Thanks, Glen. This provides some useful things to consider if we encounter this supposed 'ceiling' on sockets. I can see where the SO_REUSEADDR could cause problems if you have a multi-threaded app placing concurrent calls. We're going to write a little benchmark code and try to hammer the host with a kazaillion sockets and see who yells 'uncle'.
R. Baker Hughes UniVerse Programming Mouser Electronics, Inc. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Glen Batchelor Sent: Thursday, February 16, 2006 5:01 PM To: [email protected] Subject: RE: [U2] Pushing envelope on openSocket I can't speak from a U2 stand point, regarding limits on socket handles. I just don't have the experience. Thus my "off the wall" note. The O/S is typically responsible for cleaning up client and server sockets. If U2 is performing O/S level socket functions, then the O/S will be the deciding factor in a lot of it. Many of the MV flavors I've studied or used have wrapped the socket functions, to allow for cross-OS coding. Socket functions on Win32 are not the same as Unix. That, by itself, can cause problems if the wrapped code is performing blind operations from BASIC code calls. I have never heard of O/S level client sockets being problematic after X cycles. That's not the same as listening sockets, though. The SO_REUSEADDR flag, which is available on most platforms, tells the socket subsystem to reuse the same memory address for all incoming connections for a specific port. An example bad situation would be, listen()->accept()->I/O Error->crash->start->listen(). That kind of issue is known to cause Error->crash->start->address stacking on Windows. When a listening server crashes upstream and doesn't release the socket handle properly, the addresses that are in-use will stack up until no more addresses are available. That's why a Windows reboot is required every so often, when the startup of listening sockets begin to return "in-use" errors. I've also read about shutdown() and close() being misused interchangeably. Close() releases the file handle, but the socket address may or may not be released in the network subsystem. That can also lead to a pile-up of allocated, but unused socket addresses. The only fix there is a system reboot, or to wait it out until the O/S forces all unused, inactive, sockets to be cleaned up. That can take an hour or 3 days, depending on the O/S and how it manages the network. ------------------------------------------- Glen Batchelor IT Director All-Spec Industries phone: (910) 332-0424 fax: (910) 763-5664 e-mail: [EMAIL PROTECTED] ------------------------------------------- www.allspec.com ------------------------------------------- ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
