[3][standards-jig] NEW JEP: Inband Bytestream (JEP-0047)

Tijl Houtbeckers 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 
> are 
>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 :) 

Tijl Houtbeckers
Java/J2ME/GPRS Software Engineer @ Splendo
The Netherlands

More information about the Standards mailing list