UDP Revisited...

  • Thread starter Thread starter Zahid
  • Start date Start date
Z

Zahid

Hi,

Im in need of urgent clarifications regarding UDP comms,
Ive a client requirement to ensure my app works to a UDP
specification. Ive just read in MSDN that the "receive"
method "blocks execution until it receives a message"

What does it block? the application execution? the port?
the Sub/Function from which it is called? Can someone
please clarify.

Thanks in advance.
 
"Blocking" means your program will wait for a packet to be received. The
receive call will "block" the rest of the app from running until it gets
what it's waiting for.
Take a look at the asynchronous or multithreading options to avoid potential
app lag.
 
Thanks Ed,

Im using a background Thread that listens for packets and
another thread that sends for packets. This should
therefore NOT cause my program to stop until it receives
a packet? or will it still freeze?

What if my app is waiting to read a packet, in thread A,
and whilst waiting wants to send a packet to the same
IPAddress and port from Thread B, is this possible? or
will there be a problem? This is my main concern.

Thanks in advance.
 
Do you mean to send a packet to itself?

Zahid said:
Thanks Ed,

Im using a background Thread that listens for packets and
another thread that sends for packets. This should
therefore NOT cause my program to stop until it receives
a packet? or will it still freeze?

What if my app is waiting to read a packet, in thread A,
and whilst waiting wants to send a packet to the same
IPAddress and port from Thread B, is this possible? or
will there be a problem? This is my main concern.

Thanks in advance.
Click to expand...
 
Hi,

Sorry i wasnt very clear in my explanation. No i dont
want to send a packet to itself. I want to send a packet
from one IP Address to another IP Address on the same
host network (from the Wireless PocketPC to a desktop PC).

Im creating 2 lists, list one holds all 'To Send'
packets. List two holds all 'Received packets'. Thread
one will listen for packets and add each received packet
to the 'Received packets' list. Thread two will inspect
the 'To send' list and if its not empty it will send all
packets in the list. I wanted these 2 threads running in
the background of my program. Everytime I want to send a
packet I just add it to the 'To Send' list and the thread
should send it. I just want to crystal clear that this
algorithm will work. Is this a reasonable solution? Or
have I overlooked something?

Thanks in advance.
 
Yes, that should work. As long as the receive thread doesn't assume that
receive operations will complete *until* the requested data has actually
been received, that is.

Paul T.
 
Thanks Paul,

Brilliant.

Im trying to use the System.threading.lock(Object) to
ensure another thread doesnt add/delete items from the
lists that I seach. Any advice on using this method?

Thanks in advance.
 
Yes, the collection objects (List, Queue, Hashtable etc) have a property
called SyncRoot. When you use lock to protect access to a collection, make
sure you lock this SyncRoot and not the collection object itself. Most of
the collection objects also provide static method Synchronized() that return
a wrapper of the same class which is thread-safe, i.e. you don't need locks
when accessing it. Neither method will prevent you from modifying a
collection while another thread tries to enumerate it. To handle this
situation, you will need to set a lock on the collection object itself.
 
Back
Top