Socket & IP (timeout)

[Enrico Venturi]

Hello colleagues,
we've an application client-server based on socket communication via IP; the server accpet connection on port 5001 then creates a new socket where the communication with the client is managed.
If we disconnect the LAN for a meaningful time then when the connection is re-established the communication client-server is done by a new couple of sockets ... the "old" socket on the server is no more used and it is no explicitly closed so the number of unused sockets an increase.
My question is: I suppose there's a "timeout" for the socket relating to the IP connection .... when a timeout is expired the socket should receive an event to say that it is no more valid; is my hypothesis true? if so, why we don't receive any events? does it depend on the kind of the "bind"? or something else?

thanks a lot
Enrico

[Bill McNAMARA_1]

see ndd.conf for settings and man ndd.

use netstat -an or netstat -a | grep 5001 during lan removal.

Watch out for FIN_WAIT2's too.

Later,
Bill

[Bill McNAMARA_1]

sorry that's /etc/rc.config.d/nddconf (no .)

[Enrico Venturi]

currently, I've reconnected the LAN and there're several unsed sockets, nevertheless they aren't in FINE_WAIT status!
Does the socket receive some trigger when the IP timeout expires?

[Enrico Venturi]

currently, I've reconnected the LAN and there're several unused sockets, nevertheless they aren't in FINE_WAIT status!
Does the socket receive some trigger when the IP timeout expires?

[Charles Harris]

Enrico,

The sockets will receive a timeout and also a fin_wait(s) whilst the connection is waiting for a time out connection from the client.

The fin_wait sockets will only close if the timeout is set check nettune on 10.20 or ndd on 11. as previously stated.

I've attached a handy connection state gif that illustrates the point better than my explanation.....

Hope this helps....


-ChaZ-

[Enrico Venturi]

sorry if I insist with my questions but I don't understand:
in which way does the socket receive a timeout trigger?? by which call??
and moreover, which is the parameter to see in ndd? and who can I get all the socket in FIN_WAIT by an API?

[Charles Harris]

Enrico,

What status are the sockets you are seeing as unused ? - When you disconnect the LAN you will see only the listening sockets after all of the other connections have been closed. If I understand, I think you are asking why more sockets are used other than a single connection on 5900? - If this is the case, the reason other sockets are used is to allow for more than one concurrent connection to the listener socket.

As more connections are made to the Listener port, the server spawns more sockets as part of the tcp connection, to allow further connections to the orginal socket.

Hope this helps!

-ChaZ-

[James Murtagh]

Hi,

I think the ndd parameters you are looking for are:

tcp_keepalive_detached_interval - Send keepalive probes for detached TCP
tcp_keepalive_interval - Interval for sending keepalive probes

From the socket(2) manpage recv() will error with ETIMEOUT after the tcp_keepalive_interval (default 2hrs). I'd imagine a close() or shutdown() is then sent to that stream.

Regards,

James.

[Enrico Venturi]

On my machine all the sockets are in one of the following states: TIME_WAIT, LISTEN, ESTABLISHED; there aren't sockets in FIN_WAIT state. The partner don't close the socket therefore on my machine I don't receive an explicit close request. I suppose that when the IP timeout (2 hours) expires I should receive one trigger. The question is: in which way?????

[Enrico Venturi]

the fact is that I don't perform any recv() on the socket until the select() doesn't tell me that there's something to read ...
I perform a select(fd) where fd is the list of the file descriptors created in the process scope: the select gives me the sublist of the fd's where the recv() should find something ...
As far as concerning the socket bound to the (lost) IP connection, the select doesn't find anything on them. .....
Are there any parameters affecting the socket behaviour relating to the IP connection availability?

[Ron Kinner]

TIME WAIT means that the connection has closed correctly and is just waiting for a short time to see if there are any lost packets which might show up. This is to prevent a late packet from being confused with those from a new connection. The time interval is supposed to be 2 times the maximum time that a packet can survive on the net. On an 11.0 the default is 60 seconds which is the industry standard.

tcp_time_wait_interval:

Amount of time TCP endpoints persist in TCPS_TIME_WAIT state.
[1000,600000] Default: 60000 (60 seconds)

This means that after 60 seconds the TIME WAIT state should go away. Presumably the TCP/IP stack should then signal back to the process that started the connection that the connection no longer exists. I'm not a programmer so I am not familiar with the way this happens.

This is probably a bit conservative so you could reduce this if you are just working with a few machines that you control.

ndd -set /dev/tcp tcp_time_wait_interval 30000
would reduce it to 30 secs. You have to edit /etc/rc.config.d/nddconf to make it stay after a reboot.

TRANSPORT_NAME[0]=tcp
NDD_NAME[0]=tcp_time_wait_interval
NDD_VALUE[0]=30000

(Use the next higher integer in the brackets if you already have entries in nddconf)

I'm not sure which language you are using but you might benefit from reading how Perl does it:

http://www.perlfect.com/articles/sockets.shtml

Be sure to read the links at the bottom.

For more advanced info (note the references):

http://216.239.57.100/search?q=cache:4V3XWMAx008C:www.csd.uch.gr/~markatos/papers/issues.ps+hpux+%22time+wait%22&hl=en&lr=lang_en|lang_de&ie=UTF-8

Ron

[Ron Kinner]

I just checked and there are several patches which effect socket performance. It might be a good idea to check out:

PHNE_26771

and

PHKL_22840/PHKL_25613

http://www2.itrc.hp.com/service/patch/mainPage.do

See if anything in them looks like it might be causing your problem.

Ron

[rick jones · Accepted solution]

there should be no need at all to shrink time_wait_interval to 30000

unless the connections were "active" at the time the cable was disconnected - that is to say actively trying to transmit data, unless you explicitly close them, they will remain in ESTABLISHED _forever_ _UNLESS_ you have used setsockopt() to set SO_KEEPALIVE, at which point the tcp_keepalive_interval comes into play (along with tcp_ip_abort_interval)

if your software has timed-out on its own on a socket, it really Really, REALLY aught to go ahead and call close() on the socket(s)...