On Sun, Jul 24, 2011 at 08:24:25PM +0200, Iñaki Baz Castillo wrote: > > Yes it has. Either you open a fresh new connection, or you reuse an > > idle existing one. > > If the WS URI points to a different server, it's perfectly possible > that the WS connection has nothing to do (neither cookies usage) with > the previous HTTP/HTML traffic. I just meant it. I agree, and there will certainly be a large number of cases where it will be different. But that's not enough (in my opinion) to make something mandatory considering the negative side effects. > > 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. > > Don't take me wrong, but "keep-alive" mechanism in HTTP is just a hack > since paralelism is not possible (well, it's but with too many > constrains, for example the server must send the replies in order). Pipelining improves things a lot, especially for static objects which immediately fill the pipe. > In > other protocols working on top of TCP (as SIP) each request contains > an id (in the case of SIP the Via branch) which allows identifying > which request a response belongs to, so I can send N requests via the > same TCP connection and receive the responses in any order. >From what I've read, SPDY typically addresses this point. > HTTP is poor on this topic, and I wouldn't like WS to inherit it. But it will since there is no MUX support yet, WS frames will be delivered in order. The application on top of WS might decide to number each message though and use its own out-of-order mechanism though. > >> 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 :-) > > ok, I like what you say :) > However, imagine that in next 2 years there are a lot of WS servers > speaking HTTP (for the WS handshake, of course). If you suggest that a > different WS protocol could appear, it would require a new URI schema > so the client knows wheter to perform a HTTP WS handshake or use the > new WS protocol. That's just a minor detail. Likewise it will probably have to support a fallback to the HTTP handshake because there will be a lot of places where it will not pass through. > >> 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. > > And there is where DNS SRV could help a lot :) Not that much, because as soon as you fail your DC, you'll stop announcing it so that visitors don't try to connect there for seconds before they detect it's down. > > However, please read what I've explained in another mail about the > > limitations of client-based failover in web environments. > > Yes, I've read it. But I expect it's even more critical in a phone > call (my SIP phone performs SRV/A, gets the first IP:port and sends > the call request there using UDP, but the server is down, so after > some seconds *without hearing ringing* the phone sends the call to > another server). If it's not critical in SIP, why should it be so > critical in WS? As I said, having it in WS means having it in HTTP too. And having a browser rely on TCP connection timeouts to decide to use a server vs another one would make a lot of sites unusable. I've already been used to mark some advertiser's sites as 255.255.255.255 in my /etc/hosts to stop waiting for their crap to respond on pages that I'm used to visit. If a page loads objects from s1,s2,s3,s4.domain.tld and all are hosted both on a valid and a dead DC, it can take a lot of time before all these hosts are marked down and ignored. Nobody I know would wait for these to fail. > Also, if the user realizes that the connection takes too much time and > presses F5 to reload the page, why couldn't the webbrowser cache the > SRV results and mark the previous attemp as failed so next server:port > woul be tryed when the user presses F5? Yes but once again, if you have to wait one minute on each new site so that all dead servers can be ignored, the web will look like a terrible experience to you. Regards, Willy _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf