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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf