Talk:TCP global synchronization
![]() | This article may be too technical for most readers to understand. |
- it's missing a definition
- I suggest the following definition: "TCP global synchronization is an event, in course of which several TCP streams start to send packets simultaneously." In other words, TCP global syncronization is a TCP equivalent of physical resonance, where time substitutes frequency, and number of packets arrived in one time unit substitutes amplitude. Unfortunately, I cannot provide a linkable source (lecture at Internet Technology course in university), and therefore do not put this definition directly into the article.
- an image would be helpful
Scale of problem
Is this problem a real problem that occurs on real diverse networks like the internet, or theoretical problem that only occurs on test networks specially designed to demonstarate this. 192.102.214.6 (talk) 14:04, 29 May 2008 (UTC)
Meaningless sentence about UDP
Connectionless protocols such as UDP do not experience global synchronization because they ignore (or are not aware of) packet loss
This is meaningless.
UDP does not deal with packet loss (it is packet-loss neutral). It is not unaware of, it simply does not care. OTOH, reliable higher-level protocols care, are aware of, and deal with packet loss. The way some higher protocol does may not be exactly the same as TCP, but it will have similarities, because the context (problem, goal, constraints...) is exactly the same.
Since the design of UDP is basically the opposite of the design of TCP (unconnected, datagram-based, un-acknowledged, no rate limiting vs connected, stream-based, packet acknowledgment, rate control), they can't be used interchangeably, their only common feature being that they are both user protocol (having user chosen ports).
Since they can't be used in the same context, it is particularly absurd to compare problems with TCP with problems with UDP. Even putting them on the same "level" is misleading.
So : removing this sentence. —Preceding unsigned comment added by 212.27.60.48 (talk) 00:49, 9 November 2008 (UTC)