[Standards] Stanza Size Limits (was Re: [jdev] Communicate between two client instances of the same ID)
melo at simplicidade.org
Wed Sep 3 22:15:22 UTC 2008
On Sep 3, 2008, at 10:03 PM, Justin Karneges wrote:
> On Wednesday 03 September 2008 13:24:00 Pedro Melo wrote:
>> On Sep 3, 2008, at 8:29 PM, Justin Karneges wrote:
>>> This is more of a server limit though. The client still needs a
>>> way to
>>> negotiate its own limit, and have the server protect the client
>>> from stanzas
>>> larger than that limit.
>> ehe, Firewall XEP :).
>> What if your own server breaks that limit, for example, sending you
>> the roster? Peter would be in trouble... :)
> A hackish approach would be to make the roster iq-result exempt
> from limits.
> Long term, it's probably more appropriate to make the roster get
> sent as
> multiple stanzas if we wish to live by our "stanzas should be
> small" motto.
Yeah, the work on incremental rosters.
>> Servers already have Max stanza size on C2S and S2S. Do we really
>> need more protection than that?
> If you set a small value for the server policy then you'd be fine,
> but that's
> not very flexible. For example, most desktop clients are surely
> capable of
> handling a 1MB stanza, but for some reason you cap your server at a
> smaller 64KB. And even 64KB is probably too much for a mobile. So
> a flat
> maximum is not ideal.
Sure but as a server admin I would not admit a client negotiating a
larger stanza than my own C2S or S2S limits.
So if the limits for the desktop client will likely be larger than
those of [CS]2S, then there really is no need for this.
I agree that mobile clients will want to cap the stanza limit, but
this might be better end-to-end... Announce something via disco + IQ
The server itself can use the same process to figure it out what the
limit is and enforce it if likes.
>> Each time we had a error back to the sender, we increase
>> complexity on all
>> the clients. And some stanzas are really hard to break in two...
> Sure, but you already have this problem with server-imposed
> limits. The fact
> is, we have these limits, because we believe stanzas should be of some
> reasonable size. All of our XEPs that may return large data must
> have a way
> of being split. That's just a fact of life.
That's true. The limits are already there.
I think a <feature> in disco#info plus a IQ-based protocol would be
enough. Other entities (your own server, and other clients) can use
the same protocol to obtain the limits you are willing to accept.
XMPP ID: melo at simplicidade.org
More information about the Standards