Subject: Re: [hybi] Binary/Text Distinction

From: "Bob Gezelter" <[email-masked]>
Date: Tue, 23 Aug 2011 03:51:17 -0700

Inaki,

With regards to SCTP, I have long ago noted that absent the
HTTP-specific handshaking and the discrete places where ports 80/443 and
their corresponding schemes are specified, there is no technical
connection or dependency on TCP (my article this past March noted that
one could easily and [emphasis] virtually transparently to the end user
[end emphasis] implement the WebSocket protocol over an SCTP transport
using a different scheme (e.g., "wsc:/wssc:" instead of "ws:/wss:"). In
that way, applications code would only need a small change in URLs
(which could be handled by DNS records or redirects), the meat of the
work would be in the WSAPI-level code.

With regards to XMPP, if there are assumptions about TCP delivery of
data other than a stream, the implementation is certainly severely
broken. One of the first things I learned about TCP connections is that
any resemblance between packets and the chunks that data is received
instantaneously is purely coincidence and cannot be relied upon.

- Bob Gezelter, http://www.rlgsc.com

> -------- Original Message --------
> Subject: Re: [hybi] Binary/Text Distinction
> From: Iñaki_Baz_Castillo <[email-masked]>
> Date: Tue, August 23, 2011 3:40 am
> To: Tobias Oberstein <[email-masked]>
> Cc: Brian <[email-masked]>, "[email-masked]" <[email-masked]>, 
> Bjoern Hoehrmann <[email-masked]>, Bob Gezelter <[email-masked]>
> 
> 
> 2011/8/23 Tobias Oberstein <[email-masked]>:
> >> >  Existing non-browser applications have TCP at their disposal directly
> >> > and can use it how they see fit.
> >>
> >> That's wrong IMHO. TCP is not a friendly protocol for high-level developers
> >> since TCP is not message boundary. There are lot of buggy programs
> >
> > use SCTP .. it has messages and multiplexing
> 
> Yes, I know SCTP, and I also know that it's a transport protocol just
> present in big telephony providers networks for carrying ISUP or SIP
> protocols and intercommunicate with other providers. So I don't think
> we should suggest "use SCTP" in this thread.
> 
> 
> >> implementing a protocol on top of TCP because the author expected that a
> >> received TCP package must contain an entire application level message (and
> >> no more).
> >
> > I assume you mean "TCP packet" .. but even then, there are only TCP segments
> > and IP packets.
> 
> My fault.
> 
> 
> > If you want framing on TCP, use something that even was triggered by your
> > "security concerns"
> >
> > http://cr.yp.to/proto/netstrings.txt
> 
> I was asking for nothing, neither SCTP neither a framing solution for
> TCP. I was describing existing issues when a lazy developer tries to
> implement a *already* given protocol (so forget netstings stuff) on
> top of TCP. For example, there are some XMPP clients assuming that a
> TCP packet must contain an entire XMPP message (and just one).
> 
> 
> 
> 
> >> So, assuming that WebSocket must be designed just considering JavaScript is
> >> a very very wrong asumption IMHO.
> >
> > Who said "only"?
> 
> Extracted from the last mail of Brian in this thread:
> 
> > The entire purpose for the WebSockets protocol from the beginning was explicitly to allow *browsers* to use a real-time bidirectional socket connection in a JavaScript environment.
> 
> 
> 
> 
> >> Am I really the only one assuming that WebSocket is the perfect protocol for
> >> those NON-web-browsers applications (think in smartphones
> >> please) which currently use HTTP for communicating with the server?
> >
> > What serialization format will probably be the most widely used for JS _and_
> > "native" clients alike? If I had to make a bet, it would be JSON. You can
> > have your HTML5 frontend _and_ your native frontend talk to your
> > servers over the same transport/serialization.
> 
> I don't care which serialization format "native" clients would choose
> for use within WebSocket protocol. Why is that important? I just meant
> that, IMHO, WS is a perfect choice for a "generic" application (out of
> a web page) communicating with a server which usually servers web
> pages.
> 
> 
> Regards.
> 
> 
> -- 
> Iñaki Baz Castillo
> <[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 23 Aug 2011 13:13:08 +0200

> work would be in the WSAPI-level code.

I don't think the URI schema should represent the transport to use.
When it ends in "s" (wss, sips, https) it means "use security" which
is not a transport itself, but an extra layer (i.e. TLS) on top of a
real transport protocol (i.e. TCP, SCTP).

In case of SIP, the transport is given in a URI parameter:

1) Use TCP to contact the destination:

  sip:[email-masked];transport=tcp

2) Use TLS over TCP to contact the destination:

  sips:[email-masked];transport=tcp

> instantaneously is purely coincidence and cannot be relied upon.

Sure.

Regards.

-- 
Iñaki Baz Castillo
<[email-masked]>