Tal como dice la página del manual, los sockets de Unix son siempre confiables. La diferencia entre SOCK_STREAM y SOCK_DGRAM está en la semántica de consumir datos fuera del socket.
El socket de flujo permite leer un número arbitrario de bytes, pero aún conserva la secuencia de bytes. En otras palabras, un remitente puede escribir 4K de datos en el socket y el receptor puede consumir esos datos byte a byte. Lo contrario también es cierto:el remitente puede escribir varios mensajes pequeños en el socket que el receptor puede consumir en una sola lectura. El socket de flujo no conserva los límites del mensaje.
El socket de datagramas, por otro lado, conserva estos límites:una escritura del remitente siempre corresponde a una lectura del receptor (incluso si el búfer del receptor se asigna a read(2) o recv(2) es más pequeño que ese mensaje).
Entonces, si el protocolo de su aplicación tiene mensajes pequeños con un límite superior conocido en el tamaño del mensaje, es mejor que use SOCK_DGRAM ya que eso es más fácil de administrar.
Si su protocolo requiere cargas útiles arbitrarias de mensajes largos, o es solo una transmisión no estructurada (como audio sin procesar o algo así), elija SOCK_STREAM y haga el almacenamiento en búfer necesario.
El rendimiento debe ser el mismo, ya que ambos tipos solo pasan por la memoria local del kernel, solo que la administración del búfer es diferente.
-
Una diferencia probable son los límites del mensaje. Los datagramas se entregarán como un todo, 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 N bytes estén listos. Pero esto significa que no hay límites de mensaje obvios.
-
En igualdad de condiciones, si la velocidad es una preocupación, instrumento y medida. (Supongo que ya sabe que solo un conector de flujo proporciona un transporte en orden confiable incorporado, y solo los conectores de datagramas se pueden usar para enviar a múltiples receptores).
La principal diferencia es que uno es basado en conexión (STREAM ) y el otro es sin conexión (DGRAM ) - la diferencia entre la comunicación orientada a flujos y paquetes suele ser mucho menos importante.
Con SOCK_STREAM aún obtiene todo el manejo de la conexión, es decir, listen /accept y puede saber si una conexión está cerrada por el otro lado.
Tenga en cuenta que también hay un SEQPACKET tipo de socket que todavía está orientado a la conexión, pero conserva los límites del mensaje (lo que podría evitarle implementar una capa orientada al mensaje sobre un STREAM enchufe).
Espero que el rendimiento de la transferencia de datos sea similar para todos estos tipos, la principal diferencia es la semántica que desea.