On Sun, Jul 24, 2011 at 01:26:53PM +0200, Iñaki Baz Castillo wrote: > 2011/7/22 Willy Tarreau <w@xxxxxx>: > > Iñaki, what we're saying is that the resolving applies first to HTTP > > well before it is WS. For instance, a client could connect to an HTTP > > server, fetch a few objects, then decide to upgrade the connection to > > switch to WebSocket. DNS resolving for WS would not even be involved > > here. > > Hi. Maybe I'm the only who assumes that, usually, the WS server is not > colocated within the initial web server. Web-based infrastructures make that almost mandatory at the frontend, especially in massive hosting where you don't want to multiply IP addresses. In general you have one single point which handles the IP:port and which dispatches that to many servers based on the Host header, URI, file names, cookies, etc... > This is, your text below is valid just in the case I browse a web page > in http://some-domain.org (so port 80) and retrieve a WS URI to > connect to ws://some-domain.org (so also port 80). In that case you > say that the http/ws client would decide to upgrade the connection so > "it must assume that the WS handshake must be sent to the same IP:port > resolved for the HTTP communication". > > I don't agree with yout point. Doing the "upgrade" does not mean > reusing an existing TCP connection (in which HTTP took place) for > other purpose. Huh ? > Instead, doing the WS upgrade means opening (or > reusing) a TCP connection, sending a HTTP GET with special semantics, > expect 101 and then start a bidirectional frame-based communication. I still remember how the handshake works, thank you. > So sending the GET with "upgrade" has nothing to do with any previous > HTTP communication with the HTTP server. Yes it has. Either you open a fresh new connection, or you reuse an idle existing one. But to know that the connection is idle, you must understand the protocol that was spoken on it and this protocol must have clearly delimited messages. HTTP supports reuse of connections (also called "keep-alive") and since the WS handshake is HTTP, it is possible and I'd add even recommended to reuse an existing connection to send a WS handshake, if one such connection exists. > > I agree with what others have been saying : if/when a different handshake > > is supported, eg. on a specific port without the HTTP upgrade, then it > > will make sense. > > Do you mean WS as a complete separate protocol running on a specific > WS port and so? I'd really would like it (rather than the exotic > pseudo-HTTP mechanism used right now), but I expect it will never > happen. I'm sure it will happen. We need applications to be developped using WS first. But there are places where : - HTTP compatibility won't be needed - masking will be annoying - HTTP overhead will be too much - HTTP round trip will be too much I think that this will happen as soon as a working proposal for TLS NPN appears, because the same requirements will exist (eg: how to specify the resource name in a simpler way, etc...). Right now we need WS to be able to replace long polling mechanisms which already work over HTTP, so if we want it to be adopted, we need to deploy where previous methods used to work. You just need to be patient :-) > > But as of now we're relying on the lower layer. As Greg > > said it, without a deep change in HTTP you won't be able to make the rule > > a MUST for WS. However, John's suggest of using a SHOULD when the record > > exists and the client can see it looks fine. What's the problem if not all > > of your clients go to the same hosts ? You can even announce all of your > > servers with A/AAAA and with SRV as well as long as they're running on the > > same ports. Those who can use SRV just have more information than the other > > ones and can be served better. > > Having multiple A/AAAA records for a single domain does not provide > failover (as clients usually take just the first IP). I see your > point, but I expect no success at all. That's not what I'm saying. Right now, people are using A/AAAA with short TTLs and are updating the zones when a site fails (when I mean a site, I mean a datacenter). This is something which happens rarely enough to be acceptable. Using fast DNS updates for server failover does not work because caches are everywhere and experience shows that even after one month you still receive traffic on a server you've stopped announcing. However, please read what I've explained in another mail about the limitations of client-based failover in web environments. Regards, Willy _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf