[standards-jig] The Jabber Transport, and File Transfer Too

Jeremie jeremie at jabber.org
Tue Jun 11 06:55:14 UTC 2002


> practicality. Just to give an approximate range, I would consider a
> maximum packet size of a few MB to be slightly too liberal, and a
> maximum packet size of 64KB to be somewhat restricitive. But there is no
> reason to restrict the theoretically encodable limits of the protocol to
> either of these sizes.

The ~500k that has always been the default for jabberd seems to work well,
but somewhere between those two should satisfy most needs, and it's
configurable if not.  

There's some additional things to consider when thinking about fixed
framing and sizing, such as the fact that error bounces will always be
slightly larger, the server may modify (grow slightly) packets as they
pass through, the limits might be different in each direction (between two
servers, or even to a client vs. from a client), and the path between two
entities can only be the same or grow larger each hop unless there's some
internal mechanism of packetizing and reassembly.  It's almost enough to
want to just set certain fixed limits and be done with it :)

> As for SOAP Attachments and MIME. I am by no means advocating SOAP
> Attachments. MIME is too complicated and too loose for our wire
> protocol. What I like in SOAP Attachments over XIB is that you receive
> the whole XML structure before you need to receive any of the large
> binary data. This is useful because you can begin processing the
> readable parts of the packet before you have received the opaque parts.

I understand the logic, I guess I just don't see why that is useful, or at
least not nearly useful enough to warrant such a change.  The entity that
will be making the most use of the XML is likely to be the same one that
won't consider the binary data opaque.  When it comes to the 80/20 rule,
I'll happily sacrifice complexity and take the 80% :)

> As for XATP. I really think the requirement that the server parse all
> payload data is a scalability hindrance.

Ahh, this is my bad then for not documenting XATP better, or not giving
enough examples, if only there were more time.

My full intent with XATP has always been to, whenever necessary, leverage
XIB as a generic internal framing mechanism.  The only XATP namespace
might be a simple <route to="" from=""
type="">\134<message><body>hi</body></message></route> that wraps all xml
chunks (just as a quick example).  Since XIB is just a raw block
definition, you can always have blocks within blocks, or successive
blocks, allowing any type of framing necessary.

So yes, it's cumbersome in a heterogeneous network to force the server to
process all the payload, and I don't intend to unduly require such things
of anything built on top of XATP.

> I am not sure what some mean by a "human friendly" protocol. I contend
> that it is much easier for a (human) programmer to implement a protocol
> ...
> advantage of XML where we need it - extensibility - so what is so bad
> about them? Please take this as a rhetorical question. :-)

Heh, I'll bite: I think your concept of "human" and "programmer" are
slightly skewed from reality, many talented and smart people suffer from
this, come live in Iowa for a while *g*.  Seriously, dealing with anything
binary, even for many great programmers, is dramatically farther out of
their reach than you might think.  The other popular net protocols and
even Jabber so far has shown us that accessibility is more important than
raw efficiency.  Back to the 80/20, I'm willing to give up a few bytes and
few clock cycles for added simplicity and average-joe understandability.

I'd also like to point out that numerous times others have done the math,
comparing the messages/users/day rates for AIM to what a designed-to-scale
Jabber server (Jabber, Inc.'s specifically, but jabberd's capabilities are
even competitive to AOL's entire farm) can sustain, and a single rack of
servers could provide Jabber instead of OSCAR to their userbase.  Already
Jabber can be written to saturate almost any pipe on any modern server
hardware.

> Again, a key idea, probably the most important one, that I would like to
> see in our final wire protocol is that framing (i.e. "Here is where the
> bytes are") is done in an efficient - binary or very terse text - form,
> while structure and routing (i.e. "Here is what the bytes mean, and here
> is where they're going") is done in XML. The former gets us key
> efficiency gains, while the latter gives us the extensibility and
> portability we want from XML.

I'm all for the framing and the gains therein, and I'm also strongly for
balancing it out with the simplicity of the existing techniques.

Jer





More information about the Standards mailing list