Is TCP Guaranteed to arrive in order?
Question:
If I send two TCP messages, do I need to handle the case where the latter arrives before the former? Or is it guaranteed to arrive in the order I send it? I assume that this is not a Twisted-specific example, because it should conform to the TCP standard, but if anyone familiar with Twisted could provide a Twisted-specific answer for my own peace of mind, that’d be appreciated 🙂
Answers:
As long as the two messages were sent on the same TCP connection, order will be maintained. If multiple connections are opened between the same pair of processes, you may be in trouble.
Regarding Twisted, or any other asynchronous event system: I expect you’ll get the dataReceived messages in the order that bytes are received. However, if you start pushing work off onto deferred calls, you can, erm… “twist” your control flow beyond recognition.
TCP is a stream, UDP is a message. You’re mixing up terms. For TCP it is true that the stream will arrive in the same order as it was send. There are no distict messages in TCP, bytes appear as they arrive, interpreting them as messages is up to you.
TCP is connection-oriented and offers its Clients in-order delivery. Of course this applies to the connection level: individual connections are independent.
You should note that normally we refer to “TCP streams” and “UDP messages”.
Whatever Client library you use (e.g. Twisted), the underlying TCP connection is independent of it. TCP will deliver the “protocol messages” in order to your client. By “protocol message” I refer of course to the protocol you use on the TCP layer.
Further note that I/O operation are async in nature and very dependent on system load + also compounding network delays & losses, you cannot rely on message ordering between TCP connections.
TCP “guarantees” that a receiver will receive the reconstituted stream of bytes as it was originally sent by the sender. However, between the TCP send/receive endpoints (i.e., the physical network), the data can be received out of order, it can be fragmented, it can be corrupted, and it can even be lost. TCP accounts for these problems using a handshake mechanism that causes bad packets to be retransmitted. The TCP stack on the receiver places these packets in the order in which they were transmitted so that when you read from your TCP socket, you are receive the data as it was originally sent.
When you call the doRead method in Twisted, the data is read from the socket up to the size of the buffer. This data may represent a single message, a partial message, or multiple messages. It is up to you to extract the messages from the buffer, but you are guaranteed that the bytes are in their transmitted order at this point.
Sorry for muddying the waters with my earlier post…
If I send two TCP messages, do I need to handle the case where the latter arrives before the former? Or is it guaranteed to arrive in the order I send it? I assume that this is not a Twisted-specific example, because it should conform to the TCP standard, but if anyone familiar with Twisted could provide a Twisted-specific answer for my own peace of mind, that’d be appreciated 🙂
As long as the two messages were sent on the same TCP connection, order will be maintained. If multiple connections are opened between the same pair of processes, you may be in trouble.
Regarding Twisted, or any other asynchronous event system: I expect you’ll get the dataReceived messages in the order that bytes are received. However, if you start pushing work off onto deferred calls, you can, erm… “twist” your control flow beyond recognition.
TCP is a stream, UDP is a message. You’re mixing up terms. For TCP it is true that the stream will arrive in the same order as it was send. There are no distict messages in TCP, bytes appear as they arrive, interpreting them as messages is up to you.
TCP is connection-oriented and offers its Clients in-order delivery. Of course this applies to the connection level: individual connections are independent.
You should note that normally we refer to “TCP streams” and “UDP messages”.
Whatever Client library you use (e.g. Twisted), the underlying TCP connection is independent of it. TCP will deliver the “protocol messages” in order to your client. By “protocol message” I refer of course to the protocol you use on the TCP layer.
Further note that I/O operation are async in nature and very dependent on system load + also compounding network delays & losses, you cannot rely on message ordering between TCP connections.
TCP “guarantees” that a receiver will receive the reconstituted stream of bytes as it was originally sent by the sender. However, between the TCP send/receive endpoints (i.e., the physical network), the data can be received out of order, it can be fragmented, it can be corrupted, and it can even be lost. TCP accounts for these problems using a handshake mechanism that causes bad packets to be retransmitted. The TCP stack on the receiver places these packets in the order in which they were transmitted so that when you read from your TCP socket, you are receive the data as it was originally sent.
When you call the doRead method in Twisted, the data is read from the socket up to the size of the buffer. This data may represent a single message, a partial message, or multiple messages. It is up to you to extract the messages from the buffer, but you are guaranteed that the bytes are in their transmitted order at this point.
Sorry for muddying the waters with my earlier post…