server side connection state still open when client closes

Sep 26, 2012 at 2:01 PM


I'm using SuperSocket 1.5 beta (commit b58166b80382) on the server side. The client is a simple c# console app that uses TcpClient to connect the server.

Async communication just works perfect, except when I force the client connection to close because the server side did not respond in time (=timeout situation).

To force the client to disconnect, I call the Close() method on the TcpClient instance. To make sure the connection is really closed, I tried to call Close() on the stream as well.

Unfortunately, on the server side the Connected property on the AppSession<TAppSession, TRequestInfo> instance still returns true (=Connected). Funny enough, calling the sessions Send() method does not lead to an error...

Is there a way to find out there is actually a client connected when trying to send back the response?

Any ideas/hints highly appreciated! Thanks.


Sep 27, 2012 at 2:00 AM

Did you override the the AppServer's virtual method "OnSessionClosed(...)" but didn't invoke the base.OnSessionClosed(....) ?

Sep 27, 2012 at 2:49 AM
Edited Sep 27, 2012 at 2:50 AM

I think the current feature is ok. I have created a test case named "TestSessionConnectedState()" in Test Project to cover your case just now.

Could you try it out?

Sep 27, 2012 at 2:47 PM

hi kerry,
unfortunately, this does not fix the issue!

to reproduce, please find a small sample solution (VS 2012, NET 4) here:
if you build and run the solution, a console app fires up:

=> A custom protocol appserver is started (ip=any, port=22001).
=> All log output is routed to the console window.
=> To clear the console window, press [C]
=> To exit/terminate the application, press [ENTER]

pressing [F1] creates a tcp client and sends a custom protocol request to the server.
because the server side stuff simulates a longer processing time (3s, hardcoded), the client side thread times out after 1s.
client side connection is forced to close.
the blocking thread (Stream.Read), which waits for the response, ends with the following exception: Unable to read data from the transport connection: A blocking operation was interrupted by a call to WSACancelBlockingCall. however, this exception is expected!

=> unfortunatelly, server side now is not aware about the fact the client has disconnected (=> which is the discussion topic...)
=> strange behaviour: no exception thrown when sending the response

Scenario2 (OK):
pressing [F2] also creates a tcp client and sends a custom protocol request to the server.
but in this scenario, timeout on the client side is set to 10s => no timeout will occur during the simulated "long" processing time (3s, hardcoded).

=> server side is able to send the custom protocol response back to the client after 3s
=> client receives the custom protocol response from the server
=> no exceptions, all happy, party time!


Eventually, I close the client connection the wrong way in case of a timeout situation (scenario 1) ?

Anyway, your feedback is highly appreciated.

Sep 27, 2012 at 2:58 PM

Did you look at the test case I created for your issue? I think you didn't close the connection in a proper way.

Sep 27, 2012 at 3:03 PM

no, have not looked at the test case yet. sorry!
and yeah, I also think that I shut down the connection the wrong way... you have my sample code? any hints how to do it the proper way?


Sep 27, 2012 at 3:04 PM

Please try out the test case "TestSessionConnectedState()" in Test project first!