To make file transfers fast, client and server both use a so called sliding window, a buffer to send and receive. (Notice: we retransmitted 20003, even though it already arrived on client side. If it does not appear, the client will send an acknowledge for 20001 only. Let’s say, a server sent packets 20001, 20002, 20003 to the client, however the cient only received packet 2001 (so you see, wrong order here) the client will wait for a pre defined amount of time to get 20002. This is a very basic principle all over TCP. If a client sends a packet (let’s say number 1001) it has to get an acknowledgement for this package (1001). Sequence/acknowledge numbers are very important. This is a bit of overhead, but it’s overhead during session establishment only, so we don’t really care about it. The client increments his sequence number by 1 and uses server’s sequence number as an acknowledgement number)ġ92.168.0.1 → 192.168.0.13: ACK, seq. 1000Ĭlient → server: Ack + sequence number + acknowledge number (Ok, I’ve heared, you agree about talking. client’s sequence number is server’s acknowledge number, server’s sequence number is a random number too)ġ92.168.0.13 → 192.168.0.1 SYN/ACK, seq. Server → client: Sync/ack + sequence number + acknowledge number (Ok, let’s talk. It takes 3 packets to establish a session:Ĭlient → server: Syn + sequencenumber (Syn means: let’s talk, the sequencenumber is a random number)ġ92.168.0.1 → 192.168.0.13: SYN, seq. The situation with TCP TCP uses so called sessions. It also doesn’t care if packets arrive in the right order.
UDP doesn’t care if you got the packet, or not. So every packet you send will be delivered. Of course I care, so I’ll explain: TCP has guaranteed delivery. I got a short joke about UDP, and I don’t care if you got it!
So I’ll take a look at this brand new feature from networking perspective.I’ll start from scratch, so I don’t assume you understand network protocols.īut let me tell you a joke about UDP first: Why do I love HDX on UDP in Citrix XenDesktop and XenApp? (HDX Enlightened Data Transport EDT)
0 kommentar(er)
