locked
How to avoid ““SocketException”” in “ReceiveFrom’

    Question

  • Hi All,

     

    I am getting “SocketException” when I tried to close the socket after a call to its ‘ReceiveFrom’ method, Is there anyway to avoid the exception getting raised and I will be able to close the socket. Following is the code I am using

     

     

    private void AnotherMethod1()

    {

    bytesReceived = mcastSocket.ReceiveFrom(bytes, ref remoteEP);

    .

    .

    . <Some Code>

    .

    }

     

     

    private void AnotherMethod2()

    {

    mcastSocket.Close();

    }

     

    Thursday, March 29, 2007 10:00 AM

All replies

  • Hi,

    Could please post the exception message?

     

    Thanx,

    Ch.T.Gopi Kumar.

    Thursday, March 29, 2007 10:47 AM
  • Hi,

    one more thing is

    Check 'Available' property of socket and then close.

    Continue receiving till the 'Available' property is more than zero.

    Close connnection ,when 'Available' property becomes zero.

     

    See the following remarks for RecvFrom method(Except from MSDN):

     

    The ReceiveFrom method reads data into the buffer parameter, returns the number of bytes successfully read, and captures the remote host endpoint from which the data was sent. This method is useful if you intend to receive connectionless datagrams from an unknown host or multiple hosts.

    This overload only requires you to provide a receive buffer, and an EndPoint that represents the remote host. The buffer offset defaults to 0. The size defaults to the length of the buffer parameter and the socketFlags value defaults to None.

    Note

    Before calling ReceiveFrom, you must explicitly bind the Socket to a local endpoint using the Bind method. If you do not, ReceiveFrom will throw a SocketException.

    With connectionless protocols, ReceiveFrom will read the first enqueued datagram received into the local network buffer. If the datagram you receive is larger than the size of buffer, the ReceiveFrom method will fill buffer with as much of the message as is possible, and throw a SocketException. If you are using an unreliable protocol, the excess data will be lost. If you are using a reliable protocol, the excess data will be retained by the service provider and you can retrieve it by calling the ReceiveFrom method with a large enough buffer.

    If no data is available for reading, the ReceiveFrom method will block until data is available. If you are in non-blocking mode, and there is no data available in the in the protocol stack buffer, the ReceiveFrom method will complete immediately and throw a SocketException. You can use the Available property to determine if data is available for reading. When Available is non-zero, retry the receive operation.

    Although ReceiveFrom is intended for connectionless protocols, you can use a connection-oriented protocol as well. If you choose to do so, you must first either establish a remote host connection by calling the Connect method or accept an incoming remote host connection by calling the Accept method. If you do not establish or accept a connection before calling the ReceiveFrom method, you will get a SocketException. You can also establish a default remote host for a connectionless protocol prior to calling the ReceiveFrom method. In either of these cases, the ReceiveFrom method will ignore the remoteEP parameter and only receive data from the connected or default remote host.

    With connection-oriented sockets, ReceiveFrom will read as much data as is available up to the size of buffer. If the remote host shuts down the Socket connection with the Shutdown method, and all available data has been received, the ReceiveFrom method will complete immediately and return zero bytes.

    Note

    If you receive a SocketException, use the SocketException.ErrorCode property to obtain the specific error code. After you have obtained this code, refer to the Windows Sockets version 2 API error code documentation in the MSDN library for a detailed description of the error.

     

    Thanx,

    Ch.T.Gopi Kumar.

    Thursday, March 29, 2007 11:47 AM
  • There's nothing the C# Language addresses this issue; moved from Visual C# Language forum to the .NET Framework Networking and Communication forum.
    Thursday, March 29, 2007 4:53 PM