2012-03-10 10 views
37

TCP tiene los pares de tuplas (IP Addr/port/type) para distinguir un cliente de otro. UDP pasa el IP del cliente y el puerto. ¿Cómo hace un seguimiento del dominio Unix de diferentes clientes?¿Cómo diferencian los sockets de dominio de Unix entre múltiples clientes?

En otras palabras, el servidor crea un socket vinculado a alguna ruta say/tmp/socket. 2 o más clientes se conectan a/tmp/socket. ¿Qué está sucediendo debajo que rastrea los datos de client1 y client2? Me imagino que la pila de la red no forma parte de los sockets de dominio, ¿así que el núcleo está haciendo todo el trabajo aquí?

¿Hay un formato de protocolo de dominio Unix como si hubiera un formato de protocolo IP y formatos TCP/UDP? ¿El formato de los protocolos de datagramas socket de dominio está publicado en alguna parte? ¿Cada UNIX es diferente o hace algo como POSIX estandarizarlo?

Gracias por cualquier iluminación. No pude encontrar ninguna información que explicara esto. Cada fuente simplemente pasó por alto cómo usar los sockets de dominio.

+0

Hablar sobre un protocolo de dominio unix es básicamente solo archivo de E/S. a menos que los datos que está pasando a través del socket contengan identificación de origen, no hay forma de decir a qué proceso se envía una cadena en particular. –

+0

@MarcB que debería ser una respuesta –

+3

¿Puede ser cierto? Si un servidor escribe datos, ¿el primer cliente que lee obtiene la información independientemente de si fue o no para ese cliente? Eso los hace casi inútiles. –

Respuesta

62

Si crea un socket de tipo PF_UNIXSOCK_STREAM, y acepta conexiones en él, entonces cada vez que acepte una conexión, se obtiene un nuevo descriptor de archivo (como valor de retorno de la llamada accept sistema). Este descriptor de archivo lee datos y escribe datos en un descriptor de archivo en el proceso del cliente. Por lo tanto, funciona como una conexión TCP/IP.

No hay "formato de protocolo de dominio de Unix". No es necesario, porque un socket de dominio Unix no se puede conectar a un par a través de una conexión de red. En el kernel, el descriptor de archivo que representa el extremo de un socket de dominio Unix SOCK_STREAM apunta a una estructura de datos que le dice al kernel qué descriptor de archivo está en el otro extremo de la conexión. Cuando escribe datos en su descriptor de archivo, el kernel busca el descriptor de archivo en el otro extremo de la conexión y agrega los datos al búfer de lectura de ese otro archivo descriptor. El kernel no necesita poner sus datos dentro de un paquete con un encabezado que describa su destino.

Para un socket SOCK_DGRAM, debe decirle al kernel la ruta del socket que debe recibir sus datos, y lo usa para buscar el descriptor de archivo para ese socket receptor.

Si enlaza una trayectoria a su socket de cliente antes de conectarse a la toma de servidor (o antes de enviar los datos si está utilizando SOCK_DGRAM), entonces el proceso servidor puede obtener el recorrido en el getpeername (por SOCK_STREAM). Para un SOCK_DGRAM, el lado de recepción puede usar recvfrom para obtener la ruta del socket de envío.

Si no enlaza una ruta, el proceso de recepción no puede obtener una identificación que identifique de manera única al igual. Al menos, no en el núcleo de Linux que estoy ejecutando (2.6.18-238.19.1.el5).

+0

Gracias por una respuesta excelente y completa. –

+0

Gran respuesta. Gracias @rob – nic

+0

También hay SOCK_SEQPACKET para AF_UNIX en Linux que permite conexiones como en SOCK_STREAM, pero también conserva los límites de los mensajes como en SOCK_DGRAM. –

Cuestiones relacionadas