QuickFix and Genesis Securities

do you know what the standard reply should be after a logon request?

 

I think you should see "Received logon response" in you log right after you sent logon request (35=A)

 

Im thinking that the problem is the logon message Im sending. Attempts to get a working message example from Genesis hasn't turned up anything.

Iv tried removing and readding every optional field without any change.

Could anyone here who uses FIX through Genesis post an example of the logon message they use? (with unique info censored)

 

Are you sure your connect to the right FIX port? As someone mentioned earlier in the post you should get a connection established or connection refused when you type telnet (FIX_SVR_ADDR) (PORT)

if your using QuickFix fileLog you should see logs that look like the following:

FIX.4.2-XXX-XXX.event.log
FIX.4.2-XXX-XXX.messages.log

Your event log upon successful login will show something like the following:

20081030-13:25:50: Session state is not current; resetting FIX.4.2:FRZ->ISE
20081030-13:25:50: Created session: FIX.4.2:FRZ->ISE
20081030-13:25:51: Initiated logon request
20081030-13:25:52: Received logon response

In your FIX messages.log you should see a 35=A when you have logged in successfully. If you have not already you can ask Genesis for their offical fix SPEC.

Best of luck we use QuickFix/J here and connect to NYSE, ISE, CBOE, NASD, PHLX via FIX with no issues at all.

 

If you are getting no response at all, it is probably not a firewall issue. If it were a firewall issue, the quickfix engine would not detect a connection, and thus not send the logon.

Many exchanges choose to send NOTHING if the logon message contains invalid authentication (bad user name/password) or if the message is lacking certain fields. This is done to prevent hacking attempts. That is, if the FIX engine replied "invalid login" or worst case "invalid password" then at least the hacker knows he's on the right path...with no response, an auto script may simple gove up and try the next spot.

Call Genesis...be angry, and escalate it.

 

With all due respect (I know I am rough around the edges when communicating)...

All I see is everyone guessing as to what the problem is. Do a little more homework, and get to the heart of the matter.

Run a tcpdump (packet capture) software on your machine, and capture the full TCP session. You can then see, precisely, what is being communicated in the FIX stream. This will allow you to quickly pinpoint the problem (rather than all the guessing which has gone on).

Some packet capture applications you can run...

http://www.wireshark.org/

http://www.winpcap.org/misc/links.htm#tools

http://www.nirsoft.net/utils/smsniff.html

I have personally used SmartSniff (per the last URL listed) to decode idiotic FIX "customizations" that were causing problems, along with reverse-engineering middleware API's that insisted I run their software on a Windows computer in order to communicate with their back-end order entry system (e.g., Interactive Brokers, whose middleware simply converts .NET calls to FIX for their back-end).

I wish more brokerage firms would do what OptionsXpress did, and have a direct-access web-based API available, that can take http/https POST, GET or even SOAP requests (as OX can). For a non-institutional trader, forcing us to go FIX (in order to gain access to a non-middleware API) is ludicrous.

 

Lewcifer,

With all due respect as well, I am not guessing. Many firms that accept FIX connections do not have simulation environments, and thus are very quick to disconnect or not respond on bad data. While your suggestions are good, it seems to me that walterjennings is a little new to this in general, so he would probably have an equally tough time with the products that you suggested as he is with Genesis. So, my suggestion to call genesis, act angry enough to get someone on the phone who cares, and work through a login with a tech on the phone, is valid.

walter, 20 years ago I was a "lab consultant" for a intro to programming computer lab at the university I attended, so I am not trying to offend you, but...when you say you are sending:

8=FIX.4.2
9=91
35=A
34=1
49=sendercompid
52=20081022-20:16:48.741
56=targetcompid
95=19
96=username,password
98=0
108=30
141=Y
10=118


I assume that for tag/value 49=sendercompid

you are not actually putting in the text "sendercompid" and ditto for 96=username,password

I assume you just didn't want to divulge your own info...but, sometimes assuming too much can be bad...

again...get thru to genesis and have a tech on the line, looking at their logs when you send your login...they'll tell you what is wrong, and it may take a couple of attempts and tweaks.

 

ya sendcompid etc are just censored account information.

 

It turns out I am having this same exact issue right now. This is my first experience with FIX and the QuickFix library.

 

solved the issue. turned out to be desync'd system vs server time. fixed it by going to the NIST atomic clock website and setting my windows clock to within 1 second of it.