www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - std.socket Error: Too many open files.

reply Morgan McDermott <morganmcdermott gmail.com> writes:
Hi all,
  I've found a limitation in my current setup as far as sockets go; once 
I've  made about 500 transactions on different sockets between my test 
client and test server, I receive the error "Error: Unable to create 
socket. Too many open files." After I'm done with a socket I always shut 
it down and close it.. I assume this is some sort of operating-system 
specific limitation, but the explanation on std.socket.close ( 
"Immediately drop any connections and release socket resources" ) seems 
to state that any file handles would be closed upon calling 
Socket.close(). Is there a large delay between the close()'ing and the 
release of resources, or am I overlooking something else simple and obvious?

Thank you for your time,
  ~Morgan McDermott
Dec 08 2006
parent reply Thomas Kuehne <thomas-dloop kuehne.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Morgan McDermott schrieb am 2006-12-09:

 Hi all,
   I've found a limitation in my current setup as far as sockets go; once 
 I've  made about 500 transactions on different sockets between my test 
 client and test server, I receive the error "Error: Unable to create 
 socket. Too many open files." After I'm done with a socket I always shut 
 it down and close it.. I assume this is some sort of operating-system 
 specific limitation, but the explanation on std.socket.close ( 
 "Immediately drop any connections and release socket resources" ) seems 
 to state that any file handles would be closed upon calling 
 Socket.close(). Is there a large delay between the close()'ing and the 
 release of resources, or am I overlooking something else simple and obvious?


If you don't properly close the connection on both sides there are
delays. Do you encounter the same issues if you use the following code?








instead of





On Linux systems "netstat --tcp --numeric --programs --all" might help
you to identify "ghost" sockets.

Thomas


-----BEGIN PGP SIGNATURE-----

iD8DBQFFeq20LK5blCcjpWoRAgSNAJ91TRz0/vRLYmaSEo1W3/pMifVhDACghTwB
flbtuQXL2aUKaSWelEgnni8=
=buHL
-----END PGP SIGNATURE-----
Dec 09 2006
parent reply Morgan McDermott <morganmcdermott gmail.com> writes:
Thomas Kuehne wrote:

 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
 Morgan McDermott schrieb am 2006-12-09:

 Hi all,
   I've found a limitation in my current setup as far as sockets go; once 
 I've  made about 500 transactions on different sockets between my test 
 client and test server, I receive the error "Error: Unable to create 
 socket. Too many open files." After I'm done with a socket I always shut 
 it down and close it.. I assume this is some sort of operating-system 
 specific limitation, but the explanation on std.socket.close ( 
 "Immediately drop any connections and release socket resources" ) seems 
 to state that any file handles would be closed upon calling 
 Socket.close(). Is there a large delay between the close()'ing and the 
 release of resources, or am I overlooking something else simple and obvious?


 
 If you don't properly close the connection on both sides there are
 delays. Do you encounter the same issues if you use the following code?
 






 
 instead of
 



 
 On Linux systems "netstat --tcp --numeric --programs --all" might help
 you to identify "ghost" sockets.
 
 Thomas
 
 
 -----BEGIN PGP SIGNATURE-----
 
 iD8DBQFFeq20LK5blCcjpWoRAgSNAJ91TRz0/vRLYmaSEo1W3/pMifVhDACghTwB
 flbtuQXL2aUKaSWelEgnni8=
 =buHL
 -----END PGP SIGNATURE-----


Thank you for the reply and the (highly) useful command! My code uses 
the following to close sockets:
<code>
void close() {
	writefln("Closing connection to %s", 		
		thisSocket.remoteAddress());

		//Shutdown both send and receive
		std.socket.SocketShutdown how;
		thisSocket.shutdown(how.BOTH);

		thisSocket.close();
	}
	
	~this(){
		this.close();
	}
</code>

close() is called for all open sockets, and yet using your command, I 
receive a long list of the connections that I just closed in the 
TIME_WAIT state. According to 
<http://www.port80software.com/200ok/archive/2004/12/07/205.aspx> this 
isn't a problem with the software itself, but the mechanism TCP uses to 
ensure that any packets destined for a socket have time to get to their 
destination before a new socket gets bound on the same port.

Thanks again for the reply, Thomas.
  ~Morgan McDermott
Dec 09 2006
parent "Unknown W. Brackets" <unknown simplemachines.org> writes:
Morgan,

Are you sure both sides of the connection are being closed and shutdown?

More importantly: note that if you use a deconstructor, it will only be 
closed when explicitly deleted or when garbage collected.  If you're not 
allocating a lot of memory, this may never happen.

I suggest adding a "delete whatever;" or explicit "whatever.close();" 
when the connection is done with, to see if that improves things.

I've tested sockets and definitely done more than 1000 on both Windows 
and Linux without any problems.  But, I was closing both sides of the 
connection explicitly, not using a deconstructor.

Hope that helps.

-[Unknown]



 Thomas Kuehne wrote:

 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1

 Morgan McDermott schrieb am 2006-12-09:

 Hi all,
   I've found a limitation in my current setup as far as sockets go; 
 once I've  made about 500 transactions on different sockets between 
 my test client and test server, I receive the error "Error: Unable to 
 create socket. Too many open files." After I'm done with a socket I 
 always shut it down and close it.. I assume this is some sort of 
 operating-system specific limitation, but the explanation on 
 std.socket.close ( "Immediately drop any connections and release 
 socket resources" ) seems to state that any file handles would be 
 closed upon calling Socket.close(). Is there a large delay between 
 the close()'ing and the release of resources, or am I overlooking 
 something else simple and obvious?


 If you don't properly close the connection on both sides there are
 delays. Do you encounter the same issues if you use the following code?








 instead of





 On Linux systems "netstat --tcp --numeric --programs --all" might help
 you to identify "ghost" sockets.

 Thomas


 -----BEGIN PGP SIGNATURE-----

 iD8DBQFFeq20LK5blCcjpWoRAgSNAJ91TRz0/vRLYmaSEo1W3/pMifVhDACghTwB
 flbtuQXL2aUKaSWelEgnni8=
 =buHL
 -----END PGP SIGNATURE-----


 
 Thank you for the reply and the (highly) useful command! My code uses 
 the following to close sockets:
 <code>
 void close() {
     writefln("Closing connection to %s",        
         thisSocket.remoteAddress());
 
         //Shutdown both send and receive
         std.socket.SocketShutdown how;
         thisSocket.shutdown(how.BOTH);
 
         thisSocket.close();
     }
     
     ~this(){
         this.close();
     }
 </code>
 
 close() is called for all open sockets, and yet using your command, I 
 receive a long list of the connections that I just closed in the 
 TIME_WAIT state. According to 
 <http://www.port80software.com/200ok/archive/2004/12/07/205.aspx> this 
 isn't a problem with the software itself, but the mechanism TCP uses to 
 ensure that any packets destined for a socket have time to get to their 
 destination before a new socket gets bound on the same port.
 
 Thanks again for the reply, Thomas.
  ~Morgan McDermott
Dec 09 2006