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 <[email protected]> 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 >
