Pilk
Evolution
IT Alliance
   |
Posted - 2010.12.22 16:20:00 -
[1]
 Originally by: Gnulpie
Edited by: Gnulpie on 12/12/2010 12:35:43
Good speedup, this is pretty impressive.
But why does the machoNet::SinglecastByClientID take that long? The Destiny::SendToClients without the SingleCast is only 7.4 ms! So the overhead is not in sorting out the data any more but in sending it. Is it possible to delegate this to a (highly) parallel worker thread which is doing all the work in the background (on other nodes maybe?) or do you get in trouble then with the non-blocking paradigm of Destiny?
Edit: Do you lookup always SessionID's from ClientID's in each SingleCast? That would be a huge waste in this case as they are almost always constant.
I would also propose that a multicast approach would be more appropriate, since a large number of clients are each receiving the same data. Obviously not IP multicast, but passing a piece of serialized data exactly once to the proxy layer, along with a list of clients which must receive it. If the concern is that people might be connected through different proxies, at least three possibilities suggest themselves:
- Randomly choose a proxy server; this Sol sends a multicast to it:
multicast("Ship #21 firing an EM smartbomb, ship #33 has stopped moving",[Joe,Billy,Bob,Sam,Reggie],master=true). That proxy then sends to each other proxy: multicast("Ship #21 firing an EM smartbomb, ship #33 has stopped moving",[Joe,Billy,Bob,Sam,Reggie],master=false) (and parses and runs the multicast for its own connections). Implicitly, it is not an error, and is silently ignored, if a given recipient of a multicast is not connected to the proxy that received it.
- From the Sol, contact every proxy and perform the same steps as above. Has the advantage that it can (more easily) be blocking to whatever extent is deemed necessary.
- On the Sol, maintain a list of proxies through which players are connected; the list need not be minimal, just complete. As above, but only contact each proxy which actually has a player connected. This one scales better, and is my favorite of the three.
This closely mirrors a fundamental Google approach to cluster computingłnamely, that it is rarely correct to select something. As an example, for certain classes of boolean search problems, it is expensive to evaluate their class so as to know which of several different algorithms to use to solve them. What Google does instead is launch all three of those algorithms simultaneously on three different machines; the first result to return is used, and the other two tasks are killed. So, in our case, if serialization is expensive, and if finding out to which proxy a given player is connected soaks up time, don't bother doing it.
--P
Kosh: The avalanche has already started. It is too late for the pebbles to vote.
Tyrrax's bet status: PAID! |