[standards-jig] NEW JEP: Inband Bytestream (JEP-0047)
thoutbeckers at splendo.com
Mon Sep 30 12:39:13 UTC 2002
Justin Karneges <justin-jdev at affinix.com> wrote on 30-9-2002 13:59:43:
>> I want to remind the discussion of the karma settings, which can be
>> a very annoying issue for transmitting data as "inband" data.
>This is true, and has been considered. I did some tests today by
>simply sending large blocks of xml between two test clients (c2s2s2c).
> I can send 1024 characters from one client to another in about 2
>seconds, consistently. Assuming the overhead of base64, this probably
>amounts to a few hundred kilobytes per second on average. This is not
>very good, but it is better than nothing, which is the whole point.
I asume you mean a few hunderd bytes rather then kilobytes? If you send
too much data too fast Karma will give you even less bandwith then
normal. In your tests did you already wait for the ACK on your sequence
before sending the next? I think this would lessen the chance of
"overflowing" your karma limits.
Maybe waiting for the ACK before sending the next package should not be
an advise but a requirment as it would also solve out of order delivery
and it would enable the receiving party to control the rate of flow (eg
clients with little CPU/memory/bandwith to spare could slow down
delivery). Also when clients get disconnected or cancel the tranfer
there won't be any unnecessary packets send. On high karma servers it
might decrease the speed of inband transfers. But then again, inband
was never meant to be a speedy way of transfering. Overall I think it
would do more good then bad.
>Of course, a real socket relay server component would be more optimal.
> Unfortunately, it will be a long while before these types of things
>available widely. The best part about Inband Bytestream is that it
>will work anywhere right now, even with old servers.
Don't underestimate the usabilty for this addition. I've implemented
Jabber on more then 1 device that can only have 1 socket open at the
same time. They can already send small amouts of non-XML data to each
other inband, but I'd love to be able to use Psi to send them this kind
of data. Think of for example sending a ringtone or a logo to your
mobile phone using Jabber, with any Jabber client that supports this
>> We should at least keep Base-64. I think an addition to better
>> integrate it with something like your Stream Negotiation Protocol (is
>> there a JEP for it yet? or did it die a silent death?) is needed for
>> JEP-0047 in any case.
>JID Stream is what you are looking for, and is JEP-0041. It proposes
>a standard way of utilizing all of these various transport protocols.
Thanks, I haven't had that much time to follow the lists lately, it
looks great, and ofcourse the two JEPs are already integrated enough
with each other, sorry about that :)
Java/J2ME/GPRS Software Engineer @ Splendo
More information about the Standards