2009-11-06 9 views
27

Si envío dos mensajes TCP, ¿necesito manejar el caso donde este último llega antes que el anterior? ¿O está garantizado que llegue en el orden en que lo envío? Supongo que este no es un ejemplo específico Twisted, porque debe ajustarse al estándar TCP, pero si alguien familiarizado con Twisted pudiera proporcionar una respuesta Twisted-specific para mi propia tranquilidad, sería apreciado :-)¿Está TCP garantizado para llegar en orden?

+3

Desde TCP tiene ni idea de dónde están sus mensajes comienzan o terminan, ¿cómo sería posible cambiar el orden de ellos, incluso si quisiera? –

Respuesta

44

Siempre que se envíen los dos mensajes en la misma conexión TCP, se mantendrá el orden. Si se abren múltiples conexiones entre el mismo par de procesos, puede tener problemas.

En cuanto a Twisted, o cualquier otro sistema de eventos asíncronos: supongo que obtendrá los mensajes dataReceived en el orden en que se reciben los bytes. Sin embargo, si comienza a eliminar el trabajo de las llamadas diferidas, puede, erm ... "torcer" su flujo de control más allá del reconocimiento.

7

TCP es una secuencia, UDP es un mensaje. Estás mezclando términos. Para TCP, es cierto que la transmisión llegará en el mismo orden en que fue enviada. No hay mensajes distict en TCP, los bytes aparecen a medida que llegan, interpretándolos como mensajes depende de usted.

+1

Re: terms - Sí, por supuesto. Sin embargo, Twisted abstrae esto en mensajes distintos (así que interpretarlos como mensajes no me corresponde a mí) – Smashery

+0

Y vale la pena señalar que aunque podría tener dos escrituras en el lado del remitente, podrían colapsar en una sola lectura en el lado del receptor, y viceversa Versa - Dependiendo de los tamaños del buffer y las condiciones de la red. –

+1

No, Twisted no resume TCP en "mensajes". Obtendrá un trozo de bytes (hasta un byte por vez en casos extremos) en el protocolo base. – truppo

20

TCP está orientado a la conexión y ofrece a sus clientes por pedido entrega. Por supuesto, esto se aplica al nivel de conexión: las conexiones individuales son independientes.

Debe tener en cuenta que normalmente nos referimos a "transmisiones TCP" y "mensajes UDP".

Cualquiera que sea la biblioteca cliente que use (por ejemplo, Twisted), la conexión TCP subyacente es independiente de ella. TCP entregará los "mensajes de protocolo" para su cliente. Por "mensaje de protocolo" me refiero, por supuesto, al protocolo que usa en la capa TCP.

nota además que la operación de E/S son asíncrono en la naturaleza y muy dependiente de la carga del sistema + también agrava la red retrasa & pérdidas, no se puede confiar en el mensaje ordenando entre conexiones TCP.

+0

¿Qué quiere decir con _between_ conexiones TCP? – simplename

11

TCP "garantiza" que un receptor recibirá el flujo reconstituido de bytes tal como fue enviado originalmente por el emisor. Sin embargo, entre los puntos finales de envío/recepción de TCP (es decir, la red física), los datos se pueden recibir desordenados, se pueden fragmentar, se pueden dañar e incluso se pueden perder. El TCP da cuenta de estos problemas usando un mecanismo de saludo que hace que los paquetes defectuosos sean retransmitidos. La pila TCP en el receptor coloca estos paquetes en el orden en que se transmitieron, de modo que cuando lee desde su socket TCP, recibe los datos tal como se enviaron originalmente.

Cuando llama al método doRead en Twisted, los datos se leen desde el socket hasta el tamaño del búfer. Esta información puede representar un solo mensaje, un mensaje parcial o múltiples mensajes. Depende de usted extraer los mensajes del búfer, pero se le garantiza que los bytes están en su orden transmitido en este punto.

Lo siento por enturbiar las aguas con mi anterior post ...

+0

revisa tu respuesta ya que estás muy equivocado. La API expuesta por TCP es en gran medida una transmisión con entrega ordenada por bytes. Se refiere aquí al método de transporte subyacente (es decir, paquetes) que, por supuesto, no está garantizado que lleguen en orden. – jldupont

+0

Para su información, la "capa de servidor" para TCP es IP, que por supuesto es "sin conexión" y no garantiza la entrega de pedidos de paquetes. – jldupont

+0

Tiene razón. Lo aclararé Gracias. –

Cuestiones relacionadas