Ethereal-users: Re: [Ethereal-users] Info in a TCP packet that it has been received?
Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.
From: "Olivier Biot" <ethereal@xxxxxxxxxx>
Date: Tue, 7 Sep 2004 08:49:37 +0200
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
- References:
- Re: [Ethereal-users] Info in a TCP packet that it has been received?
- From: Hansang Bae
- Re: [Ethereal-users] Info in a TCP packet that it has been received?
- Prev by Date: Re: [Ethereal-users] Parsing protocols inside ESP packets?
- Next by Date: Re: [Ethereal-users] finding crc errors
- Previous by thread: Re: [Ethereal-users] Info in a TCP packet that it has been received?
- Next by thread: Re: [Ethereal-users] Parsing protocols inside ESP packets?
- Index(es):