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 --
http://www.iana.org/assignments/port-numbers]. 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.
--Wayne
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
