Re: [Quickfix-developers] ThreadedSocketAcceptor vrs SocketAcceptor
Brought to you by:
orenmnero
Menu
▾
▴
Re: [Quickfix-developers] ThreadedSocketAcceptor vrs SocketAcceptor
|
From: <OM...@th...> - 2003-01-09 15:19:58
|
This bears some explanation as this gets asked a lot. With the SocketAcceptor and the SocketInitiator, all processing by QuickFIX sessions occurs on one thread. This means that all sessions share the same thread of execution. This is done through a standard select statement on all open sockets. When a message comes across the wire, it is passed along to the associated session and processed. This has some disadvantages. First it means that sessions that require a lot of processing can easily make the system less responsive for other sessions. Second, since QF won't read off the socket until it is done processing a message, it is possible for the socket to queue up messages and be overloaded. These are generally ideal for small applications that have relatively few sessions and smaller traffic requirements. Actually you can handle a considerable amount of traffic with these and is suitable for most small and moderately sized firms. Its effectiveness depends on the length of your operations in your callbacks. It breaks down when you need to do long operations and fair distribution of processor time between sessions. I wouldn't use these, for example, if your callbacks wrote to a database. -- The ThreadedSocketAcceptor and ThreadedSocketInitiator address these shortcomings. With these, each session spawns two threads. One that is dedicated to nothing else but reading bytes off of the socket as fast as it can and pushing them onto a queue, and another that pulls off of the queue and parses than processes the messages within the session. This allows the sessions to process considerably more traffic since the socket is much less likely to get overloaded, and also allows all sessions to remain responsive regardless of what another session may be doing. The thing to keep in mind when using this however, is that there is no guarantee which thread of execution will be entering your callbacks. Unlike the SocketAcceptor and Initiator, which can always be expected to be called by the same thread no matter what, there is no such guaranteee here. This makes syncrhonization between shared resources very important. These are what I would use for any effort that required the creation of a responsive or large scale system. --oren |---------+-----------------------------------------------> | | "Bill Adelman" | | | <bad...@ae...> | | | Sent by: | | | qui...@li...ur| | | ceforge.net | | | | | | | | | 01/09/2003 07:53 AM | | | Please respond to badelman | | | | |---------+-----------------------------------------------> >----------------------------------------------------------------------------------------------| | | | To: <qui...@li...> | | cc: | | Subject: [Quickfix-developers] ThreadedSocketAcceptor vrs SocketAcceptor | >----------------------------------------------------------------------------------------------| What are the differences between ThreadedSocketAcceptor.cpp and SocketAcceptor.cpp and between ThreadedSocketInitiator.cpp and SocketInitiator.cpp thanks Billy ------------------------------------------------------- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com _______________________________________________ Quickfix-developers mailing list Qui...@li... https://lists.sourceforge.net/lists/listinfo/quickfix-developers |
