Receive block forever for UDPClient Class

  • Thread starter Thread starter Richard
  • Start date Start date
R

Richard

As I know, Receive method will block "forever" if no respond for UDPClient
Class by default,
this is not what I want.

I would like it to block for "timeout", (10 sec. for example), any way?

Thanks.

-Richard
 
You could use the Socket class, specifying the SocketType as Dgram and
ProtocolType as Udp, which allows you to call BeginReceive(). You could then
wait for 10 seconds and call EndReceive().

There may well be a better solution. You could examine how this is
implemented in the MessageQueue.BeginReceive method using Reflector, but
having had a quick look it does not look simple.

HTH
Dan
 
Dan Kelley said:
You could use the Socket class, specifying the SocketType as Dgram and
ProtocolType as Udp, which allows you to call BeginReceive(). You could
then
wait for 10 seconds and call EndReceive().
Click to expand...

Wait for 10 seconds and Call EndReceive?
No, you misunderstand.
I say block for timeout (10 sec.) means at most 10 sec., if there is any
Datagram come in, block would be release before 10 sec.
Can I test if there is any datagram come in by using Socket.Available?
If I would, when I test there is some datagram received, then I call
socket.Receive the incomed datagram. Am I right?

Thanks.
--Richard
 
Richard said:
Wait for 10 seconds and Call EndReceive?
No, you misunderstand.
I say block for timeout (10 sec.) means at most 10 sec., if there is any
Datagram come in, block would be release before 10 sec.
Can I test if there is any datagram come in by using Socket.Available?
If I would, when I test there is some datagram received, then I call
socket.Receive the incomed datagram. Am I right?

Thanks.
--Richard
Click to expand...

I think the confusion may be the other way around :) The BeginReceive method
takes a callback delegate. This means as soon as a dgram is received, the
callback will be executed, and you can process the message. If no message is
received, you end the receive call. My suggestion means you will neveer wait
more than 10 seconds.

As for your Available question, looking at the documentation it should work.
However, as always the only way to know for sure is to test it. The main
question is, how will you test Available? If you put it into a tight loop
(while !socket.Available), you will thrash the CPU, and will again need some
way of breaking out of the loop after 10 seconds.

HTH
Dan
 
Back
Top