Well good luck in any case.

Hopefully Storm will be what you need some other time.


On Sun, Jun 8, 2014 at 10:27 PM, joe roberts <[email protected]>
wrote:

>  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 <[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?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>>
>
>

Reply via email to