thanks quite useful answer. if we have around 700 clients, do we need to create around 700 disruptors? we also stream different types of data (3 types), will it be a good idea to create 700 * 3 disruptors?
On Saturday, April 15, 2017 at 1:07:03 AM UTC+3, mikeb01 wrote: > > We've found that as our exchange volumes have increased the only protocol > capable of handling a full un-throttled feed is ITCH (over multicast UDP). > For all of our other stream based TCP feeds (FIX, HTTP) we are moving > toward rate throttling and coalescing events based on symbol in all cases - > we already do it in the majority of our connections. We maintain a buffer > per connection (Disruptor or coalescing ring buffer depending on the > implementation) so that the rate at which a remote connection consumes does > not impact on any of the other connections. With FIX we also maintain some > code that if we detect a ring buffer becoming too full (e.g. >50%) then we > pro-actively tear down that connection under the assumption that their > connection is not fast enough to handle the full feed or it has > disconnected and we didn't set get a FIN packet. If you have non-blocking > I/O available, then you can be a little bit smarter regarding the > implementation (unfortunately not an option with the standardised web > socket APIs). > > Mike. > >> >> -- >> Studying for the Turing test >> >> -- >> You received this message because you are subscribed to the Google Groups >> "mechanical-sympathy" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > -- You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
