Ethereal-users: Re: [Ethereal-users] Info in a TCP packet that it has been received?
From: Hansang Bae
| On 01:49 PM 8/28/2004, bejay wrote:
| >Is there anyway to tell from outgoing Packets whether the packet
has been
| >received at the other end whether it is to a Web Server or a Mail
Server
| >(when you do NOT see the incoming packets)....... is there any
indication in
| >the IP/TCP to know that it got to its destination?
|
|
| How is this possible in tcp? tcp will not work if ACKs are not
acknowledged.
Your question is a little odd as a *packet* as such is not really
important to TCP but instead the *data* it conveys. You don't
(explicitly) acknowledge an ACK in TCP when the connection has been
established, as it's not required: there are implicit acknowledgements
then when sending or receiving data over the active connection. If you
use other transport protocols (like UDP) then you need to provide
secure acknowledgement. See for example class 2 transactions in the
Wireless Transaction Protocol (WTP) in the WAP specifications.
The TCP protocol provides full-duplex transmission of data streams.
This means that there are two data streams for each TCP connection:
one for each direction. If you consider only one direction, then the
sending endpoint must know whether (but not when) the data has been
received at the receiving endpoint. This is achieved by sending a TCP
packet with an ACK and a sequence counter which tells how many bytes
of data have already been received. This sequence starts with a
randomly chosen value at TCP connection setup, and there's one
sequence per direction, so each endpoint knows a sending sequence
number and a receiving sequence number, where the endpoint will
increment the sending sequence number if it has data to send, and it
will increment the receiving sequence number whenever it received data
(and the data stream arrived "without gaps").
The sequence numbers are increased by the number of data bytes the
packet conveys. This allows a successful reconstruction of the data
stream irrespective of how and in which order the data packets
arrived. If a data packet is missing, then the receiving endpoint will
issue an ACK with the last received sequence number "before the
missing packet". This will inform the sending endpoint that it must
re-send some missing data.
In TCP you not really care about the packets arriving, instead you
will ensure that the data stream sent in one direction is correctly
received (same data, in the same order) at the receiving endpoint.
This is achieved by verifying the sending and receiving sequence
numbers. Whenever the sending endpoint expects an acknowledgement and
it doesn't arrive, the sending endpoint will retransmit the data that
has been sent after the last known acknowledged sequence number from
the receiving endpoint. That's the way the TCP protocol handles
dropped packets. If the connection dropped, then you probably will
receive an ICMP message that the given endpoint no longer is
available. Your TCP stack will then know this, and your software may
then take the necessary actions (e.g., drop that TCP socket and reopen
a new one).
The TCP protocol nowadays also supports so-called TCP options, which
are negotiated at connection setup. One option is called "selective
ACK" and it allows a more efficient bandwidth usage when dropped
packets or out-of-order delivery of packets are common. If a "gap" is
detected by the receiving endpoint, then it will return a selective
acknowledgement (SACK) where it tells about the gap, so the sending
endpoint only needs to retransmit the gap, not all data already
delivered *after* that gap (which would happen with "vanilla" TCP).
There's another TCP option, where both endpoints have to timestamp
their segments. This option can be used to compute the round-trip time
(time to go from sending endpoint to receiving endpoint, and back for
the ACK).
Hope this helps!
Best regards,
Olivier
