Since keepalives seek to solve a problem created at the TCP level, solving the problem at the TCP level makes most sense, IMHO. The current practice of simply sending blanks solves the problem transparently to the Jabber protocol, except that the data loss problem remains. The data loss problem, IMHO, should be solved seperately, since it's a general problem of delivery confirmation over an unreliable transport (TCP, in this case). If Jabber entities simply keep packets in their queues until their delivery is confirmed by the next hop, data loss will no longer occur. (Obviously, it'd be wise to use the TCP technique of piggybacking confirmations on other packets and on each other, to avoid crowding the network with "<message id="243" type="delivered"/>" responses to messages.)
- Dave Matthias Wimmer wrote: > > Hi! > > I know there were some discussions about implementing keep-alives to the > Jabber protocol. > Has anybody thought about using TCP keep-alives? I would prefer using > something at the TCP level over a Jabber protocol extension. (If > somebody want's to extend the protocol the client could just send a hint > as a attribute to the <stream:stream/> tag to tell the server if it > preferes using keep-alives or not. > See "man tcp" on your favourite Unix host for more information on > keep-alives. > > (Thought I had proposed this earlier but I havn't as I now noticed *g*) > > > 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 > _______________________________________________ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
