[whatwg] WebSockets: UDP

On Wed, 02 Jun 2010 00:34:17 +0200, James Salsman <jsalsman at gmail.com>  
wrote:


> 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.
>

No it can't be UDP, it'll have to be something layered on top of UDP. One  
of the game guys I spoke to last night said "Honestly, I wish we just had  
real sockets.  It always seems like web coding comes down to reinventing a  
very old wheel in a far less convenient or efficient manner." To some  
extent I agree with him, but there's the security aspect we have to take  
into account or we'll see someone hacking the CNN website and injecting a  
little javascript and we'll have the DDOS attack of the century on our  
hands.

The reason I put down "Socket is bound to one address", "Reliable  
handshake", "Reliable close handshake" and "Sockets open sequentially" was  
for that exact reason, to try to make it "DOS and tamper safe". The  
"Sockets open sequentially" means that if you allocate two sockets to the  
same server the second socket will wait for the first one to complete its  
handshake before attempting to connect.

The cap on the number of connections is probably less important, but  
browser vendors will likely want to have some sort of limit in place  
before it completely starves the OS of resources.

-- 
Erik M?ller
Core Developer
Opera Software

Received on Tuesday, 1 June 2010 23:34:49 UTC