I ported ONC RCP-XDR to VAX/VMS and OpenVMS...was not very difficult.
You can find good information here:
http://www.onc-rpc-xdr.com
You can find good information here:
http://www.onc-rpc-xdr.com
Genesis API and custom software
- Thread starter tntneo
- Start date
Looks like commercial software.. how did you port it?
I used the RFC's, then implemented the protocols per the specificiation:
[RFC 1057] RPC: Remote Procedure Call Protocol Specification Version 2.
Obsoletes: RFC 1050.
[RFC 1790] An Agreement between the Internet Society and Sun Microsystems, Inc. in the Matter of ONC RPC and XDR Protocols.
[RFC 1831] RPC: Remote Procedure Call Protocol Specification Version 2.
[RFC 1833] Binding Protocols for ONC RPC Version 2.
[RFC 2695] Authentication Mechanisms for ONC RPC.
Just a suggestion, from my experience, do not go the RPC route...or COBRA, or similar (all based on RPC)...if you do then you'll wind-up with what some feel is a costly, high-latency, synchronous-only, mess.
Instead, just specify a good "binary packet" wire-level protocol and if there's enough demand provide a wrapper that translate it into the non-native endian'ness on machines where there are revenue driven customer requirements (JMHO).
[RFC 1057] RPC: Remote Procedure Call Protocol Specification Version 2.
Obsoletes: RFC 1050.
[RFC 1790] An Agreement between the Internet Society and Sun Microsystems, Inc. in the Matter of ONC RPC and XDR Protocols.
[RFC 1831] RPC: Remote Procedure Call Protocol Specification Version 2.
[RFC 1833] Binding Protocols for ONC RPC Version 2.
[RFC 2695] Authentication Mechanisms for ONC RPC.
Just a suggestion, from my experience, do not go the RPC route...or COBRA, or similar (all based on RPC)...if you do then you'll wind-up with what some feel is a costly, high-latency, synchronous-only, mess.
Instead, just specify a good "binary packet" wire-level protocol and if there's enough demand provide a wrapper that translate it into the non-native endian'ness on machines where there are revenue driven customer requirements (JMHO).
I agree with you 100% as far as wire-protocol goes. I was actually interested in xdr for defining a wire protocol to marshal matrices over the network, to disk, etc in a distributed environment and also for receiving udp broadcasts from redsky.. they have a nice lowlevel feed which is documented.
I'm keenly interested in all aspects of the Genesis API and would like to see further discussion of its operational characteristics and capabilities - with some focus on intelligent order routing, compound order features (execute and apply trailing stop automatically), complex orders with time- and threshold-triggered price improvement features (start buying on bid and if not completely filled after 15 sec, or price limit trigger threshold exceeded, fill the remainder at the ask), technical information and timing statistics for cancel-change-replace-modify operations, and maybe a wish-list discusstion and brainstorming session on advanced order-pairing; like execution and/or cancel triggered 2nd stage orders.
Of course, I could always call Serge
Of course, I could always call Serge
Quote from nbates:
I'm keenly interested in all aspects of the Genesis API and would like to see further discussion of its operational characteristics and capabilities - with some focus on intelligent order routing, compound order features (execute and apply trailing stop automatically), complex orders with time- and threshold-triggered price improvement features (start buying on bid and if not completely filled after 15 sec, or price limit trigger threshold exceeded, fill the remainder at the ask), technical information and timing statistics for cancel-change-replace-modify operations, and maybe a wish-list discusstion and brainstorming session on advanced order-pairing; like execution and/or cancel triggered 2nd stage orders.
Of course, I could always call Serge
Well, I can't comment on most of the items you mention, because I prefer to keep full control of them by doing those tasks in my automated system.
The exception is intelligent order routing. Genesis offers intelligent order routing through INET, ARCA and I believe BRUT. I have found INET to be the best of the three, offering lower average slippage than the other two, and very good speed. My only complaint with INET is that there seems to be some markets that they will not externally route against (I cannot think of which ones). If these markets are alone at the inside price, then INET will just post a locking order instead of routing out against that party for an execution.
My two cents. Best of luck,
-Eric
Eric,
Very good information and thank you for sharing!
I know what you mean about being able to have full-control at the lowest level, but with the right selectable and settable options there could be some performance and price improvement benefits (albeit minor), which could be gained by moving some logic and control (the right pieces) closer to the market.
I've done some API's that have auto-trailing stop and others that don't, and none have buy/sell-with-tracking on the bid/ask, so we do that manually too.
My preference is to let the order servers deal with execution, price improvement and basic risk-management ("the how"), so we can focus on the when, why and how much.
PS. Thanks again for the INET info.
-norman
Very good information and thank you for sharing!
I know what you mean about being able to have full-control at the lowest level, but with the right selectable and settable options there could be some performance and price improvement benefits (albeit minor), which could be gained by moving some logic and control (the right pieces) closer to the market.
I've done some API's that have auto-trailing stop and others that don't, and none have buy/sell-with-tracking on the bid/ask, so we do that manually too.
My preference is to let the order servers deal with execution, price improvement and basic risk-management ("the how"), so we can focus on the when, why and how much.
PS. Thanks again for the INET info.
-norman
Hi Stephen,
This seems to be a general problem. You always have to run some kind of a piece of win32 software as your local socket server (except perhaps for TWS having a linux version, still requiring jre though). I also have been thinking of using wine to run from a linux platform. Could you give a few more details on how you made out with your earlier wine experiment?
Connecting to that socket is the easy part. You can almost do that in any way you want.
Be good,
nononsense
Sure. First of all I used winebuild to create a wrapper around the native win32 dll. This doesn't work for c++ libraries yet so I ended up using the stripped down C version, I believe it is GTAPIB. Things mostly worked.. e.g. I could connect to the servers, login, etc, but none of the callbacks were working. I suspect it had something to do with calling conventions.
I ended up giving up and installed vmware. I run a process inside vmware running XP on my linux box, which connected to genesis and then communicated with the native linux via a socket and a binary protocol.
Hope this is of some help.
--Stephen
I ended up giving up and installed vmware. I run a process inside vmware running XP on my linux box, which connected to genesis and then communicated with the native linux via a socket and a binary protocol.
Hope this is of some help.
--Stephen