On Wed, Jun 2, 2010 at 10:48 AM, Philip Taylor <span dir="ltr"><<a href="mailto:excors%2Bwhatwg@gmail.com">excors+whatwg@gmail.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
I'm trying to think of them mainly as indirect examples of use cases,<br>
rather than as direct examples of interfaces. Under the assumption<br></blockquote><div><br>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.)<br>
<br>Games always do weird stuff, focus on what will enable the 80% case and not break the web! :)<br> <br>Some thoughts point by point:<br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
So they seem to suggest things like:<br>
- many games need a combination of reliable and unreliable-ordered and<br>
unreliable-unordered messages.<br></blockquote><div><br>Yes. But if you unreliable-unordered you can build the rest pretty easily.<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
- many games need to send large messages (so the libraries do<br>
automatic fragmentation).<br></blockquote><div><br>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.)<br>
<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
- many games need to efficiently send tiny messages (so the libraries<br>
do automatic aggregation).<br></blockquote><div><br>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.<br>
</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
- many games need some kind of security (I have no idea exactly what,<br>
or how much is still relevant when the client is JavaScript and<br>
trivial to tamper with).<br></blockquote><div><br>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. :)<br>
</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
- many games need to prioritise certain messages when bandwidth is limited.<br></blockquote><div><br>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.)<br>
</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
- most games don't need low-level control over individual datagrams<br>
and precise packet loss feedback, they're okay with the socket details<br>
being abstracted away.<br></blockquote><div><br>Disagree, for good networking you need to know about packet delivery state at quite high levels of the game simulation.<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
- ... probably lots more (and/or less); I'm not very familiar with the<br>
details of the libraries so this is unlikely to be an accurate list,<br>
but I think it may be a useful way to analyse the requirements.<br></blockquote><div><br>I think you got the major points. (Even though I don't necessarily agree with all of your conclusions. :))<br> <br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
(The solution suggested in your initial post<br>
(socket.send(data_smaller_than_mtu) going over UDP) seems to be one<br>
extreme, which combines with higher-level JS libraries to satisfy<br>
these needs. I think I initially suggested the other extreme of<br>
encoding all the features into the browser API. I guess the best<br>
tradeoff depends largely on what non-game use cases exist that should<br>
be satisfied by the same solution.)<br></blockquote><div><br>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.)<br>
<br>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).<br>
<br><br>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.<br>
<br></div></div>Ben<br>