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.zap...@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.zap...@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 >>> >> >> >> >
