Socket.Close

  • Thread starter Thread starter Jose Luis Balsera
  • Start date Start date
J

Jose Luis Balsera

Hi all,
I'm experiencing a behavior in Socket.Close that I'm not able to explain.
Maybe someone can find a reason for the following:

In my app I use a socket to send and receive data from a server running in a
desktop PC. The app in the server runs under the full .NET Framework. In my
Pocket PC app there's a thread that handles data sending through the socket
and another thread that handles the data receiving. The first thread waits
on an event object to send and the second thread waits on the Socket.Receive
call. Nothing extraordinary until now. The app can communicate with the
server via an ActiveSync connection when the device is in its cradle or via
a GPRS RAS connection when the device is not in the cradle.
When the application ends I awake the sending thread using the event to
terminate it and that works always. But when using the GPRS connection, the
Receive call doesn't terminate with a SocketException if previously a call
to Socket.Shutdown has been made. I've never found a problem calling
Shutdown+Close in the ActiveSync case. I've also observed that if I comment
the call to Shutdown, Receive ends with a SocketException when the socket is
closed.

I thought the correct pattern was Shutdown+Close, but in the GPRS case I can
see the thread hanging for a while after the application ends. Normally, the
exception is thrown in the Receive call after more or less 4 minutes and the
thread is then able to end, so it's the process.

Is this a normal behavior?
What would be the more appropriate way to end the receiving thread?

Thank you very much
 
Jose Luis Balsera said:
Hi all,
I'm experiencing a behavior in Socket.Close that I'm not able to explain.
Maybe someone can find a reason for the following:

In my app I use a socket to send and receive data from a server running in a
desktop PC. The app in the server runs under the full .NET Framework. In my
Pocket PC app there's a thread that handles data sending through the socket
and another thread that handles the data receiving. The first thread waits
on an event object to send and the second thread waits on the Socket.Receive
call. Nothing extraordinary until now. The app can communicate with the
server via an ActiveSync connection when the device is in its cradle or via
a GPRS RAS connection when the device is not in the cradle.
When the application ends I awake the sending thread using the event to
terminate it and that works always. But when using the GPRS connection, the
Receive call doesn't terminate with a SocketException if previously a call
to Socket.Shutdown has been made. I've never found a problem calling
Shutdown+Close in the ActiveSync case. I've also observed that if I comment
the call to Shutdown, Receive ends with a SocketException when the socket is
closed.

I thought the correct pattern was Shutdown+Close, but in the GPRS case I can
see the thread hanging for a while after the application ends. Normally, the
exception is thrown in the Receive call after more or less 4 minutes and the
thread is then able to end, so it's the process.

Is this a normal behavior?
What would be the more appropriate way to end the receiving thread?

Thank you very much

--
Jose Luis Balsera
www.raona.com

Remove "collaboration" from my address to respond privately
Click to expand...

Jose,

Is your socket a listener socket? If so, you don't need to call
Shutdown on a listener socket.
 
Hi Trevor,

If by listener you mean a socket where you listen for connections by calling
Listen, it is not the case.

Thank you
 
Jose Luis Balsera said:
Hi Trevor,

If by listener you mean a socket where you listen for connections by calling
Listen, it is not the case.

Thank you
Click to expand...

OK, that rules out one possibility. Here's another question - Can you get
to the internal error code that is causing the exception to be thrown? The
error code can be obtained calling WSAGetLastError in C++ app. There should
be some similar way to do it in a C# app. The error code should start with
"100" e.g., 10063, 10056, etc...
 
Trevor said:
OK, that rules out one possibility. Here's another question - Can you get
to the internal error code that is causing the exception to be thrown? The
error code can be obtained calling WSAGetLastError in C++ app. There should
be some similar way to do it in a C# app. The error code should start with
"100" e.g., 10063, 10056, etc...
Click to expand...
Well, I think I didn't make myself clear. My problem is not related to a
exception being thrown, but rather to a exception not being thrown when it
its supposed to be thrown :->

I need the thread waiting on the Receive call to end gracefully when the
connection is ended at the other end or when the socket is closed. In that
sense, I can handle the case when Receive returns a 0 bytes count, I can
handle a SocketException with a WSACONNRESET code, etc. But I would like one
of these events to happen always and in a timely, predictible way. As I said
in my original message, when the app is ending, I close the socket (Shutdown
+ Close). If device is connected through ActiveSync this is not an issue,
but when connected through GPRS, the Receive call doesn't end and no
exception is thrown but after several minutes and thus the thread end is
delayed until that moment, so it is the process termination. I discovered
that not making a call to Shutdown before Close provokes a SocketException
and the thread can finish in a safe manner. But I'm not sure whether this
abrupt termination of the socket can cause problems or not.

Thank you very much
 
Back
Top