Udp client Programming
-
I had a similar situation not too long ago. To solve the problem I used the following snippet in a separate thread; to close the port just set
UDPrunningto false, wait for the thread to exit and then you can close the port. I'm not sure if it's the best solution, but it is a solution that worked in my situation.while (UDPrunning == true) { if (udpSocket.Available > 0) { try { IPEndPoint msgSenderInfo = new IPEndPoint(IPAddress.Any, 0); Byte\[\] incomingData = udpSocket.Receive(ref msgSenderInfo); // do something with the data } catch (SocketException e) { // do something to handle the exception } } else { // Stop the thread from using too much processor time Thread.Sleep(100); } }Hi thanks for the reply But i have doubt regarding one of ur suggestions. You comment was "to close the port just set UDPrunning to false, wait for the thread to exit and then you can close the port" here the variable UDP running i have set to false in the close event of my application.and after seting the variable i am closing the port..is this the what you meant...if it is then no problem but i got confused that you were speaking abt the wait for the thread how should i wait for thread.. can you pls explain.
Regards DilipRam
-
Hi thanks for the reply But i have doubt regarding one of ur suggestions. You comment was "to close the port just set UDPrunning to false, wait for the thread to exit and then you can close the port" here the variable UDP running i have set to false in the close event of my application.and after seting the variable i am closing the port..is this the what you meant...if it is then no problem but i got confused that you were speaking abt the wait for the thread how should i wait for thread.. can you pls explain.
Regards DilipRam
That's exactly what I meant! To stop listening all you have to so is set that var to false and continue on your way. The comment about waiting for the thread is because I was running that method in a separate Thread from the gui thread. When I was shutting down my gui I wanted to make sure that the listener thread exited so that it wouldn't hang up my application. The
Thread.Join()method waits for a thread to exit, so my socket shutdown code looked like this:UDPrunning = false;
udpSocketThread.Join();
udpSocket.Close(); -
That's exactly what I meant! To stop listening all you have to so is set that var to false and continue on your way. The comment about waiting for the thread is because I was running that method in a separate Thread from the gui thread. When I was shutting down my gui I wanted to make sure that the listener thread exited so that it wouldn't hang up my application. The
Thread.Join()method waits for a thread to exit, so my socket shutdown code looked like this:UDPrunning = false;
udpSocketThread.Join();
udpSocket.Close();Hi, I would not like a Join in my closing code, it might sit and wait forever. Isnt the essence of the problem that you want the UDP listener thread to be a background thread, one that does not prevent your app from exiting ? :)
Luc Pattyn
try { [Search CP Articles] [Search CP Forums] [Forum Guidelines] [My Articles] } catch { [Google] }
-
Hi, I would not like a Join in my closing code, it might sit and wait forever. Isnt the essence of the problem that you want the UDP listener thread to be a background thread, one that does not prevent your app from exiting ? :)
Luc Pattyn
try { [Search CP Articles] [Search CP Forums] [Forum Guidelines] [My Articles] } catch { [Google] }
-
That's exactly what I meant! To stop listening all you have to so is set that var to false and continue on your way. The comment about waiting for the thread is because I was running that method in a separate Thread from the gui thread. When I was shutting down my gui I wanted to make sure that the listener thread exited so that it wouldn't hang up my application. The
Thread.Join()method waits for a thread to exit, so my socket shutdown code looked like this:UDPrunning = false;
udpSocketThread.Join();
udpSocket.Close();Thanks for the reply.. just want to confirm that the join method will not get into any hang mode. because i am calling the stop method by creating a object of dll and i dont have a thread in my application but the thread is present in dll where i have written the recieve method...
Regards DilipRam
-
Hi, I would not like a Join in my closing code, it might sit and wait forever. Isnt the essence of the problem that you want the UDP listener thread to be a background thread, one that does not prevent your app from exiting ? :)
Luc Pattyn
try { [Search CP Articles] [Search CP Forums] [Forum Guidelines] [My Articles] } catch { [Google] }
That essentially was the idea but there are 2 reasons that I didn't set
udpSocketThread.IsBackground = true;and forget about it: 1) The worker function is coded to avoid a blocking situation where the thread would hang so I wasn't worried about it waiting forever and 2) I didn't previously know about the Background vs. Foreground Thread property. That's a pretty nifty Property to have, thanks for the info! :) -
Thanks for the reply.. just want to confirm that the join method will not get into any hang mode. because i am calling the stop method by creating a object of dll and i dont have a thread in my application but the thread is present in dll where i have written the recieve method...
Regards DilipRam
-
-
That essentially was the idea but there are 2 reasons that I didn't set
udpSocketThread.IsBackground = true;and forget about it: 1) The worker function is coded to avoid a blocking situation where the thread would hang so I wasn't worried about it waiting forever and 2) I didn't previously know about the Background vs. Foreground Thread property. That's a pretty nifty Property to have, thanks for the info! :)Yes, but my point is when the listener is in its Receive() method, it needs another packet to resume its course, and only after that it could exit the loop, so your Join() is actually waiting for another UDP packet to arrive (which may never happen). :)
Luc Pattyn
try { [Search CP Articles] [Search CP Forums] [Forum Guidelines] [My Articles] } catch { [Google] }
-
Thanks again and sorry for troubling again.just to ensure that instead of doing UdpListnerThread.Join(); in my stop method i need to set udpSocketThread.IsBackground = true.is that it means thanks
Regards DilipRam
That's how I would do it anyway. :)
Luc Pattyn
try { [Search CP Articles] [Search CP Forums] [Forum Guidelines] [My Articles] } catch { [Google] }
-
Yes, but my point is when the listener is in its Receive() method, it needs another packet to resume its course, and only after that it could exit the loop, so your Join() is actually waiting for another UDP packet to arrive (which may never happen). :)
Luc Pattyn
try { [Search CP Articles] [Search CP Forums] [Forum Guidelines] [My Articles] } catch { [Google] }
In my situation I wasn't worried about the Ethernet cable being pulled. It was just a little test app connecting to a server on the local machine as a proof-of-concept of another piece of code. That's why I said in my original post "I'm not sure if it's the best solution, but it is a solution that worked in my situation." Using
IsBackgroundwould have been a wiser choice had I known about it. -
Thanks again and sorry for troubling again.just to ensure that instead of doing UdpListnerThread.Join(); in my stop method i need to set udpSocketThread.IsBackground = true.is that it means thanks
Regards DilipRam
-
That's how I would do it anyway. :)
Luc Pattyn
try { [Search CP Articles] [Search CP Forums] [Forum Guidelines] [My Articles] } catch { [Google] }
Thanks for replies..finally my stop method will be having the following code since i am using two udps and thread name is udpManagerbroadCast.Close();///..udp UdpListnerThread.IsBackground = true;///..thread FlagVal = true;///flag value soUdp.Close();///..udp and hope this is what you all were suggesting.Hope this fit the standards which you were suggesting
Regards DilipRam