Comment les sockets de domaine Unix différencient-ils plusieurs clients?
TCP a les paires de tuple (IP Addr/port/type) pour différencier un client d'un autre. UDP transmet l'IP et le port client. Comment le domaine Unix assure-t-il le suivi de différents clients?
En d'autres termes, le serveur crée un socket lié à un chemin, par exemple/tmp/socket. 2 clients ou plus se connectent à/tmp/socket. Que se passe-t-il en dessous qui garde la trace des données de client1 et client2? J'imagine que la pile réseau ne joue aucun rôle dans les sockets de domaine, donc le noyau fait-il tout le travail ici?
Existe-t-il un format de protocole de domaine Unix comme il existe un format de protocole IP et des formats TCP/UDP? Le format des protocoles de datagramme de socket de domaine est-il publié quelque part? Chaque Unix est-il différent ou quelque chose comme POSIX le standardise-t-il?
Merci pour toute illumination. Je n'ai trouvé aucune information expliquant cela. Chaque source a simplement passé en revue la façon d'utiliser les sockets de domaine.
Si vous créez un PF_UNIX socket de type SOCK_STREAM, et acceptez les connexions dessus, puis chaque fois que vous acceptez une connexion, vous obtenez un nouveau descripteur de fichier (comme valeur de retour de l'appel système accept). Ce descripteur de fichier lit et écrit des données dans un descripteur de fichier dans le processus client. Ainsi, cela fonctionne comme une connexion TCP/IP.
Il n'y a pas de "format de protocole de domaine Unix". Il n'y en a pas besoin, car une socket de domaine Unix ne peut pas être connectée à un pair via une connexion réseau. Dans le noyau, le descripteur de fichier représentant la fin d'un SOCK_STREAM Le socket de domaine Unix pointe vers une structure de données qui indique au noyau quel descripteur de fichier se trouve à l'autre extrémité de la connexion. Lorsque vous écrivez des données dans votre descripteur de fichier, le noyau recherche le descripteur de fichier à l'autre extrémité de la connexion et ajoute les données au tampon de lecture de cet autre descripteur de fichier. Le noyau n'a pas besoin de mettre vos données dans un paquet avec un en-tête décrivant sa destination.
Pour un SOCK_DGRAM socket, vous devez indiquer au noyau le chemin du socket qui devrait recevoir vos données, et il l'utilise pour rechercher le descripteur de fichier pour ce socket de réception.
Si vous liez un chemin d'accès à votre socket client avant de vous connecter au socket serveur (ou avant d'envoyer des données si vous utilisez SOCK_DGRAM), le processus serveur peut obtenir ce chemin en utilisant getpeername (pour SOCK_STREAM). Pour un SOCK_DGRAM, le destinataire peut utiliser recvfrom pour obtenir le chemin de la socket d'envoi.
Si vous ne liez pas de chemin, le processus de réception ne peut pas obtenir un identifiant qui identifie de manière unique l'homologue. Du moins, pas sur le noyau Linux que j'utilise (2.6.18-238.19.1.el5).