I was wondering how exactly does TCP implement in-order delivery.
lets say this is list of events
packet1 sent , ack received.
packet2 sent , ack not-received.
packet3 sent.
packet4 sent.
ack4 received.
ack3 received.
ack2 received.
Can you describe to me what exactly happens sequentially?
The short answer is that each packet contains offset information (disguised as sequence number), specifying where in the stream its payload lies.
Let's say the following occurred: packet 1 is received, packet 2 is not received, and packet 3 and 4 are received. At this point receiving TCP stack knows where to copy contents of packets 3 and 4 on the buffer, and it knows that it still hasn't received prior data, so it will make packet 1 data available for reading, but it won't make packet 3 or 4 data available until packet 2 is received.
Transmitting TCP stack generally does not wait for acknowledgements for any single packet before sending out the next one, but if it does not receive an acknowledgement for a given packet (and ACKs can and are bundled together in a single packet for efficiency), it will retransmit it until an ACK is received.
Exact sequence of events depends on network conditions, TCP stack implementation, chosen TCP policy, socket options and other factors.
TCP packets have sequence numbers (byte offsets since the start, from memory) and the ACK messages acknowledge that a specific offset has been received:
So you could end up with a situation like:
data 1 (10 bytes) ->
<- ack (10, data1)
data 2 (15 bytes) ->
data 3 (10 bytes) ->
data 4 ( 8 bytes) ->
<- ack (25, data1/2/3)
<- ack (33, data1/2/3/4)
In other words, the sender can continue to send regardless of acknowledgments up to the point where its buffers are full (it has to keep unacknowledged packets in case it needs to re-transmit them).
This "disconnect" between sends and acknowledgments can greatly speed up the data flow.
At the receiving end, the packets can arrive out of order, and they're kept until something can be delivered to the higher levels in order.
For example, if data 3 arrived before data 2, the receiving end would hold on to it until data 2 arrived, then both of them would be sent upwards for delivery.
Related
I'm working on an gameServer that communicate with game client, but wonder whether the packet server send to client remain sequence when client received it ?
like server sends packets A,B,C
but the client received B,A,C ?
I have read the great blog http://packetlife.net/blog/2010/jun/7/understanding-tcp-sequence-acknowledgment-numbers/
It seems that every packet send by the server has an ack corresponding by client, but it does not say why the packet received by client has the same sequence with server
It's worth reading TCP's RFC, particularly section 1.5 (Operation), which explains the process. In part, it says:
The TCP must recover from data that is damaged, lost, duplicated, or delivered out of order by the internet communication system. This is achieved by assigning a sequence number to each octet transmitted, and requiring a positive acknowledgment (ACK) from the receiving TCP. If the ACK is not received within a timeout interval, the data is retransmitted. At the receiver, the sequence numbers are used to correctly order segments that may be received out of order and to eliminate duplicates. Damage is handled by adding a checksum to each segment transmitted, checking it at the receiver, and discarding damaged segments.
I don't see where it's ever made explicit, but since the acknowledgement (as described in section 2.6) describes the next expected packet, the receiving TCP implementation is only ever acknowledging consecutive sequences of packets from the beginning. That is, if you never receive the first packet, you never send an acknowledgement, even if you've received all other packets in the message; if you've received 1, 2, 3, 5, and 6, you only acknowledge 1-3.
For completeness, I'd also direct your attention to section 2.6, again, after it describes the above-quoted section in more detail:
An acknowledgment by TCP does not guarantee that the data has been delivered to the end user, but only that the receiving TCP has taken the responsibility to do so.
So, TCP ensures the order of packets, unless the application doesn't receive them. That exception probably wouldn't be common, except for cases where the application is unavailable, but it does mean that an application shouldn't assume that a successful send is equivalent to a successful reception. It probably is, for a variety of reasons, but it's explicitly outside of the protocol's scope.
TCP guarantees sequence and integrity of the byte stream. You will not receive data out of sequence. From RFC 793:
Reliable Communication: A stream of data sent on a TCP connection is delivered reliably and in
order at the destination.
I've transfer a data via SCP and get some messages in picture above (in black color).What relation about these messages (TCP ACKed...,TCP Zerowindow and TCP Prev...).
Thank you very much and sorry about language from network newbie.
ACK on a TCP packet gives the sequence number the other machine shall use next:
SYN (seq=1) -> received
recived <- SYN, ACK (seq=101, ack=2)
"hi" (seq=2, ack=102) -> received 2 bytes
received <- ACK (seq=102, ack=4)
recived 2 bytes <- "ho" (seq=103, ack=4)
i.e. ACK is sent on every packet to the other machine saying: "The next sequence number i expect from you is this number".
ACKs are never increased if part of data was never seen. Has "hi" not been received in the above example (by network congestion for example) the right side will reject all packets until a packet with seq=2 is received. TCP deals with that internally by repeating the seq=2 packet.
Your wireshark log suggests that some packet was not seen by it. The packet might have goen through the network normally (and probably it did, otherwise it would have been repeated) but wireshark did not capture it. That is a completely possible scenario, in busy networks wireshark often fails to capture every packet.
I have send Udp packet to the Server. If the server is OK then I can receive the response packet nicely but when the server is down then I did not get any response packet. Anybody can help me that how can I send my packet to server multiple time when fail to receive the response packet. Moreover, want to keep alive the connection with server. Thanks in advance.
Well,
After you've sent the packet, you wait for the ACK (response) package from the server. You could use the DatagramSocket.setSoTimeout() to an appropriate time, if you get the Timeout Exception increment a counter, if that counter is less than 2/3 send the packet again and repeat these steps. If the counter is bigger than 2/3 the server is down, just quit.
According to Java documentation, receive will block until a package is received or a timeout has expired.
To keep the connection alive you need to implement a ping-pong. In another thread of your program, you send a Keep-Alive packet (any small packet will do) and wait for a response. I suggest using a different port number for this purpose so that these packets won't mess up with the normal data packets. These packets can be send every 2 seconds o 2 minutes depends on your particular needs. When the thread receives the ACK packet it will update a private time variable with the current time, for example:
lastTimeSeen = System.currentTimeMillis();
put a method in your thread class to access the value of that variable.
If client socket sends:
Packet A - dropped
Packet B
Packet C
Will server socket receive and queue B and C and then when A is received B and C will be passed to the server application immediately? Or B and C will be resent too? Or no packets will be sent at all until A is delivered?
TCP is a sophisticated protocol that changes many parameters depending on the current network state, there are whole books written about the subject. The clearest way to answer your question is to say that TCP generally maintains a given send 'window' size in bytes. This is the amount of data that will be sent until previously sent acknowledgments are successfully returned.
In older TCP specifications a dropped packet within that window would result in a complete resend of data from the dropped packet onwards. To solve this problem as it's obviously a little wasteful, TCP now employs a selective acknowledgment (SACK) option (RFC 2018). This would result in just the lost/corrupted packet being resent.
Back to your example, assuming the window size is large enough to encompass all three packets, and providing you are taking advantage of the latest TCP standard (don't see why you wouldn't), if packet A were dropped only packet A would be resent. If all packets are individually larger than the window then the packets must be sent and acknowledged sequentially.
It depends on the latencies. In general, first A is resent. If the client gets it and already has B and C, it can acknowledge them as well.
If this happens fast enough, B and C won't be resent, or maybe only B.
Can anybody explain how the packet interaction with TCP Selective Acknowledgment works?
I found the definition on Wikipedia, but I cannot get a clear picture what Selective Acknowledgment really does compared to Positive Acknowledgment and Negative Acknowledgment.
TCP breaks the information it sends into segments... essentially segments are chunks of data no larger than the current value of the TCP MSS (maximum segment size) received from the other end. Those chunks have incrementing sequence numbers (based on total data byte counts sent in the TCP session) that allow TCP to know when something got lost in-flight; the first TCP sequence number is chosen at random, and for security-purposes it should not be a pseudo-random number. Most of the time, the MTU of your local ethernet is smaller than the MSS, so they could send multiple segments to you before you can ACK.
It is helpful to think of these things in the time sequence they got standardized...
First came Positive Acknowledgement, which is the mechanism of telling the sender you got the data, and the sequence number you ACK with is the maximum byte-sequence received per TCP chunk (a.k.a segment) he sent.
I will demonstrate below, but in my examples you will see small TCP segment numbers like 1,2,3,4,5... in reality these byte-sequence numbers will be large, incrementing, and have gaps between them (but that's normal... TCP typically sends data in chunks at least 500 bytes long).
So, let's suppose the sender xmits segment numbers 1,2,3,4,5 before send your first ACK. If all goes well, you send an ACK for 1,2,3,4,5 and life is good. If 2 gets lost, everything is on hold till the sender realizes that 2 has never been ACK'd; he knows because you send duplicate ACKs for 1. Upon the proper timeout, the sender xmits 2,3,4,5 again.
Then Selective Acknowledgement was proposed as a way to make this more efficient. In the same example, you ACK 1, and SACK segments 3 through 5 along with it (if you use a sniffer, you'll see something like "ACK:1, SACK:3-5" for the ACK packets from you). This way, the sender knows it only has to retransmit TCP segment 2... so life is better. Also, note that the SACK defined the edges of the contiguous data you have received; however, multiple non-contiguous data segments can be SACK'd at the same time.
Negative Acknowledgement is the mechanism of telling the sender only about missing data. If you don't tell them something is missing, they keep sending the data 'till you cry uncle.
HTH, \m