[ should we leave ietf@xxxxxxxx in CC or not ? I'm suspecting that people who read this address will quickly get bored by hybi traffic ] On Sun, Jul 24, 2011 at 10:35:45AM +0100, Dave Cridland wrote: > You're saying that you have a nebulous connection thing, that you > pump HTTP requests down, and you may want to use that for WebSocket > upgrade requests as well, by taking the ws URI and performing a > simple transformation on it into an HTTP URI to make the upgrade > request on. > > So, given ws://example.com/foo/bar, you'll make the upgrade request > on http://example.com/foo/bar No I'm not saying that because I don't understand what you mean here. What I'm saying is that browsers try to reuse existing connections to host:port. So if you want to connect to ws://example.com/foo/bar and the browser already has a connection to example.com:80 because of a previous HTTP request to that host, it's much advantageous for it to reuse that existing connection. Making an additional DNS request and a connection come with a cost. In mobile environments, it's not uncommon to see 300-500 ms RTT. This means that performing the additional DNS request could cost up to one extra second. > What Iñaki and I are arguing for is that for WS, there is simply one > additional step prior to finding a suitable connection, which is > performing an SRV lookup/selection. That's clearly what I understood. > And this new step can actually be performed before any of the HTTP > connection steps. So, roughly, in order to "do" WebSocket for > ws://example.com/foo/bar you would first do SRV lookup, which would > give you an equivalent HTTP URI to perform the upgrade request. So > for example, if you got: > > _ws._tcp.example.com SRV 1 0 ws.example.com > > You'd make the upgrade request on the HTTP URI of: > > http://ws.example.com/foo/bar > > Of course, if this failed to connect, you can find another HTTP URI > to try - something you cannot do without SRV. If the connection fails here, HTTP will fail too, and right now, people don't use SRV records with HTTP. I'm not judging whether it's good or bad, I'm just saying what I'm seeing. Instead, people are using load balancers, BGP and DNS mechanisms to ensure their site is available. So whatever principle they're currently using with HTTP will also provide the same mechanism for free to WS. Yes it could be nice to have SRV on both HTTP and WS, but we need to make it adopted for HTTP first. And if it's not adopted at all in the case of HTTP, probably that is because it's not perceived as bringing a lot of benefit *for that specific usage*. Instead it may even add one DNS round trip which clearly is not desirable with highly interactive protocols such as HTTP. Also, the notion of "failure to connect" is hard to qualify in interactive environments. If my browser tries to connect and waits more than a few seconds before retrying on another server, I will probably already have pressed the Esc key. We all do that when clicking links on Google search results : if you don't get a result in one second, you click another one. It is not reasonable to use even lower timeouts when using SRV records, because it happens quite often to lose packets on the net, and sometimes it's the client side which is slow. If the browser decides to fail within one second and try another host, it will experience very frequent difficulties. Client-based failover (what SRV or MX are) is nice with protocols that can wait long enough to ensure the server is dead. Some mailers try to connect for one minute or even more. At that point, the client is certain that the server is dead. In a browser, nobody waits that long, so giving such a verdict is quite hard. Still, I think that SRV might be used for site failover, it will be a lot cleaner than using very short TTLs as some are doing. Such a usage is compatible with deployed infrastructures, because nothing prevents a client from prefering an SRV record over a CNAME record. Now with that in mind, I don't see how one could suggest a MUST for this. MUST that don't directly come from absolute requirements are never 100% respected and cause much more trouble than SHOULD which are recommended for optimal usage. If we say SHOULD, sites will ensure they have a working DNS config which always announces valid addresses in A/AAAA or CNAME and that SRV is used for failover. If we say MUST, sites won't bother emitting correct addresses in A/AAAA or CNAME, or will even announce different ones, and we'll get a lot of trouble at many places where the wrong record will be picked by proxies or by clients which can't use SRV for whatever reason. Regards, Willy _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf