Hi Tijl! Tijl Houtbeckers wrote:
>A few problems I see with using keep-alives (as far as I understand them) >1. It is very low level, not all programming languages / devices will have acces to >it. > It's right that not every programming language support activating keep-alives, but: - you only have to activate it at the server - you don't have to do anything on the client it's completely transparent to it - it's accessible by much more programming languages then the OOB data >2. It is bound to TCP/IP, I could for example use a bluetooth link or a serial link >instead >of TCP/IP. Jabber over HTTP also sort of falls into this catagory. > TCP keep-alives aren't and won't be needed by the Jabber protocol. It just solves some problems we have with TCP. Therefore we only need it with TCP. >3. keep alive is OS dependant. Not all OSes provide acces to it, and some let you set >it only for all applications, not specific ones (as I understand from earlyer >postings). > On the one hand I know no operating system that doesn't support it, on the other hand you only need support for it on the server side. Technical keep-alives is just the retransmission of already send IP packets. The IP stack of the server that receives this packet will just think that this is a packet that he already got but the sender didn't get its acknowledge. Therefore it sends the acknowledge again ... the server IP stack knows that the cient is still there. This meens: - The IP packets are just normal, they can't be blocked by any firewall or intrusion detection system - it's the smalles amout of data we can transmit over an IP network. Because the sender knows that the packet is already acknowleged and the client will just drop the packet and acknowledge again it can send any content it wants in the packet. Therefore most implementations (Linux included) send emtpy packets. Again OOB is the complete difference: It has to be supported by both sides of the connection. Even worse: Windows 95, Windows 98 and Windows NT clients will crash if they havn't an installed bugfix to their socket code and get OOP data. Therefore (even if the server sends the data only if the client tells it does support it) the computer of the user will crash if he has an broken OS ... and he won't start the client anymore. >4 I asume keep-alives will be for *all* user that log into jabber, some might not >want >keep-alives or anything like it at all for their clients. > As I told: It's completely transparent to the client. The only thing why he couldn't like it is that the client has very expensive metered traffic. For this clients would be possible to include some way to disable keep-alives (the server can activate and deactivate keep-alives per connection). But as I wrote above: It is a very small amount of additional traffic and it's only generated on idle connections. Every other way to fix our TCP problems will generate more traffic. >A few of these problems came up before on the mailinglist, and I haven't yet heard a >solution for them. It might not hinder any implemention for this on *nix, but the >problem will still remain for the platforms/implementations that can not use this. > We have servers on Unix, Windows and Java. All of this three platforms support keep-alives (Java since version 1.3). The client side is supported by every platform/language that supports TCP/IP. Tot kijk Matthias -- Fon: +49-700 77007770 http://matthias-wimmer.de/ Fax: +49-89 312 88654 jabber:[EMAIL PROTECTED] _______________________________________________ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
