[JDEV] Keep-Alives

Sat Jul 6 23:32:19 CDT 2002

I hope this clarifies my previous post a bit (see near bottom of email),
 - Dave

Matthias Wimmer wrote:
> Dave wrote:
> >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.)
> >  
> >
> What do you mean with the TCP technique? Why not confirming it with XML? 
> I think it's one of our strengths that we have a very simple protocol. 
> We just have a TCP connection and we're just sending XML over it. Sure 
> ... XML data is big and redundand, but that's good. If you have a bug in 
> and XML document you can easily fix it (even by hand) ... you can't do 
> this with binary data. Also it's very easy to debug, therefore you have 
> less bugs in your products. If you are concerned about the amount of 
> traffic you generate (e.g. because you connect by a mobile device and 
> traffic is expensive), then compress it.
> Using OOB is exactly what we don't need: It would make the protocol much 
> harder to be implemented. There aren't many programmers that want to 
> deal with low level networking stuff. Also adding new XML vocabulary to 
> confirm delivery will be much easier to implement in existing clients 
> then to add OOB handling to them.

Nope, I didn't mean to use binary responses.  I meant to use the TCP
technique of piggybacking ACKs on other types of packets (e.g., messages)
to save packets.  For instance, rather than sending an immediate response
of "<message id="243" type="delivered"/>" after receiving "<message
to='somebody at somewhere' id='243'><body>Hi</body></message>," the server
would send "<message from='somebody at somewhere' id='244'><body>What&apos;s
up?</body></message><message id='243' type='delivered'/>" all at once
when the next message came, rather than sending the ACK immediately.
I don't think we should use binary in an XML transport layer, and I
don't think that's about to change.  (As I've indicated in the past, I
believe very strongly that Jabber should support other transport layers,
but the last time I said anything about that, I got flamed to death,
so pretend I didn't just say that ... hehe. . .)