Re: [hybi] Extensibility mechanisms?

[Roberto Peon <[e-mail]>]

On Tue, Jul 20, 2010 at 3:14 PM, Ian Hickson <[e-mail]> wrote:

>
> (By the way, I spoke to Joe and he suggested that I post an e-mail to each
> thread to which I was replying, rather than replying to all threads in one
> bulk e-mail or replying to all the e-mails I'm replying to individually. I
> hope this compromise works for everyone; I know there was some controversy
> when I replied in bulk a few months ago. I apologise in advance if this
> causes a spike in traffic to the list.)
>
> On Mon, 19 Apr 2010, Roberto Peon wrote:
> > On Mon, Apr 19, 2010 at 2:20 AM, Julian Reschke wrote:
> > > > On 19.04.2010 10:48, Ian Hickson wrote:
> > > > >
> > > > > There are many many implementations of HTTP. Some fast, some not
> > > > > so.  Some complete, some not so.
> > > >
> > > > I think we can get orders of magnitude more complete implementations
> > > > of Web Sockets than of HTTP if we keep the protocol trivial.
> > >
> > > Yes. That's a given. Make it less complex, and it will be easier to
> > > completely implement.
> >
> > This isn't true! Make it (the protocol) less complex and it will be easy
> > to implement something which *conforms to the spec*, but not necessarily
> > something which scales and is robust, reliable, and scalable in the face
> > of all the stuff that happens out there.
>
> Not all implementations have to scale to a million QPS or withstand DDOS
> attacks for weeks at a time. Most implementations of Web Sockets will
> likely be for small amateur projects that are lucky if they average 1 QPH,
> let alone 1 QPS.
>
>
> > The latter part is what really worries me. We really need to be sure
> > that the protocol that we create allows for an implementation of a
> > server to do these things.
>
> I agree that we shouldn't make the protocol impossible to scale. If there
> are specific features in the protocol that make it impossible to scale,
> please do raise these as issues. However, one doesn't have to make a
> protocol complex to make it scale.
>

We need browser-owned connections with a security model that allows multiple
tabs to share the connection safely.
This is probably the most important requirement for scalability as far as
I'm concerned. This requires fewer keep-alives (both because of fewer TCP
connections and because the TCP connection is more likely to have real
content sent on it instead of near-zero value'd keep-alives), it requires
fewer file descriptors, it requires fewer handshakes.

-=R


>
>
> > If the (hopefully small) added complexity is too much for the amateur
> > programmer, then they should use the API level.
>
> What I'm interested in personally is writing a protocol that amateur
> programmers can implement easily. If we say they have to use someone
> else's code to do this, then that's a failure, IMHO. (Though as I've
> mentioned before, if people have different goals or priorities, I have no
> problem with separate protocols also being designed to address those --
> Web Sockets doesn't have to be everything for everybody.)
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>