|
Hello Roberto,
[..]
> Julian proposed following framework:
>
> http://www.ssi.bg/~ja/tmp/tt.txt
>
> So if you want to test, the only thing you have to do is fire up your
> editor of choice :). Ok, honestly, I don't know when this will be done
> because it's quite some work and most us developers here are a pretty
> busy with other daily activities. So unless there is a glaring issue
> regarding timers implemented as-is, chances are slim that this gets
> implemented. Of course I could fly down to Julian's place over the
> week-end and we could implement it together; want to sponsor it? ;).
Well, currently I am not in the position to sponsor such development,
but things may change. If that casse I would contact you via p-mail.
(Ryanair does not fly to .bg .... :/ )
As you are from .ch (as your domain tells me ;)) ... will you be at
linuxtag (Wiesbaden, Germany?).
And I looked at Julian's proposal. Ufff. I not a fluent C speaker, so if
I would try to do that, I would recommend not to use it :)
>> eh, I got it form /proc:
>>
>> # cat /proc/sys/net/ipv4/tcp_keepalive_time
>> 7200
> Ahh, but that's not 2h + 9*75s :).
May I quote from the document you mentioned and comment: ip-sysctl.txt
tcp_keepalive_time - INTEGER: How often TCP sends out keepalive messages
when keepalive is enabled. Default: 2hours.
-> The kernel tries all 2 houres to send probes and check if the
connection is still there?
tcp_keepalive_probes - INTEGER: How many keepalive probes TCP sends out,
until it decides that the connection is broken. Default value: 9.
-> The kernel tries 9 times to send such probes. The probes will be 75
secs (tcp_keepalive_intvl) distance. After all 9 failed, the kernel will
drop the connection.
That brings me back to my 7200 + 9 * 75 secs. But it may be only 7200 +
8 * 75 secs, because the value does say noting about the timeout of the
last IP paket.... errrrh </confused> ...
> There's a lot of TCP timers in the Linux kernel and they all have
> [...]
> /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_time_wait:120
^^^^^^^^^
Are you on drugs or am I too dumb :) ? What do the netfiler timeouts
have to do with the tcp_keepalive in general? Or did you respond to the
resource i mentioned (this was about netfilter but I was only interested
in the little part about tcp_keepalive in general ...)
> And of course we have the IPVS TCP settings, which look as follows (if
> they weren't disabled in the core :)):
^^^^^ disabled? why should we ?
> timeouts. Since there is no socket (as in an endpoint) involved when
> doing either netfilter or IPVS, you have to guess what the TCP flow
> in-between (where you machine is "standing") is doing, so you can
> continue to forward, rewrite, mangle, whatever, the flow, _without_
> disturbing it. The timers are used for table mapping timeouts of TCP
> states. If we didn't have them, mappings would stay in the kernel
> forever and eventually we'd run out of memory. If we have them wrong, it
> might occur that a connection is aborted prematurely by our host, for
> example yielding those infamous ssh hangs when connecting through a
> packet filter.
Yes, I am asking myself is, if wee see a FIN or RST fyling through a tco
connection, we could lower the timer significantly or even dropp the
entry because we may know what's happening?
My current problem is a client connection with a keepalive foo to a DB
balanced (via NAT) to two real servers. The client opens a forms, types,
then parks his browser and going to lunch for a hour ot two. Then he
comes back and presses "sumbit".... validation error....
IMVHO the best solution would be a javascript on the client that tries
to get 1 byte of from the DB every some minutes, but ....
> The tcp keepalive timer setting you've mentioned, on the other hand, is
> per socket. And as such only has an influence on locally created or
> terminated sockets. A quick socket(2) and socket(7) skimming reveil:
[....]
If SO_KEEPALIVE is not enabled, the session will cease to exist after
2h? Is anyone here aware what the default values/ranges of win machines are?
> I'm a bit missing this view from your cited reference. I did not read it
> through thoroughly. My apologies for not being more specific, however I
> don't have more time right now.
Well, first of all thanks a lot for your expertise!
Best Regards,
Andreas
|
