So it looks like what you are trying to do is build a reliable shared state server? Possibly with installable business rules in front of that?
That seems to conflict with your previous statements, but typically the way that this is done is to use a quorum update scheme (if you want consistency) or update all replicas scheme (if you don't give a hang about consistency and want availability). If you use a system that only requires persistence to memory with something like a transaction log to allow recovery then you should be able to have round-trip updates in the 1 ms range. Getting consistency as right as it can be will be much harder than it looks, of course. Take a look at Jepsen for testing such systems. See http://aphyr.com/ And in the speed range you are talking about it will be extremely hard to measure any difference between UDP and TCP. Those differences will show up (if at all) in the 10 us range within a data center. On Sun, Jun 8, 2014 at 9:34 PM, joe roberts <[email protected]> wrote: > Sure. > > Here is some of the logic for the game server: > > > > > > * - Chat Entity Movement ( players, AI, etc) - Unreliable - Update occur > within milliseconds - Server Retains last message - Server side validation > against cheating - In-Game Text Social ( Server message to client, client > to client) - Reliable and time sensitive - Updates may occur roughly once > per second or longer - Text Emotes - Delayed delivery system (player is > logged out) - Friends list - Login Server - Provide license validation > before user plays - Reliable - Confidential - Login Server specific Failure > Handling messages - Security - Before login, establish encryption - > Diffie-Hillman - Symmetric Encryption - Message Rate Limitation - Actions > Command Interface (Client to Server ) * > > > > > * - - Emotable Actions (/dance) - Take blue.sword - Give blue.sword to joe > - Object identifiers for nouns - If red.goblin near a player is ID 30232 > then client sends: kill 30232 * > > > * - Voice - Channel based * > > > On 6/9/2014 12:15 AM, Ted Dunning wrote: > > > Joe, > > Can you define a bit more about what you are trying to do? Terracotta > is a fine thing, but it doesn't usually give you want you have been asking > for so far. > > > > > On Sun, Jun 8, 2014 at 9:13 PM, joe roberts < > [email protected]> wrote: > >> Thanks Michael - this is a great and helpful explanation! When you >> mention "stateless set of servers", do you mean something like Terracota? >> If not, is there another solution that you would recommend? I actually >> started reading about Terracota and I also run into this: >> >> http://www.smartfoxserver.com/ >> >> Which seems to be a Java based game server that uses Terracota. >> >> Regards, >> >> Joe >> >> >> >> On 6/8/2014 11:18 PM, Michael Rose wrote: >> >> You could make Storm do what you want, but it's not going to work well >> for you. A normal client/server is vastly more suited to the type of >> workload you want. >> >> UDP may have less overhead, but overall a stall in processing is much >> more costly. In a datacenter, TCP is the way to go for reliable >> communications. UDP is popular between game client & server because of >> packet loss's effect on TCP RTT, and packet loss is common between >> consumers and game servers. Not as much between DC nodes. >> >> Storm's support for other languages isn't exactly anything special. You >> could effect the same interface in non-Storm code. Again, Storm can do >> processing in low-latency situations (<100ms), but it's not what you want. >> You really, really don't want Storm for this application. A custom >> application (yes, you can indeed use Netty UDP) will be much much better >> for you. >> >> If your game server is just running business logic, a totally stateless >> set of servers is really the way to go. >> >> Michael Rose (@Xorlev <https://twitter.com/xorlev>) >> Senior Platform Engineer, FullContact <http://www.fullcontact.com/> >> [email protected] >> >> >> On Sun, Jun 8, 2014 at 9:07 PM, Ted Dunning <[email protected]> >> wrote: >> >>> >>> Why do you think that UDP is faster? >>> >>> >>> >>> >>> On Sun, Jun 8, 2014 at 6:27 PM, joe roberts < >>> [email protected]> wrote: >>> >>>> To make it faster! >>>> >>>> >>>> On 6/8/2014 8:27 PM, Ted Dunning wrote: >>>> >>>> >>>> On Sun, Jun 8, 2014 at 12:12 PM, joe roberts < >>>> [email protected]> wrote: >>>> >>>>> Also, it seems Storm uses TCP via ZeroMQ by default -Is that right? >>>>> And if so, can it be switched to use UDP or UDT instead, perhaps by >>>>> replacing ZeroMQ with Netty? >>>>> >>>> >>>> Why would you want that? >>>> >>>> >>>> >>>> >>> >> >> > >
