linux - programing - socket tcp in c

¿Diferencia entre los sockets STREAM y DATAGRAM de dominio UNIX?

Question

Esta pregunta NO es por la diferencia entre el tipo STREAM y los conectores de INTERNET tipo DATAGRAM. Sé que los sockets de STREAM usan TCP, los sockets de Datagram usan UDP y todos los elementos de TCP, UDP, los paquetes que llegan en orden, ACK, NACK, etc. Entiendo la importancia de estos a través de Internet.

Q1) Cuando creo un socket de dominio UNIX que es un socket local, ¿qué importancia tendría si el socket es STREAM o DATAGRAM? Este tipo de socket escribiría los datos en el archivo socket, ¿importaría el protocolo en este caso ya que no estoy transmitiendo datos a través de una red? ¿Hay alguna posibilidad de pérdida de datos en este caso si utilizo conectores DATAGRAM basados ​​en UNIX?

Q2) ¿Los zócalos DATAGRAM UNIX proporcionan un mejor rendimiento que los zócalos STREAM de UNIX?

Q3) ¿Cómo decidir para un socket basado en STREAM / DATAGRAM UNIX en mi aplicación?

Gracias

Answer 1

1. Una diferencia probable son los límites del mensaje. Los datagramas se entregarán en su totalidad, siendo los datagramas los límites naturales del mensaje. Con los sockets de flujo puede leer N bytes y el socket se bloqueará hasta que estén listos N bytes. Pero esto significa que no hay límites obvios de mensajes.
2. Tal vez. Un socket de flujo con TCP al menos necesita el handshake inicial de tres vías para establecer la conexión. Un socket UDP no.
3. En igualdad de condiciones, si la velocidad es una preocupación, instrumento y medida. (Supongo que ya sabe que solo un zócalo de flujo de TCP proporciona un transporte incorporado en el pedido confiable, y solo los zócalos de datagramas se pueden usar para enviar a múltiples receptores).

Answer 2

La principal diferencia es que uno está basado en la conexión ( STREAM ) y el otro está sin conexión ( DGRAM ); la diferencia entre la transmisión de flujo y la comunicación orientada a paquetes suele ser mucho menos importante.

Con SOCK_STREAM usted sigue recibiendo todo el manejo de la conexión, es decir, listen / accept y puede saber si una conexión se cierra desde el otro lado.

Tenga en cuenta que también hay un tipo de socket SEQPACKET que sigue orientado a la conexión, pero conserva los límites del mensaje (lo que puede evitar la implementación de una capa orientada a mensajes sobre un socket STREAM ).

Esperaría que el rendimiento de la transferencia de datos sea similar para todos estos tipos, la diferencia principal es qué semántica quieres.

Answer 3

Si los clientes y los servidores siempre estarán en la misma máquina y el objetivo es tener una latencia mínima y un ancho de banda máximo, use la memoria compartida.

Answer 4

Al igual que la página de manual , los enchufes Unix son siempre confiables. La diferencia entre SOCK_STREAM y SOCK_DGRAM radica en la semántica de consumir datos fuera del socket.

El socket de flujo permite la lectura de un número arbitrario de bytes, pero conserva la secuencia de bytes. En otras palabras, un emisor puede escribir 4K de datos en el socket y el receptor puede consumir ese byte de datos por byte. A la inversa, también es cierto: el remitente puede escribir varios mensajes pequeños en el zócalo que el receptor puede consumir en una sola lectura. El socket Stream no conserva los límites del mensaje.

El socket de datagrama, por otro lado, conserva estos límites: una escritura del remitente siempre corresponde a una leída por el receptor (incluso si el búfer del receptor dado para read(2) o recv(2) es más pequeño que ese mensaje).

Por lo tanto, si su protocolo de aplicación tiene mensajes pequeños con un límite superior conocido en el tamaño de los mensajes, SOCK_DGRAM mejor con SOCK_DGRAM ya que es más fácil de administrar.

Si su protocolo requiere cargas útiles de mensajes largos arbitrarios, o simplemente es una transmisión no estructurada (como audio en bruto o algo así), seleccione SOCK_STREAM y realice el almacenamiento en búfer requerido.

El rendimiento debería ser el mismo, ya que ambos tipos solo pasan por la memoria interna del kernel, solo la administración del buffer es diferente.