Thread overview
std.socket Error: Too many open files.
Dec 09, 2006
Morgan McDermott
Dec 09, 2006
Thomas Kuehne
Dec 09, 2006
Morgan McDermott
December 09, 2006
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
December 09, 2006
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?

#
# // casting due to http://d.puremagic.com/issues/show_bug.cgi?id=667
# socket.shutdown(cast(SocketShutdown)2);
#
# socket.close();
#

instead of

#
# socket.close()
#

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

Thomas


December 09, 2006
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?
> 
> #
> # // casting due to http://d.puremagic.com/issues/show_bug.cgi?id=667
> # socket.shutdown(cast(SocketShutdown)2);
> #
> # socket.close();
> #
> 
> instead of
> 
> #
> # socket.close()
> #
> 
> 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
December 10, 2006
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?
>>
>> #
>> # // casting due to http://d.puremagic.com/issues/show_bug.cgi?id=667
>> # socket.shutdown(cast(SocketShutdown)2);
>> #
>> # socket.close();
>> #
>>
>> instead of
>>
>> #
>> # socket.close()
>> #
>>
>> 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