Home
Fractals
Tutorials
Books
My blog
My LinkedIn Profile

BOOKS i'm reading

Napoleon Hill Keys to Success: The 17 Principles of Personal Achievement, Napoleon Hill, ISBN: 978-0452272811
The 4-Hour Workweek: Escape 9-5, Live Anywhere, and Join the New Rich (Expanded and Updated), Timothy Ferriss, ISBN: 978-0307465351
The Fountainhead, Ayn Rand, ISBN: 0452273331
Web Hosting Canada

mailto:olivier@olivierlanglois.net

TCP RST flag subtleties

02/06/10

Permalink 09:43:23 am, by lano1106, 516 words, 13651 views   English (CA)
Categories: TCP/IP

TCP RST flag subtleties

Upon reception of RST segment, the receiving side will immediately abort the connection. This statement has more implications than just meaning that you will not be able to receive or send any more data to/from this connection. It also implies that any unread data still in the TCP reception buffer will be lost. This information can be found in TCP/IP Internetworking volume 2 and Unix Network Programming Volume 1 third edition but in my opinion those books do not put enough emphasis on that detail and if you are not reading these books to find this exact detail, it might slip away from your attention.

Now, what are the conditions to receive a RST segment? The easiest way is to enable the SO_LINGER option with a timeout value of 0 on a server socket. As soon as the connection will be closed by the server, it will send a RST. You can learn more about SO_LINGER in the book Unix Network Programming Volume 1 third edition. The other possibility is if a server receives data after having closed the connection. If you enable the LINGER option, sending RST is the expected behavior but you can easily be bitten by the second possibility and here is an example on how it can happen.

Imagine a HTTP server that limits the number of simultaneous connections. Upon accepting a new connection, it might compare a global connection counter against a configured limit and if the counter has reached the limit then immediately send back a 503 error and close the connection. Do you see the problem? The server is closing the connection before receiving the HTTP request. There is a high probability that the client will never receive the 503 reply because a RST segment will immediately follow the reply.

A not too good solution would be to call shutdown(SHUT_WR) before closing the socket. What this will do is force the server to send a FIN segment before the RST segment. I have tried this solution and this seems to greatly improve the probability that the client application will receive the data before receiving the RST segment.

A better way is to program the server to read the request even if it has no intention to actually process it. This ensures that no RST will be sent unintentionally.

There remains one question. What exactly means data reception on a closed connection? Does that only include new received TCP segment or could data still in the TCP receive buffer of a closing connection be considered as data arrived after the connection has been closed? My intuition is that this question is open to interpretation and the TCP behavior will vary from one platform to the other. However, even if your platform does not react with a RST if a TCP connection receive buffer is not empty when it is closing it; my opinion is that you should not rely on that since this is a race condition. You could be closing the connection before or after receiving the client request depending on the RTT (Round Time Trip) of the connection.

Comments, Pingbacks:

Comment from: Joe Beckner [Visitor] Email · http://www.UniplexNetworks.com
I think I am experiencing the problem you are referring to in this blog.

I should preface my comment by stating that I am not a software programmer, I am a network hardware person who sells, install and maintains Cisco network switches, routers and firewalls for small and medium businesses.

I am troubleshooting an intermittent problem for a client who has about 100 users on gmail. They experiencing intermittent periods where one or more users cannot access their gmail. All other internet traffic (web, etc.)is ok. Resetting the Cisco3825 router firewall on the T1 line clears the problem. I did not believe that this was really a router problem. All sessions are terminated when the router restarts which is probably why it clears.

I have some Wireshark captures from when users are experiencing problems. What I am seeing is an immediate TCP RST coming back from the Google gmail server after the successfull TCP 3 way session initiation for HTTPS. There are no HTTP codes coming back from the server. This repeats over and over.
PermalinkPermalink 03/26/10 @ 09:59
Comment from: lano1106 [Member]
Hi John,

it seems to be different. In the scenario I am describing, the client TCP/IP stack do receive the server reply. It is the application that do not sees it because a RST is immediately following the reply and is received by the TCP/IP stack before the application has the chance to read the reply from the stack.

This is not the problem that you have because if it was, you would see the reply precedes the RST segment with Wireshark.

In your situation, if you were asking me my opinion, I would suspect your router to be a NAT device and gmail server must have an internal limit that makes it refuse a single IP address to initiate more than a certain number of connections to protect itself against spammers.

I see some avenues to solve the problem:

1. If possible, configure your router to have more than 1 public IP address on the external NIC and make the router NAT module load balance the connections among the available public IP addresses.

2. Here is what my DNS server returns me for gmail.com:

Non-authoritative answer:
Name: gmail.com
Address: 72.14.204.17
Name: gmail.com
Address: 72.14.204.18
Name: gmail.com
Address: 72.14.204.19
Name: gmail.com
Address: 72.14.204.83

You could tweek your DNS server to let it do the load balance for your users.

Please report back here if this has helped you to fix the problem.
PermalinkPermalink 03/26/10 @ 10:47
Comment from: Joe Beckner [Visitor] Email · http://www.UniplexNetworks.com
Thank you, you are right, the router with IOS Firewall is doing NAT/PAT on the single IP address of the outside T1 interface. So the Google servers will see all users with the same IP address and different TCP port numbers. I will take a look at this some more.
PermalinkPermalink 03/26/10 @ 12:42

Comments are closed for this post.

Olivier Langlois's blog

I want you to find in this blog informations about C++ programming that I had a hard time to find in the first place on the web.

April 2024
Sun Mon Tue Wed Thu Fri Sat
 << <   > >>
  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30        

Search

Custom Search

Misc

XML Feeds

What is RSS?

Who's Online?

  • Guest Users: 1

powered by
b2evolution