Tue, Aug 22, 2006 at 09:54:05AM -0400, Hussam Shalaby wrote:
Hi,
I am using wildfire (freeware version) server, I tried different
message sizes and got a limitation of message l ength (7950), Is This XMPP
protocol limitation or a server issue?
Thanks

The protocol itself does not limit the size, but allows servers to have
their own limits for protection reasons. It however says the protocol is
optimized for small stanzas. Recommended size is <4k for instant
messaging.

Tue, Aug 22, 2006 at 05:18:11PM +0300, Joonas Govenius wrote:
8/22/06, Michal vorner Vaner <michal.vaner (AT) kdemail (DOT) netwrote:
>The protocol itself does not limit the size, but allows servers to have
>their own limits for protection reasons. It however says the protocol is
>optimized for small stanzas. Recommended size is <4k for instant
>messaging.

Has anyone actually tested this? Also, what's not "instant messaging"?

I had to resort to transfering images in a very similar way to IBB
(JEP-0047) in my whiteboard solution. I'm encoding the image in base64
and splitting the data over several messages if necessary. What
fragment size would you recommend in this case? I could imagine
sending a smallish, say 200KB, image in 4KB fragments causing much
more load on the server than sending it in 50KB fragments for example.
That's just my guess though. Does anyone know better?

If you read the XMPP-CRE, you will see it is possible to use to many
other things like distributed computing, gaming, whatever. It is not the
jabber as is known by user and usually is not used by people directly
and in that case you use different server, probably your own, where you
have different policies for stanza sizes.

Your whiteboarding is IM, since it uses the same servers.

About sending the image, I would recommend using something like stream
initiation (jep-0095), since you can open outbound stream which is much
less data consuming, and use inbound only when necessary. Because, if
you send that 200kB image, you will probably exceed not only the message
size (which you can solve by splitting it), but as well will get a karma
limit and you will be blocked for a while before the rest will be sent
out. Transfer of such image will take several seconds on most servers
out there. For example, default setup of ejabberd allows something like
7kB/s for a single user.

Joonas Govenius wrote:
8/22/06, Michal vorner Vaner <michal.vaner (AT) kdemail (DOT) netwrote:
>The protocol itself does not limit the size, but allows servers to have
>their own limits for protection reasons. It however says the protocol is
>optimized for small stanzas. Recommended size is <4k for instant
>messaging.

Has anyone actually tested this? Also, what's not "instant messaging"?

IIRC, we debated whether we wanted to recommend a maximum stanza size in
RFC 3920 or RFC 3921, but decided against it.

I had to resort to transfering images in a very similar way to IBB
(JEP-0047) in my whiteboard solution. I'm encoding the image in base64
and splitting the data over several messages if necessary. What
fragment size would you recommend in this case? I could imagine
sending a smallish, say 200KB, image in 4KB fragments causing much
more load on the server than sending it in 50KB fragments for example.
That's just my guess though. Does anyone know better?

>From the perspective of XMPP messaging, 200K is not smallish.

Perhaps some server developers could come up with recommended sizes as a
best practice.

Peter

Tuesday 22 August 2006 17:53, Peter Saint-Andre wrote:
Perhaps some server developers could come up with recommended sizes as a
best practice.

I'd be also interested in setting up the stanza maximum size somehow as a
stream feature. This is due to the technical constrains of the application's
environment. Since there is no upper-bound limit defined, I can't know for
sure that servers will *always* choose something lower than my desired value.

It would also be useful for clients if servers could advertize somehow their
default-maximum-stanza-size.

Mircea

Wed, Aug 23, 2006 at 12:28:44AM +0300, Joonas Govenius wrote:
>About sending the image, I would recommend using something like stream
>initiation (jep-0095), since you can open outbound stream which is much
>less data consuming, and use inbound only when necessary.

Stream Initiation provides a way to negotiatie streams "between any
two entities". That leaves two options for a multiuser case:

1. The sender negotiates a stream with each of the other participants
in the sessions and sends the image to each seperately.

And you do not send the messages with data to all of them? I know, there
is multicast component, but it is not much used in the wild. I did not
met a server that had said component.

2. Serverside support: the sender negotiates a stream with the server
and the server negotiates a stream with each of the other
participants.

1 doesn't seem feasible and option 2, well, requires serverside
support

Additionally, a central idea in the whiteboard protocol I'm using is
that each participant has an equivalent copy of the whiteboard's
contents. That would break if the stream negotiation fails with one of
the participants.

>Because, if
>you send that 200kB image, you will probably exceed not only the message
>size (which you can solve by splitting it), but as well will get a karma
>limit and you will be blocked for a while before the rest will be sent
>out. Transfer of such image will take several seconds on most servers
>out there. For example, default setup of ejabberd allows something like
>7kB/s for a single user.

That's too bad, but if the messages do eventually get delivered, it's
tolerable. I haven't figured out better way to do it without
serverside support.

Hm, you could send something like "Place a picture here, it will be this
large and I will send it out of bound" using jabber and then transfer
the image itself somehow outside, like the SI, or, we have jingle
already, right? Google talk uses it to file transfers, so it could be
used somehow for these images as well (they said they will have some
example of tcp-like over jingle in next version of libjingle).

The client would draw something like an empty frame before the image is
available to show there is something, like a web browser.

Like Peter said, it would be interesting if server developers could
propose some recommended sizes.

Joonas

Wed, Aug 23, 2006 at 12:28:44AM +0300, Joonas Govenius wrote:
>About sending the image, I would recommend using something like stream
>initiation (jep-0095), since you can open outbound stream which is much
>less data consuming, and use inbound only when necessary.

Stream Initiation provides a way to negotiatie streams "between any
two entities". That leaves two options for a multiuser case:

1. The sender negotiates a stream with each of the other participants
in the sessions and sends the image to each seperately.

And you do not send the messages with data to all of them? I know, there
is multicast component, but it is not much used in the wild. I did not
met a server that had said component.

2. Serverside support: the sender negotiates a stream with the server
and the server negotiates a stream with each of the other
participants.

1 doesn't seem feasible and option 2, well, requires serverside
support

Additionally, a central idea in the whiteboard protocol I'm using is
that each participant has an equivalent copy of the whiteboard's
contents. That would break if the stream negotiation fails with one of
the participants.

>Because, if
>you send that 200kB image, you will probably exceed not only the message
>size (which you can solve by splitting it), but as well will get a karma
>limit and you will be blocked for a while before the rest will be sent
>out. Transfer of such image will take several seconds on most servers
>out there. For example, default setup of ejabberd allows something like
>7kB/s for a single user.

That's too bad, but if the messages do eventually get delivered, it's
tolerable. I haven't figured out better way to do it without
serverside support.

Hm, you could send something like "Place a picture here, it will be this
large and I will send it out of bound" using jabber and then transfer
the image itself somehow outside, like the SI, or, we have jingle
already, right? Google talk uses it to file transfers, so it could be
used somehow for these images as well (they said they will have some
example of tcp-like over jingle in next version of libjingle).

The client would draw something like an empty frame before the image is
available to show there is something, like a web browser.

Like Peter said, it would be interesting if server developers could
propose some recommended sizes.

Joonas

Ralph Meijer wrote:
Wed, 2006-08-23 at 09:29 +0300, Mircea Bardac wrote:
>Tuesday 22 August 2006 17:53, Peter Saint-Andre wrote:
Perhaps some server developers could come up with recommended sizes as a
best practice.
>I'd be also interested in setting up the stanza maximum size somehow as a
>stream feature. This is due to the technical constrains of the application's
>environment. Since there is no upper-bound limit defined, I can't know for
>sure that servers will *always* choose something lower than my desired value.
>>
>It would also be useful for clients if servers could advertize somehow their
>default-maximum-stanza-size.

I suggest using Service Discovery for this. It might be useful to
provide a standard form field for this. That should be discussed on
standards-jig.

We can add this to JEP-0128.

Peter