 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / .NET Framework / .NET SDK / October 2006Calling Socket.Close() on a socket that is set to Receive()?
Hi; I have a thread with a socket in an infinite loop where it does a Receive() acts on it, then blocks for the next. Is the best way to kill this to call Close() on the socket which causes an exception?  Signaturethanks - dave david_at_windward_dot_net http://www.windwardreports.com Cubicle Wars - http://www.windwardreports.com/film.htm Hi David, From you scenario, it seems that you using the Socket.Receive method in a blocking mode which means it will block the current thread until there is data available. Commonly we did not recommend force a Socket.Close to release the blocking call. But sometime we do have the requirement to stop the blocking call which there may have certain scenario the server is down or hang which cause the client blocking infinite. Here is the document from MSDN. If no data is available for reading, the Receive method will block until data is available, unless a time-out value was set by using Socket.ReceiveTimeout. If the time-out value was exceeded, the Receive call will throw a SocketException. If you are in non-blocking mode, and there is no data available in the in the protocol stack buffer, the Receive method will complete immediately and throw a SocketException. An error occurred when attempting to access the socket. See Remarks below. You can use the Available property to determine if data is available for reading. When Available is non-zero, retry the receive operation. Socket.Receive Method (Byte[], Int32, Int32, SocketFlags) http://msdn2.microsoft.com/en-us/library/w3xtz6a5.aspx That is to say we can set the timeout value for a Receive block call, e.g. 5s, so every 5s we will have a chance to decide if we want to continue block reading or just stop reading, if you want it work in a more efficient way, you may decided the time interval at your scenario. Socket.ReceiveTimeout Property http://msdn2.microsoft.com/en-us/library/system.net.sockets.socket.receiveti meout.aspx Also here is a link about blocking and unblocking class sample. Communicating over Sockets: Blocking vs. Unblocking http://www.codeguru.com/csharp/csharp/cs_network/sockets/article.php/c11649_ _2/ Best regards, Peter Huang Microsoft Online Community Support ================================================== When responding to posts, please "Reply to Group" via your newsreader so that others may learn and benefit from your issue. ================================================== This posting is provided "AS IS" with no warranties, and confers no rights. Is timing out and starting the receive again every second better than closing the socket? This is a thread that may receive a packet once a day - but if we are closing the app we want it to do so fast so we would have a 1 second timeout. That strikes me as wasting a lot of unnecessary CPU cycles. Signaturethanks - dave david_at_windward_dot_net http://www.windwardreports.com Cubicle Wars - http://www.windwardreports.com/film.htm > Hi David, > [quoted text clipped - 47 lines] > ================================================== > This posting is provided "AS IS" with no warranties, and confers no rights. > Is timing out and starting the receive again every second better than > closing [quoted text clipped - 4 lines] > > That strikes me as wasting a lot of unnecessary CPU cycles. Having a dedicated blocked thread for a once-per-day I/O strikes me as wasting a lot of OS resources (relatively speaking). That extra thread uses memory, needs to be listed in the scheduler queues. I don't know much about the scheduler algorithms but I suspect that many of them are O(1) in the number of threads. Use WSAAsyncSelect and have a message delivered to your WndProc. Then clean shutdown is just a matter of calling WSAAsyncSelect again with zero flags before WSAShutdown and out. >> Hi David, >> [quoted text clipped - 54 lines] >> This posting is provided "AS IS" with no warranties, and confers no >> rights. We're a dll with no UI so no WndProc available. Otherwise yes that's how we would do it. Signaturethanks - dave david_at_windward_dot_net http://www.windwardreports.com Cubicle Wars - http://www.windwardreports.com/film.htm > > Is timing out and starting the receive again every second better than > > closing [quoted text clipped - 73 lines] > >> This posting is provided "AS IS" with no warranties, and confers no > >> rights. > We're a dll with no UI so no WndProc available. Otherwise yes that's how > we > would do it. Then WSAEventSelect and WaitForMultipleEvents will at least give you alternate ways of waking the thread and not require a pending I/O, even though you'll still have a dedicated thread. You should probably also look into handling some of the states besides "data available for read" because if say your ethernet hub gets power cycled, the NIC state may change to "cable disconnected" causing sockets to be closed, etc., and you may want to respond to this. >> > Is timing out and starting the receive again every second better than >> > closing [quoted text clipped - 87 lines] >> >> This posting is provided "AS IS" with no warranties, and confers no >> >> rights. Hi David, I understand your scenario as below. You have Server A, Client B. The Client B will send about one packet to Server A per day. So I think you may try the idea below. Server A will listen on Port 12345(e.g.) When the client B will try to send the packet, it connect to the Server and send the packet, and at last close the socket. i.e. Server A //pcode While(true)( S = Listen(12345); S1 = S.Accept(); S1.Read(sync or async) //Read one packet, We should define the packet size beforehandle, so that we will know what is the size we expect to receive //or define a header(fix size) to tell what is the size of the packet, so that we will know what is the size we expect to receive After that the Client should close the socket, and the S1 will be closed too. So I think we did not need to block/poll for one day on the socket S1, just the Socket S listen for new incoming connection. Best regards, Peter Huang Microsoft Online Community Support ================================================== When responding to posts, please "Reply to Group" via your newsreader so that others may learn and benefit from your issue. ================================================== This posting is provided "AS IS" with no warranties, and confers no rights.
Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.