the answer is no.
On Sun, Jun 8, 2014 at 6:25 PM, joe roberts <[email protected]> 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 < > [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 >> > > >
