Socket sur une même machine, possible ?

Version imprimable

25/09/2015, 15h39
sbill

Socket sur une même machine, possible ?

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.
25/09/2015, 15h45
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)

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:

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.

25/09/2015, 16h10
Obsidian

Bonjour,

Citation:

Envoyé par 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.

Citation:

Envoyé par leternel

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.

Citation:

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.
25/09/2015, 16h41
Obsidian

Citation:

Envoyé par 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.

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.
25/09/2015, 16h52
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.
25/09/2015, 17h19
BufferBob

salut,

Citation:

Envoyé par sbill

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
25/09/2015, 19h29
Obsidian

Citation:

Envoyé par 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 ?

Si. AF_LOCAL est un synonyme de AF_UNIX. Les deux symboles portent le même numéro en interne et correspondent à la même chose. Ça veut dire que le domaine d'adressage des sockets locaux est le système de fichiers. En tout cas sur un système UNIX ou assimilé. Windows doit implémenter cela à sa sauce…

En fait, il est bien possible de créer une paire de sockets UNIX anonymes déjà connectés à l'aide de socketpair(), mais c'est un appel rarement utilisé car il n'a que peu d'intérêt par rapport aux méthodes traditionnelles, à l'exception notable de la bidirectionnalité qui reste un avantage appréciable.

Citation:

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

Oui, car comme l'a expliqué BufferBob, c'est à cela qu'ils servent. Plus précisément, c'est nécessaire si tu utilises des sockets de type flux SOCK_STREAM. Ça ne l'est pas forcément dans le cas de type datagramme SOCK_DGRAM. La différence est la même qu'entre TCP et UDP lorsque tu passes par Internet.

Il est important de remarquer que lorsque tu déclares un socket local et que tu l'associes à une adresse, donc à une entrée dans le catalogue du système de fichiers, cette entrée est similaire dans le fonctionnement à ce qui se passe lorsque tu crées un tube nommé avec mknod p ou mkfifo : l'entrée apparaît, elle est enregistrée comme telle sur le volume exploité par le système de fichiers (généralement le disque dur) mais ne correspond à aucun fichier réellement stocké sur ce volume. L'entrée ne sert que de point de rendez-vous entre deux processus lancés de façon asynchrone (qui ne pourraient donc pas hériter des descripteurs).

Si tu veux uniquement transmettre des données entre deux processus seulement, alors les sockets ne t'apporteront rien de plus que les tubes nommés. Et comme tous ces mécanismes s'appuient sur les mêmes descripteurs de fichiers, alors ton code n'a pas besoin d'être modifié. Il te suffit simplement de créer la bonne ressource en fonction de tes besoins.

Citation:

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.

Parce que bind() (« lier ») sert à associer un socket jusque là anonyme à une adresse forcément locale à ta machine mais qui peut concerner toutes les familles d'adresses : AF_LOCAL sur le FS, comme les adresses réseau : c'est nécessaire si tu veux t'y mettre à l'écoute dans le cas d'un serveur, mais cela peut aussi être exigé par certains protocoles. Mais en aucun cas cela ne te renseigne sur l'homologue que tu cherches à joindre.

Citation:

Envoyé par BufferBob

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

C'est vrai mais à condition que l'interface locale lo (ou ce qui en tient lieu) soit correctement configurée et soit disponible, puisqu'il est possible de l'éteindre. Et dans tous les cas, les problèmes posés en environnement multi-utilisateurs persistent.
25/09/2015, 21h23
sbill

Les explications sont claire et précises, merci !