[standards-jig] JEP 65 - Bytestreams

Tijl Houtbeckers thoutbeckers at splendo.com
Fri Dec 20 00:59:04 UTC 2002


Ben Schumacher <ben at blahr.com> wrote on 20-12-2002 0:55:07:
>
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>The 'connect in both directions simultaneously' mechanism does not
>ensure that the TCP connection sets up quickly, just like Diz said.
>Actually, on low bandwidth connections (maybe even the hardware in
>embedded systems -- I don't have enough experience with these), I
>wouldn't be surprised if it slows down the amount of time it takes to
>establish a TCP connection.

Many embedded systems will prefer to set up a bytestream inband cause 
of this overhead. Neither JEPs address this but at least DTCP doesn't 
claim to be "A protocol for establishing bytestreams between any two 
Jabber entities.". JEP-0065 is *not* a generic way of setting up 
bytestreams, just bytestreams over sockets. IMHO the JEP should reflect 
this! It should be changed to SOCKS5 based, socket based or TCP based 
bytestreams. 

>
>|>NO JEP THAT WE WRITE CAN PROVIDE ANY GUARANTEE AROUND HOW LONG A USER
>|>WILL WAIT FOR A CONNECTION TO BE ESTABLISHED.
>|
>| No safety system can provide any guarantee that people survive a car
>| accident. But cars contain airbags and even much more complex 
>systems, | which make a car more difficult to 'implement'...
>
>I don't understand your logic, or Justin's, for that matter. You have
>both regularly stated that DTCP is an easier protocol to implement, yet
>you continually reject complaints from *client developers* that 
>disagree (namely, PGM and DizzyD).

Well, I'm not sure about Jan actually, but I'm "pretty convinced" that 
Justin is a very capable client developer. Without Psi I doubt I would 
be using Jabber on any desktop system. Let's not get down to the point 
where we have to start saying "but I'm a client developer!" cause I am 
a client developer too, maybe you are, and I'm sure that so are many 
many more on this list. 

>| In the end, this is a philosophical question - we could argue 
>endlessly | if it's more important to have a nice protocol, or if we 
>should | sacrifice some elegance in favor of people with broken setups.
>| So let's not hold up adoption of a standard because of this issue.
>
>I agree. I say let both JEPs move forward as they are (as PSA has
>already proposed), and let the council decided ultimately which JEP 
>they feel is the more technically sound solution.

Then let the council note that DTCP set out to solve (among other 
things) the situation where 1 peer is behind a NAT, since this is one 
of the most common problems concerning filetransfer, and that JEP65 
addresses this (very) poorly compared DTCP. And should JEP65 be 
accepted without addressing this problem correctly than we're still 
left with this problem, and we'll still need for a standard for it. 
Also let the council be aware that neither JEP solves the problem of 
setting up a generic bytestream ;) 

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




More information about the Standards mailing list