usuario1255770
Parece que hay al menos 3 tipos diferentes de socket locales/Unix (AF_UNIX) , SOCK_STREAM, SOCK_DGRAM y SOCK_SEQPACKET.
Si bien sé que un SOCK_STREAM le da un flujo de bytes bidireccional, como TCP o una canalización bidireccional, y los otros dos le dan una API de mensaje/paquete, ¿cuál es la diferencia entre un socket Unix de SOCK_DGRAM y SOCK_SEQPACKET ?
Como estos son solo locales, no puedo pensar en una buena razón por la que alguien implementaría SOCK_DGRAM de una manera que podría reordenar los paquetes.
También, hace SOCK_DGRAM/SOCK_SEQPACKET emplear control de flujo, o se pueden descartar mensajes en caso de lectores lentos?
R.. GitHub DEJAR DE AYUDAR A ICE
Aquí hay un buen artículo sobre el caso de uso previsto para SOCK_SEQPACKETel hecho de que no está realmente disponible en las familias de protocolos IP y cómo puede obtener lo mismo con la semántica TCP existente:
http://urchin.earth.li/~twic/Sequenced_Packets_Over_Ordinary_TCP.html
Tenga en cuenta que SOCK_SEQPACKET es mucho más cercano en comportamiento a SOCK_STREAM que a SOCK_DGRAM.
Citando del sitio web referenciado:
El tipo de socket SOCK_SEQPACKET es similar al tipo SOCK_STREAM y también está orientado a la conexión. La única diferencia entre estos tipos es que los límites de registro se mantienen mediante el tipo SOCK_SEQPACKET. Un registro puede enviarse mediante una o más operaciones de salida y recibirse mediante una o más operaciones de entrada, pero una única operación nunca transfiere partes de más de un registro. Los límites de registro son visibles para el receptor a través del indicador MSG_EOR en los indicadores de mensajes recibidos devueltos por la función recvmsg(). Es específico del protocolo si se impone un tamaño de registro máximo.
-
Sin embargo, habla más sobre TCP/IP que sobre sockets PF_UNIX (PF_LOCAL). Hasta ahora, parece que la única diferencia real entre un socket local SOCK_SEQPACKET y SOCK_DGRAM es que un socket SOCK_SEQPACKET está orientado a la conexión, pero todavía no estoy seguro.
– usuario1255770
11 de abril de 2012 a las 13:32
-
Bueno, esta respuesta es incorrecta. La pregunta se refiere específicamente a PF_UNIX, y aunque el SOCK_SEQPACKET ideal sería un nivel de abstracción más alto que SOCK_STREAM (proporcionando límites de mensajes sobre él), las implementaciones no son tan idealistas. De acuerdo a este, las implementaciones de PF_UNIX son mucho más parecidas a SOCK_DGRAM, excepto por… bueno, realmente no lo sé, es por eso que entré en esta página, y ninguna respuesta parece satisfactoria. Esta respuesta se aplica solo a protocolos de red más elaborados que implementan SOCK_SEQPACKET como se supone que debe ser.
– lvella
14/08/2013 a las 17:33
-
@lvella: El enlace que cité en mi respuesta no solo explica cómo emular SOCK_SEQPACKET en TCP (que no es relevante para la pregunta de OP), sino también las motivaciones de SOCK_SEQPACKET, que creo que es uno de los temas principales sobre los que OP estaba preguntando.
– R.. GitHub DEJA DE AYUDAR A ICE
14/08/2013 a las 19:52
-
@R.. El problema es que, cualquiera que sea la motivación para SOCK_SEQPACKET, no es así como funciona en AF_UNIX, y todavía no sé por qué existe, ya que la implementación carece precisamente de lo que debería diferenciarla de SOCK_DGRAM (marcas de límites de mensajes que son independientes del datagrama de bajo nivel).
– lvella
14/08/2013 a las 20:38
modelonueve
SOCK_SEQPACKET le ofrece las garantías de SOCK_STREAM (es decir, conservación del pedido, entrega garantizada, sin duplicación), pero con límites de paquetes delineados como SOCK_DGRAM. Entonces, básicamente es una mezcla de los dos tipos de protocolo.
En la familia TCP/IP, SCTP implementa SOCK_STREAM (similar a TCP) y SOCK_SEQPACKET. Desafortunadamente, no está disponible en stock en Windows.
Creo que la principal diferencia aquí es que SOCK_SEQPACKET es orientado a la conexióntiempo SOCK_DGRAM no es.
Esto importará principalmente en el servidor lado de la conexión (el proceso que escucha en el socket UNIX) cuando hay múltiple procesos del cliente hablando con él:
Con SOCK_DGRAM, obtendría datagramas de cliente intercalados directamente en el socket de escucha. Con SOCK_SEQPACKETgenerarías un separado cliente socket para cada cliente usando acceptrecibiendo así los datagramas de cada cliente por separado.
citando man 3 accept:
La llamada al sistema accept() se utiliza con tipos de socket basados en conexión (SOCK_STREAM, SOCK_SEQPACKET).
jorgensen
socket (2) página de manual proporcionada por Linux: “DGRAM: datagramas (mensajes sin conexión, no confiables), SEQPACKET: secuenciado, confiable, [two-way] ruta de transmisión de datos basada en conexión para datagramas”. Diferencia significativa.
la página de manual de unix(7) proporcionada por linux dice: “SOCK_DGRAM, for a orientado a datagramas socket que preserva los límites del mensaje [but not necessarily order] […] SOCK_SEQPACKET, para un orientado a la conexión socket que preserva los límites de los mensajes y los entrega en el orden en que fueron enviados”.
El estandar permisos que obtiene paquetes reordenados con SOCK_DGRAM. (En otras palabras, si un sistema operativo te los entrega en orden, esa es una característica específica de la implementación. O simplemente pura suerte de tiempo).
Existe un control de flujo en la implementación de af_file/af_unix en Linux, pero no es necesario que se correlacione con el comportamiento estándar especificado en absoluto.
Al igual que los sockets TCP y UDP, hay sockets SCTP (protocolo de transmisión de control de flujo) que tienen dos formas, (uno a uno) y (uno a muchos) entre puntos finales. Uno a uno usa SOCK_STREAM y uno a muchos usa SOCK_SEQPACKET
IIRC, SOCK_DGRAM le dará un mensaje a la vez, mientras que SOCK_SEQPACKET (para los protocolos que lo admiten) le permitirá leer varios datagramas a la vez, pero siempre dará lecturas atómicas de datagramas, vice SOCK_STREAM donde necesita analizar los límites del mensaje tú mismo.
– bert
11 de abril de 2012 a las 12:11
Solo un comentario SOCK_SEQPACKET se usa en AX.25 (protocolo de radioaficionado) consulte, por ejemplo, stackoverflow.com/questions/19040205/…
–Steven R. Loomis
10 de julio de 2014 a las 16:22