[jdev] SIMPLE or XMPP?

Dave Cridland dave at cridland.net
Tue Sep 30 11:59:08 CDT 2008


On Tue Sep 30 17:28:14 2008, aragalo at cs.uct.ac.za wrote:
> My question is: Is it possible that the UDP version of SIMPLE could  
> be
> more bandwidth efficient than XMPP over TCP for the conveyance of  
> presence
> information? Evidently SIMPLE is more verbose than XMPP, however  
> UDP is a
> much lighter transport layer protocol than TCP.

Short answer: No.

TCP is indeed marginally heavier than UDP - the header is 12 octets  
bigger. Unfortunately, SIMPLE's presence data is typically more than  
12 octets bigger than XMPP, so the net gain isn't in SIMPLE's favour.

In addition, there's two other factors that come into play. The  
largest factor - not as common as it should be - is compression,  
which, due to using previous TCP packets in the stream, can be very  
effective - again more than amply outweighing any overhead of TCP.

Also, more than one XMPP stanza can share a single TCP packet - this  
means the header overhead can be shared between stanzas. So if three  
or more stanzas share a single TCP packet, it's lower overhead than  
UDP.

Finally, I would note that whilst TCP is certainly more heavyweight  
than UDP, traditionally UDP's benefits are that it's connectionless,  
meaning both fewer resources on the server (not helpful here IMHO,  
because we're generally dealing with manageable numbers of clients  
and connected servers) and much more significantly a lower latency  
from cold to sending data.

XMPP will take up several RTTs before a presence packet is sent from  
cold - potentially as many as ten or so, although you'll find a very  
good analysis in the archives of the standards list by Tony Finch.

SIMPLE, on the other hand, can send that immediately, albeit without  
any TLS etc, so the latency is, in principle, much lower in the "from  
cold" case.

It's this heavyweight aspect of TCP based protocols that's the reason  
behind DNS, for example, typically using UDP, since the additional  
latency of using TCP would really show in session startup times. But  
it's worth noting that due to the lack of error handling, many  
operating systems run resolution DNS - ie, workstation-to-resolver -  
over TCP rather than UDP, maintaining a single TCP session for the  
OS's resolver service.

Similarly, I'd argue that for client-to-server cases, TCP is much  
more suitable. An argument could be made that for server-to-server  
cases UDP might be better, but that ignores aspects like TLS and  
authentication, which are much harder to get right on UDP, and would  
likely overshadow the additional setup cost of TCP anyway.

Dave.
-- 
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade



More information about the JDev mailing list