Re: [whatwg] WebSockets: UDP
On Wed, 02 Jun 2010 00:34:17 +0200, James Salsman jsals...@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
Re: [whatwg] WebSockets: UDP
On Tue, Jun 1, 2010 at 11:34 PM, Erik Möller emol...@opera.com wrote: 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 To be clear, for games, the key win is the lossy delivery. That is what enables the game to make intelligent decisions about dealing with packet loss, out of order delivery, etc. There's actually someone who has already deployed a wide-scale UDP p2p negotiated connection architecture. Adobe launched their Stratus technology in 2008: http://labs.adobe.com/technologies/stratus/ The downside is they do not expose lossy message delivery to Player content, it's only used for audio/video delivery. However something like this that did expose lossy message delivery would be very handy! A lot of interesting applications could be built mostly independently of server, saving a lot of scalability pain. Ben
Re: [whatwg] [hybi] WebSockets: UDP
On Wed, 02 Jun 2010 01:07:48 +0200, Mark Frohnmayer mark.frohnma...@gmail.com wrote: Glad to see this discussion rolling! For what it's worth, the Torque Sockets design effort was to take a stab at answering this question -- what is the least-common-denominator webby API/protocol that's sufficiently useful to be a common foundation for real time games. I did the first stab at porting OpenTNL (now tnl2) atop it; from my reading of the RTP protocol that should easily layer as well, but it would be worth getting the perspective of some other high-level network stack folks (RakNet, etc). For those who missed Mark's initial post on the subject his TorqueSocket API can be found here: http://github.com/nardo/torque_sockets/raw/master/TorqueSocket_API.txt Perhaps we could communally have a look at how this compares to other common network libraries to find a least common denominator of functionality? Only feedback here would be I think p2p should be looked at in this pass -- many client/server game instances are peers from the perspective of the hosting service (XBox Live, Quake, Half-Life, Battle.net) -- forcing all game traffic to pass through the hosting domain is a severe constraint. My question -- what does a webby p2p solution look like regarding Origin restrictions, etc? Although it sure complicates things I don't see why WebSockets couldn't be extended to allow peer-to-peer connections if we really wanted to. User agent A and B connects to WebSocket server C who keeps a list of clients connected to it. A and B are informed of the id's of connected clients and both decide to set up a peer-to-peer connection. A and B simultaneously call socket.connect_to_peer() passing a peer id and the call returns a new WebSocket in connecting mode. The user agents communicate with the server over the server-socket, retrieves the necessary information to connect to the peer including what origin to expect and off we go. (Server implementations would of course be free to not support this if they choose) As long as the usual DOS/tamper protection is there it should be possible... then there's the success rate of UDP NAT hole punching... -- Erik Möller Core Developer Opera Software
[whatwg] Why there is no wrap=off, intentional or forgotten?
Hi, I'm missing the wrap=off value for textarea wrap attribute; is there any particular reason why this is not part of HTML5? Currently the only values mentioned are soft and hard: http://dev.w3.org/html5/spec/the-button-element.html#attr-textarea-wrap The wrap attribute is an enumerated attribute with two keywords and states: the soft keyword which maps to the Soft state, and the hard keyword which maps to the Hard state. The missing value default is the Soft state. However, I'd like to use wrap=off because I don't want the lines to wrap. (Like when you have a HTML in textarea.) I haven't found any other way to force this behavior (yep, I tried white-space: nowrap;). I tested it in all major browsers on Windows and it works, it just won't validate. :) Code textarea cols=50 rows=10 wrap=soft/textarea textarea cols=50 rows=10 wrap=hard/textarea textarea cols=50 rows=10 wrap=off/textarea More at http://server.ebrana.cz/olda/_apps/html5/textarea-wrap.html There is also no mention in the spec about wrap=virtual and wrap=physical back from the days. http://www.htmlcodetutorial.com/forms/_TEXTAREA_WRAP.html Thanks, Ollie
Re: [whatwg] Why there is no wrap=off, intentional or forgotten?
On Wed, 2010-06-02 at 12:51 +0200, Oldřich Vetešník wrote: Hi, I'm missing the wrap=off value for textarea wrap attribute; is there any particular reason why this is not part of HTML5? Currently the only values mentioned are soft and hard: http://dev.w3.org/html5/spec/the-button-element.html#attr-textarea-wrap The wrap attribute is an enumerated attribute with two keywords and states: the soft keyword which maps to the Soft state, and the hard keyword which maps to the Hard state. The missing value default is the Soft state. However, I'd like to use wrap=off because I don't want the lines to wrap. (Like when you have a HTML in textarea.) I haven't found any other way to force this behavior (yep, I tried white-space: nowrap;). I tested it in all major browsers on Windows and it works, it just won't validate. :) Code textarea cols=50 rows=10 wrap=soft/textarea textarea cols=50 rows=10 wrap=hard/textarea textarea cols=50 rows=10 wrap=off/textarea More at http://server.ebrana.cz/olda/_apps/html5/textarea-wrap.html There is also no mention in the spec about wrap=virtual and wrap=physical back from the days. http://www.htmlcodetutorial.com/forms/_TEXTAREA_WRAP.html Thanks, Ollie That does seem odd. I would have thought the default value would be 'off' or 'no' as I've never seen a browser yet wrap text in a textarea unless a specific wrapping method was specified either via an attribute or CSS. Thanks, Ash http://www.ashleysheridan.co.uk
Re: [whatwg] Why there is no wrap=off, intentional or forgotten?
Dne Wed, 02 Jun 2010 13:05:37 +0200 Ashley Sheridan a...@ashleysheridan.co.uk napsal(a): That does seem odd. I would have thought the default value would be 'off' or 'no' as I've never seen a browser yet wrap text in a textarea unless a specific wrapping method was specified either via an attribute or CSS. Thanks, Ash http://www.ashleysheridan.co.uk By default it wraps, otherwise you would end up with with a horizontal scroll bar. If only resize: both; worked in all browsers and not just webkit :). Ollie
[whatwg] entry script
Sorry for the repeat message... But entry script is a rather fundamental concept in web workers and its not defined as far as I can tell. Can someone tell me where and how its defined? I don't see how entry script is set, when it is set, or what it is set to. Initially, there is no entry script. [1] Can someone help me out? [1] http://dev.w3.org/html5/spec/browsers.html#entry-script Thanks, Perry Ease Software, Inc. ( http://www.easesoftware.com ) Low cost SATA Disk Systems for IBMs p5, pSeries, and RS/6000 AIX systems
Re: [whatwg] Why there is no wrap=off, intentional or forgotten?
On 2010-06-02 13:05, Ashley Sheridan wrote:
On Wed, 2010-06-02 at 12:51 +0200, Oldřich Vetešník wrote:
I'm missing the wrap=off value for textarea wrap attribute; is there any
particular reason why this is not part of HTML5?
Currently the only values mentioned are soft and hard:
http://dev.w3.org/html5/spec/the-button-element.html#attr-textarea-wrap
The explanation is here.
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/022022.html
In theory, you can achieve the same effect by using CSS.
textarea { white-space: nowrap; }
This works fine in Opera, WebKit and IE. Doesn't work in Gecko though.
That does seem odd. I would have thought the default value would be
'off' or 'no' as I've never seen a browser yet wrap text in a textarea
unless a specific wrapping method was specified either via an attribute
or CSS.
Netscape 4 was the last browser I'm aware of that defaulted to that
wrap=off behaviour. I believe every other mainstream browser I'm aware
of since then wraps by default.
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
Re: [whatwg] WebSockets: UDP
On Tue, Jun 1, 2010 at 9:02 PM, Erik Möller emol...@opera.com wrote: On Tue, 01 Jun 2010 21:14:33 +0200, Philip Taylor excors+wha...@gmail.com wrote: More feedback is certainly good, though I think the libraries I mentioned (DirectPlay/OpenTNL/RakNet/ENet (there's probably more)) are useful as an indicator of common real needs (as opposed to edge-case or merely perceived needs) - they've been used by quite a few games and they seem to have largely converged on a core set of features, so that's better than just guessing. I guess many commercial games write their own instead of reusing third-party libraries, and I guess they often reimplement very similar concepts to these, but it would be good to have more reliable information about that. I was hoping to be able to avoid looking at what the interfaces of a high vs low level option would look like this early on in the discussions, but perhaps we need to do just that; look at Torque, RakNet etc and find a least common denominator and see what the reactions would be to such an interface. I'm trying to think of them mainly as indirect examples of use cases, rather than as direct examples of interfaces. Under the assumption that most games either use a library like these or implement a comparable one themselves, and that the library designs are driven by the game requirements, if a feature is supported by most of the libraries then it's probably needed by many games; and if a feature is unsupported in many of the libraries then it's probably unnecessary for most games. (Also an assumption: games running in web browsers will have similar needs to native games (though lagging many years behind state-of-the-art); and we only ought to aim to support the needs of most games, not all games.) So they seem to suggest things like: - many games need a combination of reliable and unreliable-ordered and unreliable-unordered messages. - many games need to send large messages (so the libraries do automatic fragmentation). - many games need to efficiently send tiny messages (so the libraries do automatic aggregation). - many games need some kind of security (I have no idea exactly what, or how much is still relevant when the client is JavaScript and trivial to tamper with). - many games need to prioritise certain messages when bandwidth is limited. - most games don't need low-level control over individual datagrams and precise packet loss feedback, they're okay with the socket details being abstracted away. - ... probably lots more (and/or less); I'm not very familiar with the details of the libraries so this is unlikely to be an accurate list, but I think it may be a useful way to analyse the requirements. (The solution suggested in your initial post (socket.send(data_smaller_than_mtu) going over UDP) seems to be one extreme, which combines with higher-level JS libraries to satisfy these needs. I think I initially suggested the other extreme of encoding all the features into the browser API. I guess the best tradeoff depends largely on what non-game use cases exist that should be satisfied by the same solution.) So, what would the minimal set of limitations be to make a UDP WebSocket browser-safe? -No listen sockets -No multicast -Reliable handshake with origin info -Automatic keep-alives -Reliable close handshake -Socket is bound to one address for the duration of its lifetime -Sockets open sequentially (like current DOS protection in WebSockets) -Cap on number of open sockets per server and total per user agent Perhaps also: - Cap or dynamic limit on bandwidth (you don't want a single web page flooding the user's network connection and starving all the TCP connections) - Protection against session hijacking - Protection against an attacker initiating a legitimate socket with a user and then redirecting it (with some kind of IP (un)hijacking) to a service behind the user's firewall (which isn't a problem when using TCP since the service will ignore packets when it hasn't done the TCP handshake; but UDP services might respond to a single packet from the middle of a websocket stream, so every single packet will have to be careful not to be misinterpreted dangerously by unsuspecting services). -- Philip Taylor exc...@gmail.com
Re: [whatwg] WebSockets: UDP
On Wed, Jun 2, 2010 at 10:48 AM, Philip Taylor excors+wha...@gmail.comexcors%2bwha...@gmail.com wrote: I'm trying to think of them mainly as indirect examples of use cases, rather than as direct examples of interfaces. Under the assumption This is a very valid approach. (Note that most serious games do not use DirectPlay and it has not been updated by Microsoft in a while, so don't burn a lot of braincells on it.) Games always do weird stuff, focus on what will enable the 80% case and not break the web! :) Some thoughts point by point: So they seem to suggest things like: - many games need a combination of reliable and unreliable-ordered and unreliable-unordered messages. Yes. But if you unreliable-unordered you can build the rest pretty easily. - many games need to send large messages (so the libraries do automatic fragmentation). Yes. But many engines do fragmentation more explicitly, since they don't spend a lot of time dealing with TCP streams. (The usual case is transfer of asset files over the network connection, for instance, if a client doesn't have a texture. I suspect for a JS app using UDP this would not be an issue, they could just ask the web server.) - many games need to efficiently send tiny messages (so the libraries do automatic aggregation). Sort of. The common cases are most-recent state and message queues. Mostly they define a packet format and have smart logic for incrementally sending the most relevant state in each packet. - many games need some kind of security (I have no idea exactly what, or how much is still relevant when the client is JavaScript and trivial to tamper with). What is relevant for this discussion is to prevent man in the middle and DoS activities. (Smart) game devs always assume the client is compromised - same as smart web devs. :) - many games need to prioritise certain messages when bandwidth is limited. See the aggregation comment. Also, games typically assume bandwidth is limited - they will target and operate within a fixed bandwidth budget and often a fixed packet rate. Say, 10 500 byte packets per second. This is beneficial for many reasons, but primarily it is good because it optimizes for realtime interaction. For some situations you will want fixed rate, for others you want to have adaptive rate. (For instance, talking to a game server in Counterstrike vs. playing an MMO.) - most games don't need low-level control over individual datagrams and precise packet loss feedback, they're okay with the socket details being abstracted away. Disagree, for good networking you need to know about packet delivery state at quite high levels of the game simulation. - ... probably lots more (and/or less); I'm not very familiar with the details of the libraries so this is unlikely to be an accurate list, but I think it may be a useful way to analyse the requirements. I think you got the major points. (Even though I don't necessarily agree with all of your conclusions. :)) (The solution suggested in your initial post (socket.send(data_smaller_than_mtu) going over UDP) seems to be one extreme, which combines with higher-level JS libraries to satisfy these needs. I think I initially suggested the other extreme of encoding all the features into the browser API. I guess the best tradeoff depends largely on what non-game use cases exist that should be satisfied by the same solution.) I think the best layer to provide is a notify protocol. That is, provide a way to send lossy, smaller-than-MTU messages over a connection in realtime, and notify the dev when a packet has made it (or hasn't). This way the browser can provide a connection abstraction, which deals with the DoS/security/origin issues. (For instance, two obvious pieces are connection puzzles to prevent DoS, and PKI signing to prevent tampering with data. The browser can also support arranged connections for the p2p case.) It also keeps the interoperability manageable. Servers have a specific, fairly small protocol to implement, and can provide some or all of a small set of features. (For instance, caps might be: basic protocol support, secure connections, arranged connections.) Beyond that it is application specific blobs of small size (under a few kb). All that said, I think looking at the notify protocol in TNL is a good baseline. On that you can pretty easily implement every game scenario I can think of. You can reuse a lot of the TCP connection security semantics, too, since it is a connection - just one with lossy delivery. Ben
Re: [whatwg] Why there is no wrap=off, intentional or forgotten?
On 6/2/10 10:10 AM, Lachlan Hunt wrote:
In theory, you can achieve the same effect by using CSS.
textarea { white-space: nowrap; }
This works fine in Opera, WebKit and IE. Doesn't work in Gecko though.
That would be because nothing defines the interaction of CSS with the
contents of replaced elements (which textarea happens to be in at least
Gecko, and probably all browsers). In particular, Gecko's
implementation actually has a box inside the textarea that has
white-space styles applied to it based on the textarea's wrap attribute.
If you think that the above style should do something to textarea,
then the HTML spec needs to explicitly say so, since it's what defines
how the inside of a textarea is rendered, not CSS per se.
-Boris
