Re: [hybi] [Editorial Errata Reported] RFC6455 (3473)

[Salvatore Loreto <[e-mail]>]

the original idea was to serialize the tentative to connect to the same 
IP address (especially in
the case several /host/ names share the same IP address);
IMO it becomes clear if you read the second paragraph of the bullet #2 
and the NOTE.


    2.  If the client already has a WebSocket connection to the remote
        host (IP address) identified by /host/ and port /port/ pair, even
        if the remote host is known by another name, the client MUST wait
        until that connection has been established or for that connection
        to have failed.  There MUST be no more than one connection in a
        CONNECTING state.  If multiple connections to the same IP address
        are attempted simultaneously, the client MUST serialize them so
        that there is no more than one connection at a time running
        through the following steps.

        If the client cannot determine the IP address of the remote host
        (for example, because all communication is being done through a
        proxy server that performs DNS queries itself), then the client
        MUST assume for the purposes of this step that each host name
        refers to a distinct remote host, and instead the client SHOULD
        limit the total number of simultaneous pending connections to a
        reasonably low number (e.g., the client might allow simultaneous
        pending connections to a.example.com and b.example.com, but if
        thirty simultaneous connections to a single host are requested,
        that may not be allowed).  For example, in a web browser context,
        the client needs to consider the number of tabs the user has open
        in setting a limit to the number of simultaneous pending
        connections.


        NOTE: This makes it harder for a script to perform a denial-of-
        service attack by just opening a large number of WebSocket
        connections to a remote host.  A server can further reduce the
        load on itself when attacked by pausing before closing the
        connection, as that will reduce the rate at which the client
        reconnects.



-- 
Salvatore Loreto, PhD
www.sloreto.com



On 2/5/13 3:00 PM, Martin Thomson wrote:
>
> That is approximately where my reasoning lead. I think that the *safe* 
> option is to have one connection per name.
>
> On Feb 4, 2013 3:20 AM, "Adam Rice" <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     On 1 February 2013 23:27, Martin Thomson <[e-mail]
>     <mailto:[e-mail]>> wrote:
>
>         Is this "host and port" or "IP and port" ?  That too is
>         unclear.  If
>         I'm sharding a.example.com <http://a.example.com> and
>         b.example.com <http://b.example.com> and they are served on
>         the same VIP, is the expectation that wss://a.example.com/
>         <http://a.example.com/> and
>         wss://b.example.com/ <http://b.example.com/> can't have
>         concurrent connection attempts?
>
>
>     I was assuming that in the first sentence the text "connection to
>     the remote host (IP address) ... even if the remote host is known
>     by another name" made the interpretation of "IP address" unambiguous.
>
>     But section 4.1 says that /host/ is defined in section 3, and
>     section 3  actually defines /host/ as "host = <host, defined in
>     [RFC3986], Section 3.2.2
>     <http://tools.ietf.org/html/rfc3986#section-3.2.2>>", ie. the host
>     portion of the URI.
>
>     So now I don't know.
>
>
>
> _______________________________________________
> hybi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hybi