Discussion :

[sbill]

Bonjour,

Pourriez-vous me dire si ces possible d'utiliser les sockets pour communiquer entre deux processus sur une même machine ? ( comme un pipe ). Ou les machines doivent forcément ne pas être les mêmes ?

Merci.

[ternel]

C'est possible.

Mais ca utilise un port réseau, qui ne doit pas être utilisé par autre chose.
C'est d'ailleurs une des possibilités pour empêcher un programme d'être lancé plusieurs fois (si la socket "serveur" ne peut pas être ouverte, alors return/exit)

[sbill]

Pourquoi utiliser un port réseau puisque la communication se fais sur la même machine avec donc la même machine ? je pensai à créer une socket ( un fichier ), écrire sur ce fichier puis lire dessus avec un autre processus.

Exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
static int	my_sockfile(void)
{
	int				s;
	struct sockaddr_un	name;
 
	if ((s = socket(PF_LOCAL, SOCK_STREAM, 0)) == -1)
		printf(ERROR);
	name.sun_family = AF_LOCAL;
	my_strncpy(name.sun_path, "SOCKET", sizeof(name.sun_path));
	if (bind(s, (const struct sockaddr *)&name, sizeof(name)) == -1)
	{
		close(s);
		printf(ERROR);
	}
	return (s);
 
int main(void)
{
        int sock = my_sockfile();
        int ret = write (sock, "Bonjour", 7);
        if (ret == -1)
             perror("Write : "); //Destination address required
        return 0;
}
}

Cependant j'ai l'erreur "Destination address required" lors de l'écriture sur le socket, aprés je ne vois pas l'intêret de listen/accept vu que ces un processus de la même machine. (fork)

Merci pour les précisions.

[Obsidian]

Pourquoi utiliser un port réseau puisque la communication se fais sur la même machine avec donc la même machine ? je pensai à créer une socket ( un fichier ), écrire sur ce fichier puis lire dessus avec un autre processus.

Merci pour les précisions.

Ce qu'il te faut, c'est un tube (pipe), nommé ou anonyme. Sous UNIX, c'est même la première technique de communication inter-processus que l'on présente réellement.

Si le second processus est engendré par le premier, alors il faut utiliser l'appel pipe() qui renvoie deux descripteurs de fichiers : un en écriture, l'autre en lecture. Tout ce qui est envoyé dans le premier peut être lu depuis le second. Les données peuvent transiter par un tampon de typiquement 4096 octets mais en règle générale, les appels sont bloquants par défaut : ils restent en attente si l'homologue n'est pas encore au rendez-vous. Le principe général consiste donc à appeler pipe(), à créer le processus fils avec fork() qui hérite donc des mêmes descripteurs, puis à fermer avec close() de chaque côté le descripteur non utilisé sur les deux hérités.

Remarque importante : un tube est unidirectionnel. Il faut en ouvrir deux pour dialoguer dans les deux sens.

Les sockets sont une extension du principe des descripteurs de fichiers et des tubes, développé par BSD et proposé comme modèle de communication inter-processus, au moment où SysV proposait ses IPC. Ce modèle unifie les communications en se basant sur les principes existants, en généralisant d'emblée la communication bidirectionnelle (déjà possible sur les fichiers ordinaires) et en séparant distinctement les descripteurs d'un côté et le domaine dans lequel ils sont censés exister. C'est donc assez naturellement qu'on a pu les adapter à la gestion du réseau (pour lequel il n'existait pas grand chose d'unifié, hormis les solutions propriétaires) et que l'interface a été portée sur le tard dans le monde Microsoft, essentiellement suite à la démocratisation d'Internet et des applications en TCP/IP, à une époque où c'était encore IPX/SPX qui régnait en maître sur PC.

[sbill]

Merci pour la leçon Obsidian

L'utilisation des pipes ne me pose pas de problème, cependant puis-je en conclure que ce que je veux faire est impossible avec une socket de type AF_LOCAL ?

De plus, toute les sockets AF_LOCAL doivent également être bindé, listen & accept ? (puis d'un autre coté connect()).

Je sais que les pipes sont la solutions à mon problème mais actuellement j'apprend le fonctionnement des sockets en profondeur et j'aimerai bien savoir ce qui est possible et pas possible. J'ai jamais eu l'occasion d'utiliser les sockets en mode AF_LOCAL (uniquement AF_INET et AF_INET6).
Si tu pourrais me dire, pourquoi mon code renvoie l'erreur mentionné, je t'en serai reconnaissant.

Merci.

[BufferBob]

salut,

toute les sockets AF_LOCAL doivent également être bindé, listen & accept ? (puis d'un autre coté connect()).

c'est le mode opératoire pour utiliser les sockets, c'est comme dire "le fichier est dans le même répertoire que mon exécutable, y'a pas plus court que open/read/write/close ?"

pour la petite info les sockets "locales" (bindées sur localhost, 127.0.0.1 etc.) ne sortent pas de la carte réseau, et les services ne sont donc pas accessibles depuis internet non plus

[Obsidian]

Bonjour,

Bonjour,
Pourriez-vous me dire si ces possible d'utiliser les sockets pour communiquer entre deux processus sur une même machine ? ( comme un pipe ). Ou les machines doivent forcément ne pas être les mêmes ? Merci.

C'est possible.
Mais ca utilise un port réseau, qui ne doit pas être utilisé par autre chose.

Justement ! Les sockets, en principe, ne sont pas obligés d'être forcément déclarés dans le domaine réseau. La communication inter-processus est justement l'objectif principal des sockets UNIX, dont l'espace est celui du système de fichiers.

C'est d'ailleurs une des possibilités pour empêcher un programme d'être lancé plusieurs fois (si la socket "serveur" ne peut pas être ouverte, alors return/exit)

Oui, mais c'est justement ce qu'il ne faut pas faire : c'est une horreur pour les administrateurs système et sécurité : il faut configurer les firewalls pour tenir compte de ces applications et même au sein d'un même réseau, il faudrait carrément modifier la politique de sécurité de la machine elle-même, sinon la machine voisine pourrait perturber le travail de l'utilisateur avec un simple telnet, en accaparant le port concerné avec une tentative de connexion. Et même sans aller jusque là, cela interdit de fait à l'application d'être utilisée sur une même machine mais depuis deux sessions utilisateur distinctes. C'est déjà préjudiciable sur une machine personnelle, ça devient rédhibitoire quand la machine en question est un serveur : un seul connecté à la fois pourrait utiliser l'application.