# How to Distinguish between a Reset packet and a Normal one **URL:** \ **Category:** Ruby\ **Created:** [March 22, 2007, 5:29am UTC](https://www.ruby-forum.com/t/how-to-distinguish-between-a-reset-packet-and-a-normal-one/89697 "2007-03-22T05:29:13Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![sai438](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/b4bc9f/32.png) [@sai438](https://www.ruby-forum.com/u/sai438)\ **Post date:** [March 22, 2007, 5:29am UTC](https://www.ruby-forum.com/t/how-to-distinguish-between-a-reset-packet-and-a-normal-one/89697/1 "2007-03-22T05:29:13Z")
How to Distinguish between reset packet and a normal packet?? Here I am using TCPSocket API where in Iam Using recvfrom(). ---
**Author:** ![sai438](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/b4bc9f/32.png) [@sai438](https://www.ruby-forum.com/u/sai438)\ **Post date:** [March 22, 2007, 6:19am UTC](https://www.ruby-forum.com/t/how-to-distinguish-between-a-reset-packet-and-a-normal-one/89697/2 "2007-03-22T06:19:29Z")
On Mar 22, 2007, at 12:29 AM, sairam MP wrote: > How to Distinguish between reset packet and a normal packet?? Here > I am > using TCPSocket API where in Iam Using recvfrom(). You can’t. If you are using a TCP socket you don’t know where any packet boundaries are located. TCP only presents a byte stream to the application. It sounds like you are describing a situation where data has been arriving and you are reading it and then for some reason the remote system decides to abort the TCP connection by sending a TCP RST packet. On your end, you’ll be able to read all the queued data normally and then, when you’ve consumed all the pending data, the next time you try to read from the socket, an exception will be raised to let you know that the underlying TCP session has gone away (rather than being closed cleanly). Gary W. ---
**Author:** ![sai438](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/b4bc9f/32.png) [@sai438](https://www.ruby-forum.com/u/sai438)\ **Post date:** [March 22, 2007, 9:52am UTC](https://www.ruby-forum.com/t/how-to-distinguish-between-a-reset-packet-and-a-normal-one/89697/3 "2007-03-22T09:52:31Z")
Gary W. wrote: > On Mar 22, 2007, at 12:29 AM, sairam MP wrote: > > > How to Distinguish between reset packet and a normal packet?? Here > > I am > > using TCPSocket API where in Iam Using recvfrom(). > > You can’t. If you are using a TCP socket you don’t know where > any packet boundaries are located. TCP only presents a byte > stream to the application. > > It sounds like you are describing a situation where data has been > arriving and you are reading it and then for some reason the remote > system decides to abort the TCP connection by sending a TCP RST > packet. > > On your end, you’ll be able to read all the queued data normally > and then, when you’ve consumed all the pending data, the next time > you try to read from the socket, an exception will be raised to let > you know that the underlying TCP session has gone away (rather than > being closed cleanly). > > Gary W. I think its possible,while receiving some data,if the length of data received is zero in a blocked receive function then the connection is said to be reset by peer. Sairam ---
**Author:** ![sai438](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/b4bc9f/32.png) [@sai438](https://www.ruby-forum.com/u/sai438)\ **Post date:** [March 22, 2007, 3:52pm UTC](https://www.ruby-forum.com/t/how-to-distinguish-between-a-reset-packet-and-a-normal-one/89697/4 "2007-03-22T15:52:25Z")
On Mar 22, 2007, at 4:52 AM, sairam MP wrote: > I think its possible,while receiving some data,if the length of data > received is zero in a blocked receive function then the connection is > said to be reset by peer. No. A ‘reset by peer’ is a very specific TCP term. It means that a packet with the RST bit set has arrived on the connection. It is possible to have packets that contain no data (keep alive packets for instance). You can’t infer that the connection is dead from that. But the bigger problem is that you can’t even see packet arrivals from the application. By the time the data gets to the application the packet boundaries are unknowable. Unless you are talking about kernel programing you are thinking about TCP in a very misleading way. It is a common misunderstanding about TCP that if the sender writes 100 bytes that the receiver will read 100 bytes. That is, that the writes of the sender and the reads of the receiver are always ‘paired up’. This is not the way TCP works. Message boundaries are not preserved across a TCP stream nor does each call to ‘write’ correspond to a single packet on the wire. TCP can coalesce multiple writes into a single packet and can also split a single write into multiple packets. Gary W. ---
**Author:** ![sai438](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/b4bc9f/32.png) [@sai438](https://www.ruby-forum.com/u/sai438)\ **Post date:** [March 29, 2007, 7:33am UTC](https://www.ruby-forum.com/t/how-to-distinguish-between-a-reset-packet-and-a-normal-one/89697/5 "2007-03-29T07:33:59Z")
> It is a common misunderstanding about TCP that if the sender > writes 100 bytes that the receiver will read 100 bytes. That is, > that the writes of the sender and the reads of the receiver are > always ‘paired up’. This is not the way TCP works. Message > boundaries are not preserved across a TCP stream nor does > each call to ‘write’ correspond to a single packet on the wire. > TCP can coalesce multiple writes into a single packet and can > also split a single write into multiple packets. > > Gary W. I found that whenever a Reset Packet while data transfer an Exception is raised (Error::ECONNRESET), I think this can be useful. ---
**Author:** ![sai438](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/b4bc9f/32.png) [@sai438](https://www.ruby-forum.com/u/sai438)\ **Post date:** [March 29, 2007, 8:00am UTC](https://www.ruby-forum.com/t/how-to-distinguish-between-a-reset-packet-and-a-normal-one/89697/6 "2007-03-29T08:00:23Z")
On Mar 29, 2007, at 1:34 AM, sairam MP wrote: > I found that whenever a Reset Packet while data transfer an > Exception is > raised (Error::ECONNRESET), I think this can be useful. Yes it is useful. Just understand that the exception is not raised when the packet _arrives_ but when you attempt to read past the last successfully received byte in the stream. Perhaps I misunderstood your original question.