Alex Rivera | Logout

How to prevent .NET libraries from sending RST packet on close

Asked 2011-08-23T17:00:47.117
14

I'm doing some testing trying to isolate some odd behavior in the libraries (.NET). When I use the Winsock API through C++ and simply call, closesocket(), I see the windows side send the FIN/ACK packet and the remote side send back an ACK packet. This is what I would call a graceful close. However, when programming in C# I'm not seeing what I would call a graceful close.

In C#, I open my socket and then, when closing it, I see windows send a FIN packet Only when first calling Socket.Shutdown(). However, regardless, when I call Socket.Close() in C#, an RST packet is sent and the connection summarily dropped. This confuses me because, from what I've read on line, the TCP closing process should be FIN/ACK -> ACK (from both sides actually but for now, I'm only concerned with "my" side); i.e. there should not be an RST packet in the mix at all. From what I've read, apparently, an RST packet is only sent when the receiver is uncertain about the connection state and wants out.

Why is this RST packet being sent on a planned shutdown in .NET and not at all in a planned shutdown from the winsock API? Is there a way to prevent the transmission of an RST packet during a graceful shutdown from .NET?

In case it's important, in both code paths, I'm reading all available data on the socket before calling the respective close() method.

Edit
Report

1 Answer

0

Just recently hit a similiar issue where an application was talking POP3 to an Exchange Server. When the .NET program finished, it closed down ungracefully, and Exchange treated the POP3 conversation as "aborted" and rolled it back.

The reason for that is I think TCP RST is a "one-way" message-- you don't have to wait for a reply. So that's what .NET sends (or perhaps any program after it terminates.) One possible solution is to wait a bit after closing the socket and before quitting the program:

Thread.Sleep(5000);

This worked for the POP3 problem I mentioned earlier; the waiting time caused the connection to shut down gracefully, and Exchange no longer aborted the session.

answered 2011-08-23T17:14:21.613

Your Answer