You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@storm.apache.org by joe roberts <ca...@gmail.com> on 2014/06/08 21:12:54 UTC
Are Real-Time Game Servers a good use case for Storm
Hi,
I am starting to look at Storm as a possible candidate for a writing the
business logic for a real time game server and I am interested in your
opinion and if you think this would be a good use case for Storm.
Basically here is a rough view / flow of the architecture that I want to
use:
Game Client -> UDP/UDT -> Game Server-> Storm (runs business logic via
rules written in different languages (C, C++, Java (JDBC), C#, LUA,
Python) -> Server -> UDP/UDT -> Client.
The reasons that I want to use Storm are:
* Scalable
* Parallel processing
* Guarantee of at-least-once message delivery
* Writing rules in different languages.
* Fail-over
Regarding scalability, I plan to start with everything running on one
box at first, but with the option to break the work into different nodes
as the number of clients scales up, so ideally, this solution should
perform well with only one node, when there are 10 clients, and scale
well as the number of clients increase and I add more nodes.
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?
Please let me know your thoughts and if this architecture is a good idea
or not.
Regards,
Joe
Re: Are Real-Time Game Servers a good use case for Storm
Posted by Ted Dunning <te...@gmail.com>.
Ben's advice about stateless servers is sound. For lots of apps like this,
you can simple round-robin through the available servers until you find a
nice one, then stick with it until it goes down.
If you want serious speed, you need to be be defining what kind of speed
you want start making measurements. JMH is your friend.
On Sun, Jun 8, 2014 at 9:11 PM, Ted Dunning <te...@gmail.com> wrote:
>
> If you read the replies on the SO question, you will find lots of people
> refuting the "UDP is faster" mantra.
>
> If you haven't already benchmarked Storm to determine the latency and if
> you are thinking that you might want to use Python for message handling,
> then you have already given up far more than what TCP might cost you.
>
> The simple act of marshaling a tuple is going to cost more than the
> difference in many cases.
>
>
>
> On Sun, Jun 8, 2014 at 8:14 PM, joe roberts <carl.roberts.zapata@gmail.com
> > wrote:
>
>> Based on this articles, it is.
>>
>> http://gafferongames.com/networking-for-game-programmers/udp-vs-tcp/
>>
>> http://stackoverflow.com/questions/47903/udp-vs-tcp-how-much-faster-is-it
>>
>> http://www.diffen.com/difference/TCP_vs_UDP
>>
>> http://www.skullbox.net/tcpudp.php.
>>
>> The real-time game server that I am writing has use cases where some
>> packet loss is acceptable, and some cases where reliable messages are
>> needed (UDT), so for my particular use-cases, it is. As I understand it,
>> Netty offers, UDP, UDT, and TCP classes, therefore, it provides what I need.
>>
>> On 6/8/2014 11:07 PM, Ted Dunning wrote:
>>
>>
>> Why do you think that UDP is faster?
>>
>>
>>
>>
>> On Sun, Jun 8, 2014 at 6:27 PM, joe roberts <
>> carl.roberts.zapata@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.zapata@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?
>>>
>>>
>>>
>>>
>>
>>
>
Re: Are Real-Time Game Servers a good use case for Storm
Posted by joe roberts <ca...@gmail.com>.
Hi Ted,
I don't really want to use Python myself, but I plan to support it if
someone wants to use it. Mainly, I plan on supporting C/C++ code, and
perhaps C# and some scripting languages like LUA to add the ability to
add plug-ins to the game server once it is released. The idea is that
once someone acquires the server, they can write their own plug-ins for
the server in the preferred language to extend the functionality of the
server.
Now, in relation to your points about TCP vs UDP, I think the answer
depends on each use-case. For my use-case, when the client only cares
to get the last message from the server, then I truly believe it will be
faster to use UDP as opposed to TCP, as if a message is lost in TCP, or
if the order of the messages that arrive is not correct in TCP, I
believe the TCP stack will queue any messages that it already has until
it can deliver all messages in order, and that, is something I do not want.
Also, thanks for the info. about the cost of marshalling the tuple - I
see now that Storm is not a good candidate for my real-time game
client-server use-case. Many thanks to you and everyone who was kind
enough to provide me with an answer and additional information; you all
just saved me a lot of fruitless effort - I am glad that I asked this
question before embarking on a prototype that used Storm...:)
Thanks,
Joe
On 6/9/2014 12:11 AM, Ted Dunning wrote:
>
> If you read the replies on the SO question, you will find lots of
> people refuting the "UDP is faster" mantra.
>
> If you haven't already benchmarked Storm to determine the latency and
> if you are thinking that you might want to use Python for message
> handling, then you have already given up far more than what TCP might
> cost you.
>
> The simple act of marshaling a tuple is going to cost more than the
> difference in many cases.
>
>
>
> On Sun, Jun 8, 2014 at 8:14 PM, joe roberts
> <carl.roberts.zapata@gmail.com <ma...@gmail.com>>
> wrote:
>
> Based on this articles, it is.
>
> http://gafferongames.com/networking-for-game-programmers/udp-vs-tcp/
>
> http://stackoverflow.com/questions/47903/udp-vs-tcp-how-much-faster-is-it
>
> http://www.diffen.com/difference/TCP_vs_UDP
>
> http://www.skullbox.net/tcpudp.php.
>
> The real-time game server that I am writing has use cases where
> some packet loss is acceptable, and some cases where reliable
> messages are needed (UDT), so for my particular use-cases, it is.
> As I understand it, Netty offers, UDP, UDT, and TCP classes,
> therefore, it provides what I need.
>
> On 6/8/2014 11:07 PM, Ted Dunning wrote:
>>
>> Why do you think that UDP is faster?
>>
>>
>>
>>
>> On Sun, Jun 8, 2014 at 6:27 PM, joe roberts
>> <carl.roberts.zapata@gmail.com
>> <ma...@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.zapata@gmail.com
>>> <ma...@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?
>>>
>>>
>>
>>
>
>
Re: Are Real-Time Game Servers a good use case for Storm
Posted by Ted Dunning <te...@gmail.com>.
If you read the replies on the SO question, you will find lots of people
refuting the "UDP is faster" mantra.
If you haven't already benchmarked Storm to determine the latency and if
you are thinking that you might want to use Python for message handling,
then you have already given up far more than what TCP might cost you.
The simple act of marshaling a tuple is going to cost more than the
difference in many cases.
On Sun, Jun 8, 2014 at 8:14 PM, joe roberts <ca...@gmail.com>
wrote:
> Based on this articles, it is.
>
> http://gafferongames.com/networking-for-game-programmers/udp-vs-tcp/
>
> http://stackoverflow.com/questions/47903/udp-vs-tcp-how-much-faster-is-it
>
> http://www.diffen.com/difference/TCP_vs_UDP
>
> http://www.skullbox.net/tcpudp.php.
>
> The real-time game server that I am writing has use cases where some
> packet loss is acceptable, and some cases where reliable messages are
> needed (UDT), so for my particular use-cases, it is. As I understand it,
> Netty offers, UDP, UDT, and TCP classes, therefore, it provides what I need.
>
> On 6/8/2014 11:07 PM, Ted Dunning wrote:
>
>
> Why do you think that UDP is faster?
>
>
>
>
> On Sun, Jun 8, 2014 at 6:27 PM, joe roberts <carl.roberts.zapata@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.zapata@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?
>>
>>
>>
>>
>
>
Re: Are Real-Time Game Servers a good use case for Storm
Posted by joe roberts <ca...@gmail.com>.
And thanks for taking the time to answer my questions Ted...it is much
appreciated.
Regards,
Joe
On 6/8/2014 11:14 PM, joe roberts wrote:
> Based on this articles, it is.
>
> http://gafferongames.com/networking-for-game-programmers/udp-vs-tcp/
>
> http://stackoverflow.com/questions/47903/udp-vs-tcp-how-much-faster-is-it
>
> http://www.diffen.com/difference/TCP_vs_UDP
>
> http://www.skullbox.net/tcpudp.php.
>
> The real-time game server that I am writing has use cases where some
> packet loss is acceptable, and some cases where reliable messages are
> needed (UDT), so for my particular use-cases, it is. As I understand
> it, Netty offers, UDP, UDT, and TCP classes, therefore, it provides
> what I need.
>
> On 6/8/2014 11:07 PM, Ted Dunning wrote:
>>
>> Why do you think that UDP is faster?
>>
>>
>>
>>
>> On Sun, Jun 8, 2014 at 6:27 PM, joe roberts
>> <carl.roberts.zapata@gmail.com
>> <ma...@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.zapata@gmail.com
>>> <ma...@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?
>>>
>>>
>>
>>
>
Re: Are Real-Time Game Servers a good use case for Storm
Posted by joe roberts <ca...@gmail.com>.
Based on this articles, it is.
http://gafferongames.com/networking-for-game-programmers/udp-vs-tcp/
http://stackoverflow.com/questions/47903/udp-vs-tcp-how-much-faster-is-it
http://www.diffen.com/difference/TCP_vs_UDP
http://www.skullbox.net/tcpudp.php.
The real-time game server that I am writing has use cases where some
packet loss is acceptable, and some cases where reliable messages are
needed (UDT), so for my particular use-cases, it is. As I understand
it, Netty offers, UDP, UDT, and TCP classes, therefore, it provides what
I need.
On 6/8/2014 11:07 PM, Ted Dunning wrote:
>
> Why do you think that UDP is faster?
>
>
>
>
> On Sun, Jun 8, 2014 at 6:27 PM, joe roberts
> <carl.roberts.zapata@gmail.com <ma...@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.zapata@gmail.com
>> <ma...@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?
>>
>>
>
>
Re: Are Real-Time Game Servers a good use case for Storm
Posted by Ted Dunning <te...@gmail.com>.
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 <ca...@gmail.com>
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 <carl.roberts.zapata@gmail.com
> > 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 <
>> carl.roberts.zapata@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/>
>>> michael@fullcontact.com
>>>
>>>
>>> On Sun, Jun 8, 2014 at 9:07 PM, Ted Dunning <te...@gmail.com>
>>> wrote:
>>>
>>>>
>>>> Why do you think that UDP is faster?
>>>>
>>>>
>>>>
>>>>
>>>> On Sun, Jun 8, 2014 at 6:27 PM, joe roberts <
>>>> carl.roberts.zapata@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.zapata@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?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>>
>
>
Re: Are Real-Time Game Servers a good use case for Storm
Posted by joe roberts <ca...@gmail.com>.
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.zapata@gmail.com <ma...@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.zapata@gmail.com
>> <ma...@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/>
>>> michael@fullcontact.com <ma...@fullcontact.com>
>>>
>>>
>>>
>>> On Sun, Jun 8, 2014 at 9:07 PM, Ted Dunning
>>> <ted.dunning@gmail.com <ma...@gmail.com>> wrote:
>>>
>>>
>>> Why do you think that UDP is faster?
>>>
>>>
>>>
>>>
>>> On Sun, Jun 8, 2014 at 6:27 PM, joe roberts
>>> <carl.roberts.zapata@gmail.com
>>> <ma...@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.zapata@gmail.com
>>>> <ma...@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?
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>
>
Re: Are Real-Time Game Servers a good use case for Storm
Posted by Ted Dunning <te...@gmail.com>.
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 <ca...@gmail.com>
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 <
> carl.roberts.zapata@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/>
>> michael@fullcontact.com
>>
>>
>> On Sun, Jun 8, 2014 at 9:07 PM, Ted Dunning <te...@gmail.com>
>> wrote:
>>
>>>
>>> Why do you think that UDP is faster?
>>>
>>>
>>>
>>>
>>> On Sun, Jun 8, 2014 at 6:27 PM, joe roberts <
>>> carl.roberts.zapata@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.zapata@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?
>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>
>
Re: Are Real-Time Game Servers a good use case for Storm
Posted by joe roberts <ca...@gmail.com>.
On 6/9/2014 12:34 AM, joe roberts wrote:
> Sure.
>
> Here is some of the logic for the game server (reformatted for better
> reading):
>
Entity Movement ( players, AI, etc)
* Unreliable (UDP)
* Update occur within milliseconds
* Server Retains last message
* Server side validation against cheating
Map Data
* Reliable (UDT)
* Map objects
* Other objects
In-Game Text Social ( Server message to client, client to client)
* Reliable and time sensitive (UDT)
* 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 (TCP)
* Confidential
* Login Server specific Failure Handling messages
Security
* Before login, establish encryption
* Diffie-Hillman
* Symmetric Encryption
* Message Rate Limitation
Command Interface (Client to Server )
* Reliable (UDT)
* 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:
Voice
* Reliable (UDT)
* 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.zapata@gmail.com
>> <ma...@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/>
>>> michael@fullcontact.com <ma...@fullcontact.com>
>>>
>>>
>>>
>>> On Sun, Jun 8, 2014 at 9:07 PM, Ted Dunning
>>> <ted.dunning@gmail.com <ma...@gmail.com>> wrote:
>>>
>>>
>>> Why do you think that UDP is faster?
>>>
>>>
>>>
>>>
>>> On Sun, Jun 8, 2014 at 6:27 PM, joe roberts
>>> <carl.roberts.zapata@gmail.com
>>> <ma...@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.zapata@gmail.com
>>>> <ma...@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?
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>
Re: Are Real-Time Game Servers a good use case for Storm
Posted by joe roberts <ca...@gmail.com>.
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.zapata@gmail.com <ma...@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/>
>> michael@fullcontact.com <ma...@fullcontact.com>
>>
>>
>>
>> On Sun, Jun 8, 2014 at 9:07 PM, Ted Dunning
>> <ted.dunning@gmail.com <ma...@gmail.com>> wrote:
>>
>>
>> Why do you think that UDP is faster?
>>
>>
>>
>>
>> On Sun, Jun 8, 2014 at 6:27 PM, joe roberts
>> <carl.roberts.zapata@gmail.com
>> <ma...@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.zapata@gmail.com
>>> <ma...@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?
>>>
>>>
>>
>>
>>
>
>
Re: Are Real-Time Game Servers a good use case for Storm
Posted by Ted Dunning <te...@gmail.com>.
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 <ca...@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/>
> michael@fullcontact.com
>
>
> On Sun, Jun 8, 2014 at 9:07 PM, Ted Dunning <te...@gmail.com> wrote:
>
>>
>> Why do you think that UDP is faster?
>>
>>
>>
>>
>> On Sun, Jun 8, 2014 at 6:27 PM, joe roberts <
>> carl.roberts.zapata@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.zapata@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?
>>>
>>>
>>>
>>>
>>
>
>
Re: Are Real-Time Game Servers a good use case for Storm
Posted by joe roberts <ca...@gmail.com>.
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/>
> michael@fullcontact.com <ma...@fullcontact.com>
>
>
>
> On Sun, Jun 8, 2014 at 9:07 PM, Ted Dunning <ted.dunning@gmail.com
> <ma...@gmail.com>> wrote:
>
>
> Why do you think that UDP is faster?
>
>
>
>
> On Sun, Jun 8, 2014 at 6:27 PM, joe roberts
> <carl.roberts.zapata@gmail.com
> <ma...@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.zapata@gmail.com
>> <ma...@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?
>>
>>
>
>
>
Re: Are Real-Time Game Servers a good use case for Storm
Posted by Michael Rose <mi...@fullcontact.com>.
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/>
michael@fullcontact.com
On Sun, Jun 8, 2014 at 9:07 PM, Ted Dunning <te...@gmail.com> wrote:
>
> Why do you think that UDP is faster?
>
>
>
>
> On Sun, Jun 8, 2014 at 6:27 PM, joe roberts <carl.roberts.zapata@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.zapata@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?
>>
>>
>>
>>
>
Re: Are Real-Time Game Servers a good use case for Storm
Posted by Ted Dunning <te...@gmail.com>.
Why do you think that UDP is faster?
On Sun, Jun 8, 2014 at 6:27 PM, joe roberts <ca...@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.zapata@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?
>
>
>
>
Re: Are Real-Time Game Servers a good use case for Storm
Posted by joe roberts <ca...@gmail.com>.
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.zapata@gmail.com <ma...@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?
>
>
Re: Are Real-Time Game Servers a good use case for Storm
Posted by Ted Dunning <te...@gmail.com>.
On Sun, Jun 8, 2014 at 12:12 PM, joe roberts <ca...@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?
Re: Are Real-Time Game Servers a good use case for Storm
Posted by joe roberts <ca...@gmail.com>.
Thanks for taking the time to answer my questions Ben.
Best Regards,
Joe
On 6/8/2014 9:43 PM, Benjamin Black wrote:
> you are talking about the relatively small latency introduced by one
> transport vs another at the same time you indicate wanting to write
> parts in arbitrary languages, including python, and intending to run
> it all on a single machine. this is not a good way to computer.
>
>
> On Sun, Jun 8, 2014 at 6:38 PM, Benjamin Black <b@b3k.us
> <ma...@b3k.us>> wrote:
>
> the answer is no.
>
>
> On Sun, Jun 8, 2014 at 6:25 PM, joe roberts
> <carl.roberts.zapata@gmail.com
> <ma...@gmail.com>> wrote:
>
> Thanks for your response - it is much appreciated. I looked
> at Ordasity, but I am not sure it handles writing code / rules
> in different languages like Storm does, which is one of the
> primary reasons that I wanted to use Storm. Also, regarding
> scalability, yes, my plans are to code for it and test for it
> in the beginning, but the requirement is to deploy on one box
> initially, hence Storm also looked appealing in this regard as
> it supports local and clustered setups. Yes, latency is one of
> the primary concerns for my client - game server architecture
> and I forgot to mention that ... :(. So, is there no way to
> achieve a latency of ~100ms with Storm when processing tuples
> via Spouts and Bolts (I realize this is a loaded question
> since it really depends on what the processing logic does, but
> assuming that logic is fast, what kind of latency can I expect
> from the Storm communication layer)? Storm looks very
> appealing but if it flat out won't handle < 100 ms latency,
> then I cannot use it. If the answer is No, then I'll have to
> keep looking for a solution.
>
>
> On 6/8/2014 5:02 PM, Benjamin Black wrote:
>> tl;dr - no.
>>
>> the aspect you left out of your list is latency. storm, like
>> most stream processing systems, is throughput oriented, not
>> latency oriented. think hundreds to thousands of milliseconds
>> rather than tens. what you've described so far is not a good
>> candidate for any stream processing system. if your "business
>> logic" layer is essentially a stateless layer, then have a
>> look at ordasity https://github.com/boundary/ordasity
>>
>> if you intend your system to be distributed, then do it
>> distributed from day one. running it all on one box is a
>> reliable way to unknowingly include assumptions that later
>> preclude running on multiple systems.
>>
>> storm already uses netty:
>> https://storm.incubator.apache.org/2013/12/08/storm090-released.html
>>
>>
>> b
>>
>>
>>
>> On Sun, Jun 8, 2014 at 12:12 PM, joe roberts
>> <carl.roberts.zapata@gmail.com
>> <ma...@gmail.com>> wrote:
>>
>> Hi,
>>
>> I am starting to look at Storm as a possible candidate
>> for a writing the business logic for a real time game
>> server and I am interested in your opinion and if you
>> think this would be a good use case for Storm. Basically
>> here is a rough view / flow of the architecture that I
>> want to use:
>>
>> Game Client -> UDP/UDT -> Game Server-> Storm (runs
>> business logic via rules written in different languages
>> (C, C++, Java (JDBC), C#, LUA, Python) -> Server ->
>> UDP/UDT -> Client.
>>
>> The reasons that I want to use Storm are:
>>
>> * Scalable
>> * Parallel processing
>> * Guarantee of at-least-once message delivery
>> * Writing rules in different languages.
>> * Fail-over
>>
>> Regarding scalability, I plan to start with everything
>> running on one box at first, but with the option to break
>> the work into different nodes as the number of clients
>> scales up, so ideally, this solution should perform well
>> with only one node, when there are 10 clients, and scale
>> well as the number of clients increase and I add more nodes.
>>
>> 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?
>>
>> Please let me know your thoughts and if this architecture
>> is a good idea or not.
>>
>> Regards,
>>
>> Joe
>>
>>
>
>
>
Re: Are Real-Time Game Servers a good use case for Storm
Posted by Benjamin Black <b...@b3k.us>.
you are talking about the relatively small latency introduced by one
transport vs another at the same time you indicate wanting to write parts
in arbitrary languages, including python, and intending to run it all on a
single machine. this is not a good way to computer.
On Sun, Jun 8, 2014 at 6:38 PM, Benjamin Black <b...@b3k.us> wrote:
> the answer is no.
>
>
> On Sun, Jun 8, 2014 at 6:25 PM, joe roberts <carl.roberts.zapata@gmail.com
> > wrote:
>
>> Thanks for your response - it is much appreciated. I looked at
>> Ordasity, but I am not sure it handles writing code / rules in different
>> languages like Storm does, which is one of the primary reasons that I
>> wanted to use Storm. Also, regarding scalability, yes, my plans are to
>> code for it and test for it in the beginning, but the requirement is to
>> deploy on one box initially, hence Storm also looked appealing in this
>> regard as it supports local and clustered setups. Yes, latency is one of
>> the primary concerns for my client - game server architecture and I forgot
>> to mention that ... :(. So, is there no way to achieve a latency of ~100ms
>> with Storm when processing tuples via Spouts and Bolts (I realize this is a
>> loaded question since it really depends on what the processing logic does,
>> but assuming that logic is fast, what kind of latency can I expect from the
>> Storm communication layer)? Storm looks very appealing but if it flat out
>> won't handle < 100 ms latency, then I cannot use it. If the answer is No,
>> then I'll have to keep looking for a solution.
>>
>>
>> On 6/8/2014 5:02 PM, Benjamin Black wrote:
>>
>> tl;dr - no.
>>
>> the aspect you left out of your list is latency. storm, like most
>> stream processing systems, is throughput oriented, not latency oriented.
>> think hundreds to thousands of milliseconds rather than tens. what you've
>> described so far is not a good candidate for any stream processing system.
>> if your "business logic" layer is essentially a stateless layer, then have
>> a look at ordasity https://github.com/boundary/ordasity
>>
>> if you intend your system to be distributed, then do it distributed
>> from day one. running it all on one box is a reliable way to unknowingly
>> include assumptions that later preclude running on multiple systems.
>>
>> storm already uses netty:
>> https://storm.incubator.apache.org/2013/12/08/storm090-released.html
>>
>>
>> b
>>
>>
>>
>> On Sun, Jun 8, 2014 at 12:12 PM, joe roberts <
>> carl.roberts.zapata@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> I am starting to look at Storm as a possible candidate for a writing the
>>> business logic for a real time game server and I am interested in your
>>> opinion and if you think this would be a good use case for Storm.
>>> Basically here is a rough view / flow of the architecture that I want to
>>> use:
>>>
>>> Game Client -> UDP/UDT -> Game Server-> Storm (runs business logic via
>>> rules written in different languages (C, C++, Java (JDBC), C#, LUA, Python)
>>> -> Server -> UDP/UDT -> Client.
>>>
>>> The reasons that I want to use Storm are:
>>>
>>> - Scalable
>>> - Parallel processing
>>> - Guarantee of at-least-once message delivery
>>> - Writing rules in different languages.
>>> - Fail-over
>>>
>>> Regarding scalability, I plan to start with everything running on one
>>> box at first, but with the option to break the work into different nodes as
>>> the number of clients scales up, so ideally, this solution should perform
>>> well with only one node, when there are 10 clients, and scale well as the
>>> number of clients increase and I add more nodes.
>>>
>>> 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?
>>>
>>> Please let me know your thoughts and if this architecture is a good idea
>>> or not.
>>>
>>> Regards,
>>>
>>> Joe
>>>
>>
>>
>>
>
Re: Are Real-Time Game Servers a good use case for Storm
Posted by Benjamin Black <b...@b3k.us>.
the answer is no.
On Sun, Jun 8, 2014 at 6:25 PM, joe roberts <ca...@gmail.com>
wrote:
> Thanks for your response - it is much appreciated. I looked at
> Ordasity, but I am not sure it handles writing code / rules in different
> languages like Storm does, which is one of the primary reasons that I
> wanted to use Storm. Also, regarding scalability, yes, my plans are to
> code for it and test for it in the beginning, but the requirement is to
> deploy on one box initially, hence Storm also looked appealing in this
> regard as it supports local and clustered setups. Yes, latency is one of
> the primary concerns for my client - game server architecture and I forgot
> to mention that ... :(. So, is there no way to achieve a latency of ~100ms
> with Storm when processing tuples via Spouts and Bolts (I realize this is a
> loaded question since it really depends on what the processing logic does,
> but assuming that logic is fast, what kind of latency can I expect from the
> Storm communication layer)? Storm looks very appealing but if it flat out
> won't handle < 100 ms latency, then I cannot use it. If the answer is No,
> then I'll have to keep looking for a solution.
>
>
> On 6/8/2014 5:02 PM, Benjamin Black wrote:
>
> tl;dr - no.
>
> the aspect you left out of your list is latency. storm, like most stream
> processing systems, is throughput oriented, not latency oriented. think
> hundreds to thousands of milliseconds rather than tens. what you've
> described so far is not a good candidate for any stream processing system.
> if your "business logic" layer is essentially a stateless layer, then have
> a look at ordasity https://github.com/boundary/ordasity
>
> if you intend your system to be distributed, then do it distributed from
> day one. running it all on one box is a reliable way to unknowingly include
> assumptions that later preclude running on multiple systems.
>
> storm already uses netty:
> https://storm.incubator.apache.org/2013/12/08/storm090-released.html
>
>
> b
>
>
>
> On Sun, Jun 8, 2014 at 12:12 PM, joe roberts <
> carl.roberts.zapata@gmail.com> wrote:
>
>> Hi,
>>
>> I am starting to look at Storm as a possible candidate for a writing the
>> business logic for a real time game server and I am interested in your
>> opinion and if you think this would be a good use case for Storm.
>> Basically here is a rough view / flow of the architecture that I want to
>> use:
>>
>> Game Client -> UDP/UDT -> Game Server-> Storm (runs business logic via
>> rules written in different languages (C, C++, Java (JDBC), C#, LUA, Python)
>> -> Server -> UDP/UDT -> Client.
>>
>> The reasons that I want to use Storm are:
>>
>> - Scalable
>> - Parallel processing
>> - Guarantee of at-least-once message delivery
>> - Writing rules in different languages.
>> - Fail-over
>>
>> Regarding scalability, I plan to start with everything running on one box
>> at first, but with the option to break the work into different nodes as the
>> number of clients scales up, so ideally, this solution should perform well
>> with only one node, when there are 10 clients, and scale well as the number
>> of clients increase and I add more nodes.
>>
>> 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?
>>
>> Please let me know your thoughts and if this architecture is a good idea
>> or not.
>>
>> Regards,
>>
>> Joe
>>
>
>
>
Re: Are Real-Time Game Servers a good use case for Storm
Posted by joe roberts <ca...@gmail.com>.
Thanks for your response - it is much appreciated. I looked at
Ordasity, but I am not sure it handles writing code / rules in different
languages like Storm does, which is one of the primary reasons that I
wanted to use Storm. Also, regarding scalability, yes, my plans are to
code for it and test for it in the beginning, but the requirement is to
deploy on one box initially, hence Storm also looked appealing in this
regard as it supports local and clustered setups. Yes, latency is one
of the primary concerns for my client - game server architecture and I
forgot to mention that ... :(. So, is there no way to achieve a latency
of ~100ms with Storm when processing tuples via Spouts and Bolts (I
realize this is a loaded question since it really depends on what the
processing logic does, but assuming that logic is fast, what kind of
latency can I expect from the Storm communication layer)? Storm looks
very appealing but if it flat out won't handle < 100 ms latency, then I
cannot use it. If the answer is No, then I'll have to keep looking for
a solution.
On 6/8/2014 5:02 PM, Benjamin Black wrote:
> tl;dr - no.
>
> the aspect you left out of your list is latency. storm, like most
> stream processing systems, is throughput oriented, not latency
> oriented. think hundreds to thousands of milliseconds rather than
> tens. what you've described so far is not a good candidate for any
> stream processing system. if your "business logic" layer is
> essentially a stateless layer, then have a look at ordasity
> https://github.com/boundary/ordasity
>
> if you intend your system to be distributed, then do it distributed
> from day one. running it all on one box is a reliable way to
> unknowingly include assumptions that later preclude running on
> multiple systems.
>
> storm already uses netty:
> https://storm.incubator.apache.org/2013/12/08/storm090-released.html
>
>
> b
>
>
>
> On Sun, Jun 8, 2014 at 12:12 PM, joe roberts
> <carl.roberts.zapata@gmail.com <ma...@gmail.com>>
> wrote:
>
> Hi,
>
> I am starting to look at Storm as a possible candidate for a
> writing the business logic for a real time game server and I am
> interested in your opinion and if you think this would be a good
> use case for Storm. Basically here is a rough view / flow of the
> architecture that I want to use:
>
> Game Client -> UDP/UDT -> Game Server-> Storm (runs business logic
> via rules written in different languages (C, C++, Java (JDBC), C#,
> LUA, Python) -> Server -> UDP/UDT -> Client.
>
> The reasons that I want to use Storm are:
>
> * Scalable
> * Parallel processing
> * Guarantee of at-least-once message delivery
> * Writing rules in different languages.
> * Fail-over
>
> Regarding scalability, I plan to start with everything running on
> one box at first, but with the option to break the work into
> different nodes as the number of clients scales up, so ideally,
> this solution should perform well with only one node, when there
> are 10 clients, and scale well as the number of clients increase
> and I add more nodes.
>
> 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?
>
> Please let me know your thoughts and if this architecture is a
> good idea or not.
>
> Regards,
>
> Joe
>
>
Re: Are Real-Time Game Servers a good use case for Storm
Posted by Benjamin Black <b...@b3k.us>.
tl;dr - no.
the aspect you left out of your list is latency. storm, like most stream
processing systems, is throughput oriented, not latency oriented. think
hundreds to thousands of milliseconds rather than tens. what you've
described so far is not a good candidate for any stream processing system.
if your "business logic" layer is essentially a stateless layer, then have
a look at ordasity https://github.com/boundary/ordasity
if you intend your system to be distributed, then do it distributed from
day one. running it all on one box is a reliable way to unknowingly include
assumptions that later preclude running on multiple systems.
storm already uses netty:
https://storm.incubator.apache.org/2013/12/08/storm090-released.html
b
On Sun, Jun 8, 2014 at 12:12 PM, joe roberts <ca...@gmail.com>
wrote:
> Hi,
>
> I am starting to look at Storm as a possible candidate for a writing the
> business logic for a real time game server and I am interested in your
> opinion and if you think this would be a good use case for Storm.
> Basically here is a rough view / flow of the architecture that I want to
> use:
>
> Game Client -> UDP/UDT -> Game Server-> Storm (runs business logic via
> rules written in different languages (C, C++, Java (JDBC), C#, LUA, Python)
> -> Server -> UDP/UDT -> Client.
>
> The reasons that I want to use Storm are:
>
> - Scalable
> - Parallel processing
> - Guarantee of at-least-once message delivery
> - Writing rules in different languages.
> - Fail-over
>
> Regarding scalability, I plan to start with everything running on one box
> at first, but with the option to break the work into different nodes as the
> number of clients scales up, so ideally, this solution should perform well
> with only one node, when there are 10 clients, and scale well as the number
> of clients increase and I add more nodes.
>
> 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?
>
> Please let me know your thoughts and if this architecture is a good idea
> or not.
>
> Regards,
>
> Joe
>