Re: [Quickfix-developers] Intermittent disconnects on Solaris

[Oren M. <or...@qu...>]

I know all of this is due for an overhaul.  I would have actually prefered 
to use one of the libraries dedicated to socket handling, but a couple 
reasons prevented me from doing so:  First licensing issues limited our 
choices (can't use GPL and distribute under our license), and second I felt 
it important that QF have as few third party dependencies as possible to 
make the build process simple.  It was far from assured anyone would bother 
to download and build quickfix, much less have to build an equally 
complicated third party socket library.  In order to encourage adoption, the 
basics had to be encapsulated into the main library.

Well ok, that part of the plan worked well enough, and now we are paying the 
price for that decision.  Fortunately unlike before we have the benefit of 
experienced socket developers to advise on how to correct the inexperienced 
design decisions.

First thing to know is the Parser's use of an std::stream is an experiment 
gone bad.  It's not actually used and should have been removed a long time 
ago.  (At one point, the sockets were wrapped in a custom std::stream.  So 
at the time that was intended to be the abstraction. In practice there were 
some problems with this and it was abandoned.)  The only reason it still 
exists is so there is a way for the unit tests to pass data to the Parser. 
Obviously this reduces the value of the tests somewhat and brings glaring 
attention to the design flaw.  Why was the recv call placed there?  Probably 
a poor attempt to share code between the Socket and ThreadedSocket 
implementations. If we had ever gotten around to implementing any non-socket 
based transports, this would certainly have been addressed sooner.

But this will be easy to fix.  We basically need to pull the functionality 
out of the readFromStream call, and instead pass in a parameter to 
readFixMessage which will contain just the bytes to be processed.

The other problems will be harder to address, although I believe some of you 
would likely benefit from the ThreadedSocket classes. These are what is 
currently recommended for high frequency lines, particularly if you are 
running several of them.  I personally don't want to add threads to the 
standard Socket implementation as that pretty much defeats the existence of 
its purpose.  It is intended for applications which do not want or need to 
deal with threads.  When the SocketInitiator/Acceptor Combined with the 
block() or poll() call, QuickFIX can be run entirely single threaded.  I 
think there is value in this. I also think there is plenty of precedence for 
this if done correctly.

I think the naming of the Socket and ThreadedSocket implementations has 
caused confusion.  Perhaps it would be better to just have classes named 
SocketInitiator/Acceptor and pass in the threading model through the 
constructor or configuration settings.

What I think I would like to have happen is if we can come up with a plan to 
address the current shortcomings within the existing framework, do a 
release, and then focus on a more comprehensive overhaul.  Comments?

--oren