confused by socket.BeginReceive

[Steve Richter]

I dont get the point of socket.BeginReceive and socket.EndReceive. As I
understand it, BeginReceive will start a 2nd thread, call the
ReceiveCallback delegate in the 2nd thread, then block until the
socket.EndReceive method called in the 2nd thread receives some data
from the socket.

If the 1st thread will block until the 2nd thread receives some data
from the socket, what is the point of starting up the 2nd thread? I am
aware I can create my own thread and have the two threads behave the
way I want, but what am I missing about BeginReceive and EndReceive?

Is BR ... ER intended for situations when a lot of data is to be
received and EndReceive will return after the first block of data is
returned?

A 2nd related question ... How does the first thread kill the receive
in progress in the 2nd thread? Wait for the current chunk of data to
be received by EndReceive and use a sync object of some sort to signal
it is time for the 2nd thread to end?

3rd question ... the documentation says SetSocketOption -
ReceiveTimeout does not apply when Socket.BeginReceive is used. How do
I implement timeout when using the BeginReceive ... EndReceive pair?

thanks,

-Steve

 

[Nicholas Paldino [.NET/C# MVP]]

Steve,

I think you are mistaken. When you call BeginReceive, it returns
immediately, and you do not have to wait on the second thread. When the
callback is called, it will be called on the second thread. How you
interact with the first thread is up to you. If you want to have the first
thread wait for the operation to complete, then you can call EndReceive on
the first thread.

As for applying a timeout, you can use an instance of the Timer class in
the System.Timer namespace to do this. After you call BeginReceive, you
start your timer, setting the interval property to the length of time you
want to wait. You also need a flag to indicate if the operation timed out
or not. In the event handler for the callback on the async operation, you
would check the flag. If the flag is set, then do not continue your
processing (since the operation timed out, and there is no need). If the
flag is not set, then disable the timer.

Hope this helps.

 

[Steve Richter]

Steve,

I think you are mistaken. When you call BeginReceive, it returns
immediately, and you do not have to wait on the second thread. When the
callback is called, it will be called on the second thread. How you
interact with the first thread is up to you. If you want to have the first
thread wait for the operation to complete, then you can call EndReceive on
the first thread.

ok, thanks Nicholas, I just misread the documentation:

"...Your callback method should implement the EndReceive method. When
your application calls BeginReceive, the system will use a separate
thread to execute the specified callback method, and will block on
EndReceive until the Socket reads data or throws an exception. ..."

As for applying a timeout, you can use an instance of the Timer class in
the System.Timer namespace to do this. After you call BeginReceive, you
start your timer, setting the interval property to the length of time you
want to wait. You also need a flag to indicate if the operation timed out
or not. In the event handler for the callback on the async operation, you
would check the flag. If the flag is set, then do not continue your
processing (since the operation timed out, and there is no need). If the
flag is not set, then disable the timer.

what if the 2nd thread stays blocked on socket.EndReceive and does not
return because there is no data to receive? The 2nd thread would
never get to the code that tests the timeout flag.

Can I shutdown the socket in the first thread, which would cause the
socket.EndReceive to return?

thanks,

-Steve

 

[Nicholas Paldino [.NET/C# MVP]]

Steve,

Basically, in the callback, you call EndReceive to get the results of
the operation. However, your callback will not be executed until the
operation is complete. When your callback is called, EndReceive will return
immediately with the result.

If you call EndReceive before your callback is called, then the thread
you call it (the initial calling thread, perhaps) on will block until the
operation is complete.

If you shut down the socket in the middle of this operation, it should
cause the operation to complete (even because of an abort), and then your
callback will be fired. However, depending on how abrupt the abort call is,
you might have to wrap the call to EndReceive in a try/catch block to catch
any exceptions that arise.

 

[Helge Jensen]

If you call EndReceive before your callback is called, then the thread
you call it (the initial calling thread, perhaps) on will block until the
operation is complete.

Is this a guarantee? I couldn't find that anywhere in the docs when I
last did async IO.

If you shut down the socket in the middle of this operation, it should
cause the operation to complete (even because of an abort), and then your

I have never seen Thread.Abort actually abort a call on a blocking
socket. I have seen the Close of a socket generate an exception in
EndReceive though.

callback will be fired. However, depending on how abrupt the abort call is,
you might have to wrap the call to EndReceive in a try/catch block to catch
any exceptions that arise.

I don't see it as special. You have to be aware, that the socket
EndReceive is associated with might be invalid when you get invoked (it
was Close()'ed elsewhere) though.

 

[Helge Jensen]

I dont get the point of socket.BeginReceive and socket.EndReceive. As I
understand it, BeginReceive will start a 2nd thread, call the

A piece of advice: unless you *really* *really* need non-blocking IO,
don't use it. The potential synchroniazation problems are *huge*.

If you do decide to go for it for some reason, like performance, write a
test that validates that you actually realize your reason (I've seen a
few places where async-IO was a lot slower than blocking).

 

[Jon Skeet [C# MVP]]

Is this a guarantee? I couldn't find that anywhere in the docs when I
last did async IO.

It depends exactly what you mean by "operation is complete", but from
the docs:

<quote>
The EndReceive method will block until data is available. If you are
using a connectionless protocol, EndReceive will read the first
enqueued datagram available in the incoming network buffer. If you are
using a connection-oriented protocol, the EndReceive method will read
as much data as is available up to the number of bytes you specified in
the size parameter of the BeginReceive method
</quote>