Runtime network described classes and frame groups (libtpproto-cpp)
Posted 2004-11-03-0100
I had been holding off working on libtpproto-cpp orders. I knew it wouldn't be easy. But I didn't expect to find myself pondering rewriting a good portion of the whole library to get them going.
The python library (py-netlib) uses runtime dynamic classes... evil! Under C++ I was going to (and are still going to) use parameter objects, much nicer than dynamic classes, and still typesafe. The problem lies in the way that the description of the parameters is send, and when.
Order descriptions are treated seperately from orders, and are carried in seperate frames. Since the library only processes one frame at a time, sending a Get Order Description packet from the Order Frame handler and expecting the next frame to be an Order Description will not work quite alot of the time. If a group of Orders is requested, when the first call to the order frame handler is called it sends a get order description, but will appear to get back an order frame... the next order to be processed. I think the technical name for this problem is the "Front of the Queue Blocking" problem.
There are two solutions take I can see. The first is to recode the whole library, so that it reads the whole sequence of frames before it decodes them (not nice, big change, kuldge). The second is to have a cache of order descriptions from when the client downloaded the objects, using the available order field to select what order types to get. The second sounds better to me, but means exposing some knowledge of order descriptions (in case the client bypasses the nice interface and uses sendFrame()/recvFrame() instead).
Which ever I choose, it's not going to happen tonight. I was soooooo looking forward to having the first client that had every feature green on the TP client Feature Matrix.