Re: [hybi] Last Call: <draft-ietf-hybi-thewebsocketprotocol-10.txt> (The WebSocket protocol) to Proposed Standard

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

2011/7/22 Bruce Atherton <[e-mail]>:

> Oh, it isn't hard, but it violates the principle of least surprise. Most
> people think they know how to code name resolution by using gethostbyname()
> or equivalent.

Should a new protocol loose cool features just because "most people"
expect a domain to be mapped to a single IP always?


> And to do it efficiently, especially when we are operating in
> a world that is predominantly driven by HTTP servers, requires complexities
> like dealing with asynchronous calls to fetch the A and SRV records at the
> same time under the assumption that the SRV record probably won't exist.

You can do it serially (first SRV then A). We are speaking about a few
miliseconds just during the WS connection, no more. In SIP and XMPP
(real *realtime* protocols with IM and voice) this is not a problem.




> As I understand it, the issue that caused the various drafts for HTTP SRV to
> die without getting much traction is one of efficiency.

Could you point to any reference for such a conclusion?

I really think the problem of SRV in HTTP is the fact the HTTP was
already extended when SRV appeared and migration was unfeasible.


> It is inefficient to
> make all these extra DNS calls, especially when it is unlikely that many of
> the records you are blocking on will exist. Other than the inefficiency,
> HTTP SRV is just an incremental technology you add to your existing DNS
> without hurting what already exists. Since Websockets uses the same
> infrastructure the records are unlikely to exist for it either, so the
> inefficiency issues are still present.

How is possible that using DNS SRV (and also DNS NAPTR in SIP !!) is
not "inefficient" for SIP and XMPP ***realtime*** protocols?



Regards.


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