[whatwg] WebSockets: UDP

[James Salsman]

I agree UDP sockets are a legitimate, useful option, with applications
far beyond games.  In most cases TCP is fine, but adaptive bit-rate
vocoders, for example, can use packet loss as an adaptation parameter,
and chose only to retransmit some of the more essential packets in
cases of congestion.  I am not suggesting that javascript applications
should implement adaptive bit-rate vocoding (until a fast
cross-platform javascript signal processing library is developed, if
then) but there are reasons that a web application might want to send
both reliable and unreliable traffic; most all of them having to do
with adapting to bandwith constraints.

On Tue, Jun 1, 2010 at 8:52 AM, John Tamplin <jat at google.com> wrote:
>
>... How would proxies be handled?

UDP is supposed to never be buffered, not even by proxies. Proxies are
supposed to simply forward UDP without logging.  Lots of them don't
forward any UDP, and alot of them probably log the traffic.

> Even if specs were written and implementations available, how many years
> would it be before corporate proxies/firewalls supported WebSocket over UDP?

Maybe UDP adoption would follow adoption of SIP and RTP.  Has anyone
measured the current rate of UDP transmission availability from the
typical corporate client host?

On Tue, Jun 1, 2010 at 1:02 PM, Erik Möller <emoller at opera.com> wrote:
>....
> what would the minimal set of limitations be to make a "UDP WebSocket" browser-safe?
>
> -No listen sockets

For outgoing-from-client UDP, client-initiated TCP streams for
incoming responses and packet acknowledgment may be maximally
NAT-safe.

> -No multicast

People will eventually ask for it, but forwarding to it through
servers known to be free from NATs is preferable.

> -Reliable handshake with origin info

Nothing about UDP is reliable, you just send packets and hope they get there.

> -Automatic keep-alives

You mean on the incoming-to-client TCP channel in the opposite
direction from the UDP traffic?

> -Reliable close handshake

Can we use REST/HTTP/HTTPS persistent connections for this?

> -Socket is bound to one address for the duration of its lifetime

That sounds reasonable, but clients do change IP addresses now and
then, so maybe there should be some anticipation of this possibility?

> -Sockets open sequentially (like current DOS protection in WebSockets)

Do you mean their sequence numbers should be strictly increasing
incrementally until they roll over?

> -Cap on number of open sockets per server and total per user agent

There was some discussion that people rarely check for the error
condition when such caps are exausted, so I'm not sure whether that
should be the same as the system cap, or some fraction, or dozens, or
a developer configuration parameter.