[e2e] Some questions about TCP.
detlef.bosau at web.de
Sun Nov 22 13:24:57 PST 2009
Noel Chiappa wrote:
> > From: Detlef Bosau <detlef.bosau at web.de>
> > 1.: Recently, I was told, however I did not find a reference in some
> > RFC, we had two distinct packet types in TCP:
> > - those _with_ payload, which are _data_ _segments_,
> > - those _without_ payload, which are _acknowledgements_.
> > If this is correct, I would appreciate some reference.
> No, not really.
> All TCP packets contain both i) an ack field (for acking
Correct. So, basically I would expect acks to flow "piggypack" on the
The problem occurs when you clock out several segments from a TCP peer.
In that case, several segments / TCP packets will contain the same ack
Now, the RFC states explicitly that a segment _MUST_ _NOT_ be acknowled
more than once. So, how do we avoid
incoming packets to be mistaken for dup acks?
So, I asked a number of people and was told the above....
> data bytes sent from the other end), and ii) provisions for carriage of
> data. (Well, putting data in with a SYN is allowed, but is a bit odd.)
> Iff there is bi-directional data flow, a packet with data in it (going in
> one direction) can _also_ ack bytes received from the other side. An ack
O.k.. One thought of mine was that the ACK flag will indicate a
significant ack number. However, RFC 793 states that in "established"
state, a packet's ACK flag is always set.
So, there's some confusion....
Meanwhile, I looked into some real TCP connections using wireshark - and
found the aforementioned statement confirmed...
> packet is just a normal TCP data packet with 0 bytes of data in it. You
> sometimes see the term 'ack packet' used to describe such packets.
So, my confusion retains....
Detlef Bosau Galileistraße 30 70565 Stuttgart
phone: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau
ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de
More information about the end2end-interest