[standards-jig] JEP 65 - Bytestreams
temas at box5.net
Fri Dec 20 02:05:42 UTC 2002
On Fri, Dec 20, 2002 at 01:59:04AM +0100, Tijl Houtbeckers wrote:
> 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
This is understandable and I'm sure diz could make this more clear.
> >|>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.
Let's not take this over the top. Let's stay on the protocol =)
> >| 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
As it stands (from a rough count of hands raised) the council would go
with bytestreams, but I honestly don't want to vote on something that
people are still arguing about. Especially if someone has a good point.
Now, you suggest that -65 "(very) poorly" handles one side being NATted.
Could you expand on this? I'm not sure I see where that comment is
coming from, but if it is founded, we don't need a vote yet.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the Standards