2011/7/21 David Endicott <dendicott(_at_)gmail(_dot_)com>:
Yes, those are all excellent reasons to use DNS SRV. None of them are a
reason to mandate that WS require it. Because something is good for some
(or many) use cases, does not mean it is appropriate for everything and
certainly is not a reason to mandate it as a requirement.
Hi David, I will be away for some days until I can read all the new
mails in this thread (I'll do it and will reply in a few days).
In the meanwhile I strongly ask you to read the draft about DNS SRV in
WebSocket:
http://tools.ietf.org/html/draft-ibc-websocket-dns-srv-02
Sepecially some sections:
1. Introducion
[...]
DNS SRV mechanism facilitates network applications scalability
without requiring an intermediary node distributing the traffic in
load-balancing or failover fashion. Instead, DNS SRV mechanism just
requires a proper DNS setup.
By introducing DNS SRV records into WebSocket protocol
[I-D.ietf-hybi-thewebsocketprotocol], WebSocket providers can,
optionally, take same advantages and provide scalable services with a
minimal infrastructure.
This specification mandates the usage of DNS SRV resource records by
WebSocket clients when resolving a "ws:" or "wss:" URI [RFC3986], but
still leaves the decision of using SRV records up to the service
administrator.
3. Implementation
[...]
It is up to the system administrator whether to set, or not, DNS SRV
resource records for the WebSocket protocol within the provided
service. This specification allows the system administrator to use
the DNS SRV [RFC2782] mechanism to improve the service reliability by
providing load-balancing and failover capabilities, but does not
mandate it (the system administrator could choose whichever
scalability strategy).
Section 4 "Client Usage" in which is shown how the WS client should
perform SRV resolution just in case the WS URI is a domain and no port
is present in the URI:
To clarify it, a WebSocket URI like "ws://example.org/myservice"
requires the client to perform SRV resolution while
"ws://example.org:80/myservice" does not (as the port is explicitly
present in the URI).
step 3: If there is no SRV result, attempt the fallback process described
in Section 4.2 and omit next steps.
4.2. Fallback Process
The fallback process SHOULD be a normal A or AAAA address record
resolution to determine the IPv4 or IPv6 address of the URI host
component (or URI host value without DNS resolution if it contains an
IP address).
The server connection port is obtained as stated in Section 3.1 of
[I-D.ietf-hybi-thewebsocketprotocol].
NOTE: The section 3.1 has changed in the new WS draft. It pointed to
http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-06#section-3.1
(3.1. Parsing WebSocket URIs)
Also, the section 5 (Examples) should clarify it even more.
Regards.
--
Iñaki Baz Castillo
<ibc(_at_)aliax(_dot_)net>
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf