ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wayne Cannon <>
Subject Re: <socket> returns true thought there is no listener
Date Fri, 17 Aug 2007 15:28:35 GMT
I haven't been monitoring this thread very closely, but if I'm not off 
base, the following points may explain some of what you are seeing.  I'm 
not a TCP expert, but have been burned in the past and had to learn the 
following the hard way.

-- When you "close" a socket, it actually remains in a kind of limbo 
state, usually four minutes (two times the "maximum segment lifetime") 
or more, before it actually goes away.  This is to prevent the 
socket/port from being reused during that time so delayed packets from 
the earlier "incarnation" of the connection aren't received and 
misinterpreted by a new connection on that port.  [Stevens, "TCP/IP 
Illustrated: Volume 1, The Protocols"]

-- Many (most?) well-behaved applications use a predefined port only to 
establish a connection, and set up a temporary port provided by TCP for 
subsequent operations.  "Dynamic and/or Private Ports are those from 
49152 through 65535" [Internet Assigned Number Authority --].  This threshold used to 
be much lower.  Most applications don't seem to abide by these 
"well-known" "registered" port numbers once you get above 1024 -- and 
occasionally have conflicts as a result.

>> Does anybody know what's the cause? Thanks
> 1. <socket> tries to open a TCP connection; it gets assigned some 
> random port..I'd be surprised that it got 39001, though it is a high 
> enough value it could happen sometimes. Maybe it depends where the TCP 
> stack starts allocating unallocated ports. Try opening a socket to a 
> remote site, see what gets opened there.
> 2. run netstat -p to see the process with the port
> 3. are you sure the port is closed? Sometimes after a previous run the 
> port may still be open.
> -steve

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message