Re: [hybi] [whatwg] WebSockets: UDP

[Lars Eggert <[e-mail]>]

Hi,

on a purely managerial level, let me point out that this work is far beyond the current charter of the HYBI WG. This defines an entirely new protocol, and will definitely require a charter discussion.

(If there is community/developer interest, we should by all means have that discussion.)

Lars

On 2010-6-10, at 22:35, Erik Möller wrote:

> During the Opera Network Seminar held in Oslo this week I discussed the  
> possible addition of a new wsd: URL scheme to WebSockets that would allow  
> relaxing the packet resends and enable demanding real-time applications to  
> be written. I'd like to summarize some of the conclusions a few of us came  
> to when discussing this (informally).
> 
> Regarding the discussions on at what level the API of a UDP-WebSocket  
> should be: One of the most important aspects to remember are that for this  
> to be interesting to application developers we need all the browser  
> vendors to support this feature in a compatible way. Therefore it doesn't  
> seem reasonable to standardize and spec a higher level network API akin to  
> RakNet / Torque Socket and hope all vendors will be willing to spend the  
> (quite large amount of) resources required for their own implementation of  
> TCP over UDP, bandwidth throttling etc. In our opinion we're much better  
> off standardizing a minimal UDP-like socket. For most application  
> developers it seems likely they will be able to work with a mix of  
> XMLHttpRequest, WebSockets and this new UDP-WebSocket to achieve the same  
> functionality provided by those higher level APIs. If deemed necessary for  
> an application the higher level network API can be written in JavaScript  
> and work on-top of the much smaller hopefully cross-browser compatible  
> UDP-WebSocket API.
> 
> As discussed the following features/limitations are suggested:
> -Same API as WebSockets with the possible addition of an attribute that  
> allows the application developer to find the path MTU of a connected  
> socket.
> -Max allowed send size is 65,507 bytes.
> -Socket is bound to one remote address at creation and stays connected to  
> that host for the duration of its lifetime.
> -IP Broadcast/Multicast addresses are not valid remote addresses and only  
> a set range of ports are valid.
> -Reliable handshake with origin info (Connection timeout will trigger  
> close event.)
> -Automatic keep-alives (to detect force close at remote host and keep NAT  
> traversal active)
> -Reliable close handshake
> -Sockets open sequentially (like current DOS protection in WebSockets) or  
> perhaps have a limit of one socket per remote host.
> -Cap on number of open sockets per host and global user-agent limit.
> 
> Some additional points that were suggested on this list were:
> -Key exchange and encryption
>  If you do want to have key exchange and encryption you really shouldn't  
> reinvent the wheel but rather use a secure WebSocket connection in  
> addition to the UDP-WebSocket. Adding key exchange and encryption to the  
> UDP-WebSocket is discouraged.
> 
> -Client puzzles to reduce connection depletion/CPU depletion attacks to  
> the handshake.
>  If the goal is to prevent DOS attacks on the accepting server this seems  
> futile. Client puzzles only raises the bar ever so slightly for an  
> attacker so this is also discouraged.
> 
> -Packet delivery notification to be a part of the API.
>  Again this is believed to be better left outside the UDP-WebSockets spec  
> and implemented in javascript if the application developer requires it.
> 
> Best Regards,
> 
> -- 
> Erik Möller
> Core Developer
> Opera Software
> _______________________________________________
> hybi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hybi