PDA

View Full Version : Closing duplicate slimproto connections?



Triode
2006-03-29, 15:52
I've been trying to track down a problem causing occasion freezing of the client on 6.5 (firmware 35). Not sure I am getting
anywhere in terms of identifying the problem, but I noticed that old slimproto sessions don't get closed by the server:

Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 Vig.lan:3483 192.168.1.101:31683 ESTABLISHED 3881/slimserver
tcp 0 0 Vig.lan:3483 192.168.1.101:31682 ESTABLISHED 3881/slimserver
tcp 0 0 Vig.lan:3483 192.168.1.101:31681 ESTABLISHED 3881/slimserver
tcp 0 0 Vig.lan:3483 192.168.1.101:31680 ESTABLISHED 3881/slimserver
tcp 0 0 Vig.lan:9000 Mesh.lan:1380 ESTABLISHED 3881/slimserver
tcp 0 0 Vig.lan:microsoft-ds Mesh.lan:1096 ESTABLISHED -
tcp 0 0 Vig.lan:3483 192.168.1.102:35151 ESTABLISHED 3881/slimserver
tcp 0 0 Vig.lan:3483 192.168.1.102:35154 ESTABLISHED 3881/slimserver
tcp 0 0 Vig.lan:42999 Mesh.lan:x11 TIME_WAIT -
tcp 0 501 Vig.lan:telnet Mesh.lan:1377 ESTABLISHED -

In this case there are 4 tcp sessions maintained by the kernel for the top player. Ethereal shows only one is actively receiving
tcp keepalives from the player. As there are no keepalives going the other way the server does not know the far end has died.

I'm currently summising this is due to client reconnects using a new port number. Is there any reason for parallel tcp sessions?
If not should they be killed in slimproto_accept (if we can assume the IP address uniquely identifies the client) or _hello_handler
(if not).?

Doesn't explain why I am seeing the freezing problem as I think the last connect will steal the client in terms of all state being
set to the more recent tcp connection, but shouldn't happen?

Adrian

Triode
2006-03-30, 14:28
> I'm currently summising this is due to client reconnects using a new port number. Is there any reason for parallel tcp sessions?
> If not should they be killed in slimproto_accept (if we can assume the IP address uniquely identifies the client) or
> _hello_handler (if not).?

Turns out that not killing all the old slimproto sockets is probably the cause of my frozen player problem. [I've recorded the
details in bug 3226] Essentially leaving the old one open give the chance that the new _forgetDisconnectedClient timer could fire
and forget a client due to the old socket closing even though the new one has already opened.

I'd like to proposed closing the old slimproto connections at client reconnect time as per attached patch.

Can anyone see a problem with this?

Adrian

Triode
2006-03-30, 14:32
> Turns out that not killing all the old slimproto sockets is probably the cause of my frozen player problem. [I've recorded the

Somehow that bit got corrupted - should have said, recorded the details as bug 3226.

Dan Sully
2006-03-30, 14:40
* Triode shaped the electrons to say...

>Turns out that not killing all the old slimproto sockets is probably the
>cause of my frozen player problem. [I've recorded the details in bug 3226]
>Essentially leaving the old one open give the chance that the new
>_forgetDisconnectedClient timer could fire and forget a client due to the
>old socket closing even though the new one has already opened.
>
>I'd like to proposed closing the old slimproto connections at client
>reconnect time as per attached patch.
>
>Can anyone see a problem with this?

No.. this looks good to me. And I think it may fix a SN problem as well.

-D
--
Off the record, on the QT, and very hush-hush.