Genesis API and custom software

[nononsense]

Quote from tntneo:

... but if you want to keep things as lean and mean as possible,...

Hi tnteo,

Happy to hear this tnteo.
May I add that this also often goes hand in hand with the search for platform independence, IMHO a must for any longterm survival in this business.

I'm quite curious to read further about your promised experience with x-trader.

BTW, some people interested in programming questions may be interested to listen to Guido van Rossum's extensive talk in 2 parts:
http://www.itconversations.com/shows/detail545.html

Be good,
nononsense

 

[dcraig]

Quote from tntneo:

anyway, win32 yes, mfc yes, but one can build an extra layer (com, .net or other) if you want to. but if you want to keep things as lean and mean as possible, I like Genesis approach very much.

I'm sure stephencrowley can speak for himself but what he (and others) want is no COM, ActiveX, MFC, Win32 or anything else tied to a Microsoft platform. The point really is that it is all completely unnecessary. An API just has to send/receive messages and marshall them to/from data structures. It can be done in C using BSD sockets(not Winsock !) and is then portable across all Windows from NT onward, all UNIX, Linux, MAC etc. You can wrap it with bindings to whatever environment you like or the vendor wrap it in ActiveX or whatever is the latest and greatest Microsoft environment.

 

[nononsense]

Quote from dcraig:

I'm sure stephencrowley can speak for himself but what he (and others) want is no COM, ActiveX, MFC, Win32 or anything else tied to a Microsoft platform. The point really is that it is all completely unnecessary. An API just has to send/receive messages and marshall them to/from data structures. It can be done in C using BSD sockets(not Winsock !) and is then portable across all Windows from NT onward, all UNIX, Linux, MAC etc. You can wrap it with bindings to whatever environment you like or the vendor wrap it in ActiveX or whatever is the latest and greatest Microsoft environment.

Right Craig!
PS: about C: Great language but only use it sparingly, i.e. if you have to.

 

[nbates]

Agreed, no need or purpose for MFC...but WSA Extensions to the Winsock API represent a performance advantage over BSD sockets (imo).

My preference is a nice tight asynchronous (!=COM) API for Win32 Platforms, with a well-published wire-level packet specification with BSD socket sample/example code for Unix or roll your own low-level API specialists.

One could also add the bits for eXternal Data Representation (XDR) to marshall between little-endian to big-endian machines, but that should be a "plugable" protocol option because of the performance overhead and complexity it creates.

But never forget that, ("advanced") features and functionality are just as important as raw-speed.

 

[tntneo]

I agree with you guys.
although I am not sure if what you suggest is as practical as it seems.
when I get an API, I want a sample application and it should be as easy as possible to get things to work. win32 (if possible without MFC) is a way to do it.

in theory, what you suggest is the most independent way to do things.
I do not like MS platform. I wish I could get rid of it. but again, it goes to practicality.. flexibility to link to many brokers, means usually use win32 through dlls or com.
that's the reality.

I'd rather spend as little time as possible coding and spend time monitoring robots trading instead.

regarding XTrader, I will let you know soon. I won't be using it for myself, but a fellow trader is contracting me for this platform. you never know, maybe I will like it better

 

[dcraig]

Quote from nbates:

Agreed, no need or purpose for MFC...but WSA Extensions to the Winsock API represent a performance advantage over BSD sockets (imo).

My preference is a nice tight asynchronous (!=COM) API for Win32 Platforms, with a well-published wire-level packet specification with BSD socket sample/example code for Unix or roll your own low-level API specialists.

One could also add the bits for eXternal Data Representation (XDR) to marshall between little-endian to big-endian machines, but that should be a "plugable" protocol option because of the performance overhead and complexity it creates.

But never forget that, ("advanced") features and functionality are just as important as raw-speed.

Yes, it would be very nice if vedors provided a decent protocol spec including sample message flows etc etc.

For building handlers for binary protocols XDR is incredibly easy to use and is actually quite efficient. I doubt if performance is an issue. NFS seems to manage OK with much greater bandwidth demands than any data feed.

The point really is that whatever 'easy to use' stuff people need or think they need can be wrapped over a decent portable base without a lot of effort in the larger scheme of things.

 

[stephencrowley]

Maybe my point was lost in translation somewhere.. but I am saying the API should be as low-level as possible, with perhaps a higher level api available as well for those who want it. A lowlevel C api with callback functions is all I need. Preferably they would publish the socket layer protocol and I would write my own library. My bots certainly aren't going to be running on the MS platform. You can wrap simple C dlls with wine in Linux, but more complicated things like c++/templates etc make it nearly impossible.

Quote from tntneo:

That's true. however, it also means it is a very fast API not using layers and layers of 'frameworks' slowing down execution.
I still code for IB and Genesis (and soon Xtrader, so I will tell you more about it later). Genesis full API is complex but so powerful. IB API is a little more mature for remote traders. For instance it is more resilient to internet disruptions. Genesis is very sensitive to disconnects and will not tell you that you are disconnected. So I have to add extra support for this in my robots using Genesis.
Now that's not a big issue anymore (used to be the same thing for IB, for those who remember).

anyway, win32 yes, mfc yes, but one can build an extra layer (com, .net or other) if you want to. but if you want to keep things as lean and mean as possible, I like Genesis approach very much.

 

[stephencrowley]

XDR looks really interesting, couldn't find much in the open-source world about it thought besides NFS and RPC like you said. Are there any packages which can convert XDR to c++ templates, etc?

Quote from dcraig:

Yes, it would be very nice if vedors provided a decent protocol spec including sample message flows etc etc.

For building handlers for binary protocols XDR is incredibly easy to use and is actually quite efficient. I doubt if performance is an issue. NFS seems to manage OK with much greater bandwidth demands than any data feed.

The point really is that whatever 'easy to use' stuff people need or think they need can be wrapped over a decent portable base without a lot of effort in the larger scheme of things.

 

[nononsense]

IMHO, a good example would be Troy Melhases's IbPy. This is in fact a rewrite of the TWS java api.

It runs on anything that has Python which seems to be omnipresent these days. You are completely independent of platforms and hardware and the enslaving gimmickery of their vendors.

It should be added that for TWS, you are still hooked to the jre crap required for running the TWS tradestation that you will hook into.

I wish x-trader would have the wisdom & insight to put something together like this, but possibly without the jre crap. They should have their trader also run on linux though.

 

[dcraig]

Quote from stephencrowley:

XDR looks really interesting, couldn't find much in the open-source world about it thought besides NFS and RPC like you said. Are there any packages which can convert XDR to c++ templates, etc?

rpcgen is the compiler and should be on just about any UNIX/Linux box. You make a "*.x" file which bears more than a passing resemblance to a C header file, compile it with rpcgen and out pops the C code that encodes/decodes the messages, together with the C data structures. It's quite a long time since I used it. There was some sort of Java implementation I think somewhere. As for C++, I don't know. There's an RFC for XDR that may be worth looking at.

I think the best documentation I found was in some AIX manuals. IBM may possibly have these available online these days.

There are arguments for and against binary protocols. One problem is that they are difficult to support as reading message traces is laborious. We got around this by modifying the rpcgen compiler to generate code for printing nicely formatted trace messages.

These days XML based stuff looks pretty good for most things, but may be too slow for tick data.