.NET Framework - SocketException question

Asked By Rainer Queck
17-Jul-08 08:50 AM
Hello NG,

in my application I get a SocketException in my receive callback method, if
the remote socket closes.
What would be the right way to treat this exception?

I want to keep my socket working, so that I can continue to receive
messages from the remote application, as it comes back online.
My problem at the moment is, that if I call  the udpClient.BeginReceive in
this moment, I again get the SocketException and from now on can't receive
any more messages on the socket.

Thanks for help and infos.

Regards
Rainer Queck
SocketException.ErrorCode
(1)
SocketException
(1)
BeginReceive
(1)
Callback
(1)
UdpClient.BeginReceive
(1)
Receive
(1)
BeginRecieve
(1)
Newsbeitrag
(1)
  Pavel Minaev replied...
19-Jul-08 10:30 PM
if

Technically, a remote UDP socket cannot "close" from your perspective,
since there's no established connection channel as such.


Depends on what the exception is, really...what is
SocketException.ErrorCode for the one you get?
  Rainer Queck replied...
17-Jul-08 09:12 AM
Hello Pavel,

Technically, a remote UDP socket cannot "close" from your perspective,
since there's no established connection channel as such.


Depends on what the exception is, really...what is
SocketException.ErrorCode for the one you get?
The error code is 10054 and the message - translated from german - is:

Rainer
  Pavel Minaev replied...
19-Jul-08 10:30 PM
Hm... apparently, if you do a Send, and get the "ICMP port
unreachable" response, this manifests itself as an error on the next
Receive you try to do on the same socket.  MSDN claims that a socket
is unusable once that happens, so you may have to recreate it entirely
on the same endpoint (once the client goes back online, it shouldn't
make any difference anyway, so long as the endpoint is the same).
  Rainer Queck replied...
17-Jul-08 09:56 AM
Hello Pavel,

Hm... apparently, if you do a Send, and get the "ICMP port
unreachable" response, this manifests itself as an error on the next
Receive you try to do on the same socket.  MSDN claims that a socket
is unusable once that happens, so you may have to recreate it entirely
on the same endpoint (once the client goes back online, it shouldn't
make any difference anyway, so long as the endpoint is the same).
Basically I understand what you say, but...
If I start my app and send a udp message to a port which is not opened
(yet) I  do get the socket exception (10054).
The confusing part is, that in this case I can call the
udpClient.BeginReceive within the Callback Method, without causing another
SocketException.

If a connection was establische, and then the remote socke closes I can't
call BeginRecieve without causing another (10054).
Why is that?

Regards
Rainer
help
know why this would happen on win2k? VB.NET Discussions Windows Server (1) IAsyncResult (1) SocketException (1) AsyncCallback (1) XP (1) BeginReceive (1) GetString (1) BeginSend (1) With TCP / IP you are not guarenteed to get all loop just block indefinitely 'Loop While not sLine.EndsWith("<EOF> ") ErrorCode = 0 Catch ex As SocketException ErrorCode = 89 response = "SocketException " & ex.SocketErrorCode.ToString & _ Catch ex As Exception ErrorCode = 88 response = ex.Source & ":" & ex.Message state object for the async receive. Dim state As New StateObject state.workSocket = handler handler.BeginReceive(state.buffer, 0, StateObject.BufferSize, 0, New AsyncCallback(AddressOf ReadCallback), state) End Sub 'SendCallback - -- -- - After a closer look - they never call Receive in their callbacks - they, make another call to BeginReceive. Besides, this apparently wasn't the issue anyway :) Interesting. . . Can you try to set the
blnReset = True End If Catch ex As System.IO.IOException If TypeOf ex.InnerException Is SocketException AndAlso CType(ex.InnerException, SocketException).ErrorCode = 10060 Then 'This should mean that we had a timeout 'for some reason, in .Net End If end try thanks, Keith Langer .NET Framework Discussions IOException (1) Socket.EndReceive (1) SocketException (1) TcpClient (1) Socket.Select (1) BeginReceive (1) Forms.Timer (1) ShowMessage (1) Actually, you should have been reestablishing the connection before timeout in the call to the Select() method. Personally, I would use async paradigm, with BeginReceive, and a timer (if you've got a GUI, I'd use Forms.Timer, but
NetworkStream EndRead SocketException OperationAborted .NET Framework I have a .NET 2.0 application that acts as a TCP called, so it calls EndRead. EndRead occasionally throws an IoException that has an InnerException of SocketException that has a SocketErrorCode of OperationAborted. The MSDN documentation says that OperationAborted means the socket is the NetworkStream and the Socket still connected and working? Thanks, John .NET Framework Discussions SocketException.SocketErrorCode (1) OutOfMemoryException (1) NetworkStream.ReadTimeout (1) ObjectDisposedException (1) StackOverflowException (1) NetworkStream.EndRead (1) ArgumentNullException net_nonClsCompliantException"))); } return num2; } EndReceive() method just wraps the errorCode returned and throws it out with SocketException: public int EndReceive(IAsyncResult asyncResult) { SocketError errorCode; int num = this.EndReceive(asyncResult, out errorCode); if (errorCode ! = SocketError.Success) { throw new SocketException(errorCode); } return num; } Regarding OperationAborted, I assume you mean WSA_OPERATION_ABORTED(995) error code: http: / / msdn2.microsoft I am using .NET 2.0 and can get the error code directly from the SocketException.SocketErrorCode property which I assume matches the old WSA error code. With .NET 2.0 I call BeginRead again. After this second response, I either continue OK or get this SocketException for the OperationAborted when I call EndRead. I'm testing using localhost and see the