Thanks Ted.
My apologies for the inconsistency on my statements - I will confess
that I am new to the world of game development, so I am learning as
quickly as I can by reading a lot and asking questions and every person
like you who is willing to take time from their busy day to help me with
an answer or another tidbit of useful information has been extremely
helpful to me.
Many, many thanks.
Joe
On 6/9/2014 1:09 AM, Ted Dunning wrote:
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
<carl.roberts.zap...@gmail.com <mailto:carl.roberts.zap...@gmail.com>>
wrote:
Sure.
Here is some of the logic for the game server:
*
o
ChatEntity Movement ( players, AI, etc)
+
Unreliable
+
Update occur within milliseconds
+
Server Retains last message
+
Server side validation against cheating
o
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
o
Login Server
+
Provide license validation before user plays
+
Reliable
+
Confidential
+
Login Server specific Failure Handling messages
o
Security
+
Before login, establish encryption
+
Diffie-Hillman
+
Symmetric Encryption
+
Message Rate Limitation
o 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
o
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
<carl.roberts.zap...@gmail.com
<mailto:carl.roberts.zap...@gmail.com>> 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/>
mich...@fullcontact.com <mailto:mich...@fullcontact.com>
On Sun, Jun 8, 2014 at 9:07 PM, Ted Dunning
<ted.dunn...@gmail.com <mailto:ted.dunn...@gmail.com>> wrote:
Why do you think that UDP is faster?
On Sun, Jun 8, 2014 at 6:27 PM, joe roberts
<carl.roberts.zap...@gmail.com
<mailto:carl.roberts.zap...@gmail.com>> 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
<carl.roberts.zap...@gmail.com
<mailto:carl.roberts.zap...@gmail.com>> 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?
