Re: [hybi] DNS SRV for WebSocket

[Iñaki Baz Castillo <[e-mail]>]

2011/3/29 Roy T. Fielding <[e-mail]>:
> There are many ways to do load balancing -- DNS is just one.

So cheeaper as DNS SRV? based on a standard as DNS SRV?


>>> So the problem using SRV for ws is that ws starts with a HTTP connection,
>>> which may be existing and may be used for other HTTP requests if the
>>> handshake fails.
>> Right. Adam's going to hate me, but this would be a perfect use-case for a redirect.
>
> Indeed.

Does a 3XX redirect provide failover? No, it can provide just load-balancing.


>> But in any case, we can say that this is a MUST NOT. I appreciate this is somewhat bending the rules of HTTP compatibility, but I think it's worthwhile for the benefits that SRV records give.
>
> No, it isn't.  SRV has a benefit when there is one authority within
> the domain and that authority has control over DNS.

Sorry, but in most of the web deployments the author of the web site
also owns the domain so he is free to configure SRV records if he
wants. I can't see the problem.



>  Historically,
> that has not been the case for HTTP.  Web servers are not like email,
> xmpp, or sip.  They are very direct and anti-establishment.

If HTTP requires a new TCP connection for each request (or the exotic
and limited pipelined-mode of HTTP/1.1) then this is a limitation in
HTTP protocol (the same doesn't occur in other protocol better
designed as SIP-TCP or XMPP). Anyhow, the client must not perform a
SRV query for each connection, but just one at the beginning (to
resolve the domain).

But WebSocket is a new protocol, is not? In fact, the client
establishes an unique TCP connection with the WS socket, just one.



> SRV was developed after HTTP and did not see any real deployment
> until well after 2616 was done.  In any case, it would not have been
> used by HTTP because a goal of web interaction is to have all of the
> instruction provided to the client up-front in order to minimize latency.

Again, the SRV query would be performed just *once*. That cannot
introcude noticeable latency.


> DNS load balancing is only minimally effective because the client has
> no choice but to make an initial DNS request (to be cached for the
> remainder of its uptime).

And what is the problem? why do you say "is only minimally effective"?
The client performs the SRV query at the beginning and internally
stores the result set. If a connection fails it then uses the next
rcached result to try the connection.


> Exactly, but email management is inherently centralized because of
> the authentication.  Likewise for XMPP and SIP.  And none of those
> are sensitive to per-interaction latency during the authentication phase.

SIP is not sensitive to per-interaction latency?


> Any service that relies on some form of centralized administration
> is a good match with SRV if and only if the service lookup is faster
> than the application requirements for user-perceived latency. The long
> tail of HTTP sites is not of that type.  Only a very few websites
> would gain any advantage from SRV, and those sites are already using
> CDNs and IP-based load balancing to do the same thing without any need
> for SRV.

As I've explained and detailed various times in this thread, the web
adminitrator could decide to use *OR NOT* DNS SRV records for the
ws:// uri. He could still set an IP (ws://1.2.3.4:80) so the client
shouldn't perform a SRV query. Or he could set a domain with no SRV
record (but just A).

So, what is the problem? SRV would be a perfect choice for many people
but you want to prohibit it just because it would be not so useful for
other people (even if they can just ignore and not use it in their
deployments). It would be fully optional from the admin and user
perspective. The website owner could decide to use SRV or not. The
only requeriment, of course, os that WS clients support it (and WS
clients are built in the web browsers, so that shoud not be a
problem).



-- 
Iñaki Baz Castillo
<[e-mail]>