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
