API Support Forum
OEC API > Market Data > FIX Logon response and username hashing for FAST Login
Author Topic: FIX Logon response and username hashing for FAST Login
(17 messages, Page 1 of 1)
Moderators: VPfau
AErglis3996
Posts: 24
Joined: Nov 26, 2019


Posted: Jan 14, 2020 @ 02:14 PM             Msg. 1 of 17
I am using goFAST for FAST msg data encoding/decoding on Fedora 31 box. Unfortunately connection with FAST server must be done "by hand" and there is no automatics for this process.

I am able to log into FIX, get FIX Logon response (FastHashcode tag 12004), and get Hello response (template 16002) from FAST server. As stated from specification: FastHashcode must be used as password for Login to FAST server.

Do I need to do some hashing to this FastHashcode? or some other manipulations to be able to pass template 63 to FAST and get back Logon_Response (template 60)? Is there some specific procedure/order for these Admin msg exchange? Something else? Some configuration specific to GAIN?
VPfau
Moderator
Posts: 154
Joined:


Posted: Jan 14, 2020 @ 02:30 PM             Msg. 2 of 17
Hello AErglis3996,

Take a hashcode from 12004 tag of FIX login message, then use this code without modifications at FastFIX login
Vitaliy Pfau
AErglis3996
Posts: 24
Joined: Nov 26, 2019


Posted: Jan 15, 2020 @ 09:43 AM             Msg. 3 of 17
Thanks a lot! Your response shrinks the field of research significantly. The same problem still exists - I am not able "manually" to login in FAST server with template 63.

Probably this problem is due to this - on SCP page 8 one can read:
*****************************************
... The Hello message must appear before any other messages and must appear only once....
******************************************
Do I have to resend this Hello in front of each message? Then - what is bytes structure for such FAST message (hello+ templateID+ fields)? What are PMap or PMaps look like? For instance to send template 63? I can't find it out. Can you please help me with some prompts?! At least - where to look for solution?
VPfau
Moderator
Posts: 154
Joined:


Posted: Jan 15, 2020 @ 10:25 AM             Msg. 4 of 17
Please check out our oecfixsample project https://bitbucket.org/GainFuturesDev/oecfixsample
Vitaliy Pfau
AErglis3996
Posts: 24
Joined: Nov 26, 2019


Posted: Jan 27, 2020 @ 01:35 PM             Msg. 5 of 17
Thank you very much for your time and assistance. I am sorry to bother you again but I need your help more then ever.

After long reading of different exchanges FAST specifications, learning by heart SCP1.1, GAIN examples and documentation:
http://jettekfix.com/education/fix-fast-tutorial/
http://ftp.moex.com/pub/FAST/ASTS/docs/ENG_Market_Data_Multicast_User_Guide_Ver_4_5.pdf
https://www.twse.com.tw/downloads/en/products/FIXFAST_manual-Eng.pdf
...and so on

+ endless experimenting for one and a half month I am still not able to get reasonable (template NR. 60) response from GAIN FAST server. The main lesson from my readings – SCP implementation is highly dependent on server configuration. So,

With straight forward Login inquiry based on template Nr. 63 and all needed fields in place, GAIN FAST servers response is {192, 16003, 2, 11, 0, “Template not supported”}
192 = 11000000 => Presence Map
16003 = 01111101 10000011 => obviously template number however there is no such template in template list. But it doesn't matter.
2, 11, 0 without any template are mystery but it is not important.
The main part in GAIN response is: “Template not supported”

Obviously, there is something wrong because FAST encoded message send from my PC is perfect and checked 10’000+ times. In case someone is suspicious I can send it in full binary, binary FAST encoded and decoded forms. This FAST Login message is well documented in GAIN Examples and there is no mystery at all. Mystery starts with this “Hello” and SCP implementation.

In case I use some code based on SCP1.1 specification as “Hello” message, like this:

192 = 11000000 => Presence Map (or 224 = 11100000 works as well)
16002 = 01111101 10000010 => (with stop bit in bold) Template ID without template in list
+ two what ever fields with stop bits.
I am able to get GAIN FAST servers response: {192, 16002, “OEC FAST Prices” “http://OpenFAST.org/OpenFAST/1.1”}
192 = 11000000 => Presence Map
16002 = 01111101 10000010 => Template ID
After that there is no responses from GAIN server what so ever. I tried to follow recommendations from SCP1.1 to wait for answer on my HELLO and then to try pass template 63. I tried all possible and impossible combinations of fields, templates HELOOs, SenderNames and VendorId's like: "http://www.fixprotocol.org/ns/fast/scp/1.1" and other different combinations but nothing works.
Please help me with FAST login (Hello?) because there is not enough information how to do it? What GAIN server expects to receive bedsides fields what are well stated in GAIN documentation and examples?! What this HELLO should look like?

Thank you in advance!
Arturs
VPfau
Moderator
Posts: 154
Joined:


Posted: Jan 27, 2020 @ 02:24 PM             Msg. 6 of 17
Arturs,

we do not implement FAST protocol ourselves, we use available implementations. We are going to update our fix example project very soon
Vitaliy Pfau
AErglis3996
Posts: 24
Joined: Nov 26, 2019


Posted: Jan 27, 2020 @ 06:53 PM             Msg. 7 of 17
Thank you for quick response! Unfortunately it is not answering my question and not solving Hello problem. Might be with little more effort you can provide me with better answer and some solution to this Login problem?
Arturs.
AErglis3996
Posts: 24
Joined: Nov 26, 2019


Posted: Jan 27, 2020 @ 08:30 PM             Msg. 8 of 17
Just idea - cause your FAST server runs on Windows might be there is need for something like this:
https://docs.microsoft.com/en-us/globalization/encoding/data-encoding
?
Arturs
AErglis3996
Posts: 24
Joined: Nov 26, 2019


Posted: Jan 27, 2020 @ 10:28 PM             Msg. 9 of 17
Thanks Good and your help I get to the point where I have GAIN FAST server response from Template 61: "InvalidUserOrPassword". Can you please check that my password (FIX Tag 12004) and username AErglis3996 is correct for FAST Login? Are you sure that they do not be hashed or what ever manipulated? Because deep in OpenFAST source there is some hashing taking place. Might be your server silently expects some hash sum from me?
Thanks!
Arturs
AErglis3996
Posts: 24
Joined: Nov 26, 2019


Posted: Jan 28, 2020 @ 08:43 AM             Msg. 10 of 17
It seems to me that problem is in fact that template states that HeartBeatInt and MsgType are constant. So there is no need for passing them in FAST MSG. In samples Heartbeat is passed, but in FAST Login documentation is indicated that both of these fields are mandatory. So, after deleting "constant" from templates and passing both of them in FAST MSG, and prepending FAST MSG with HELLO bits like []byte{192, 125, 130, 193, 193} successfully led me to server answer with Template 61: WrongUsernameOrFassword which I hope we will be able to resolve today. Actually I think that this is bug in templates.
AErglis3996
Posts: 24
Joined: Nov 26, 2019


Posted: Jan 28, 2020 @ 10:29 AM             Msg. 11 of 17
Mr. Vitaliy Pfau! Please! I am waiting.
Arturs
VPfau
Moderator
Posts: 154
Joined:


Posted: Jan 28, 2020 @ 11:02 AM             Msg. 12 of 17
No, these fields are constant
I don't think we are interested in our own FAST protocol implementation

Although, we send you the our fix example c# project with external dependencies in it. You can use it as a start point.

Thank you
Vitaliy Pfau
AErglis3996
Posts: 24
Joined: Nov 26, 2019


Posted: Jan 28, 2020 @ 01:09 PM             Msg. 13 of 17
Thank you very much for your attention and helping hand! Unfortunately this file you provided is almost equal to one I already using. Except 4 some minor irreverent differences in token parsing. I sent screen shot of DiffMerge comparison to your e-mail. Question is not about templates but: are my username and password (FIX tag 12004) is valid for FAST login? Please check them!
AErglis3996
Posts: 24
Joined: Nov 26, 2019


Posted: Jan 29, 2020 @ 03:30 AM             Msg. 14 of 17
Please have a look! I am trying to figure out what is wrong. Bytes stream from my application in FAST encoding (binary and decimal representations).

From GF PAI documentation, quot: “Session should be started with HELLO handshake according SCP 1.1.”
So, Hello (how far I was able to figure it out)
11000000 => 192 => Presence Map from SCP1.1 p. 23
01111101 10000010 => Hello template ID 16002 from SCP1.1 p. 23
11000001, 11000001 => two what ever fields. From GF API documentation “SenderName and VendorId fields are used just for information”. In this case I used two “A” and it seems that these fields are really “just for information” without any impact on server response. Regarding SCP1.1 I tried to put in there my Username and in VendorID some URL like: “http://www.fixprotocol.org/ns/fast/scp/1.1”. It has no impact to FAST server response.

Template 63. From GF API documentation in this MSG must be present MsgType, SendingTime HeartbeatInt, Username and Password. Because of that Presence Map should look like this:
11111110=>254. It is in sharp contrast to template file which has stated that MsgType and HeartbeatInt are “Constants”. FAST specification 1.1, 6.3.3 p.13 quote: “The value of a constant field is never transferred.”. So, MsgType and HeartbeatInt should be omitted from Presence Map and MSG fields. However in https://bitbucket.org/GainFuturesDev/oecfixsample/src/master/FAST/FastMessageFactory.cs example and also example file what I got from GF Support one can find that along with SendingTime, Username and Password it sends also HeartbeatInt but not MsgType. Regarding this PresenceMap should be: 11011110=>222 with all but MsgType field in MSG. Such combination is not working. I am going to stick to version which gave me at least some results. I found that there are only two such PresenceMaps. They are: 11000000=>192 or 11100000=>224 however neither of them corresponds to mandatory fields stated in GF API documentation. So, my PresenceMap is:
1) 11000000 => 192
2) 10111111 => Template ID 63
3) 10111111 =>”A” => MsgType, Mandatory field regarding GF API documentation
4) 00000100 01001011 01110011 00101100 00010010 00011000 10000110=> sending time. At this moment it is 20200129072134
5)10110110 => Heartbeat 30
6) 01101001 01110011 00110011 00111001 00111001 10110110=>AErglis3996=>my Username
7) 00110100 00110110……. 11000110=>long Password. FastHashcode from FIX tag 12004
Hello and template fields are passed to server in one stream.

FAST sever response is:
1) 11000000 => Presence Map
2) 01111101 10000010 => Template ID => 16002
3) 01001111 01000101 01000011 00100000 01000110 01000001 01010011 01010100 00100000 01010000 01110010 01101001 01100011 01100101 11110011 => OEC FAST Prices
4) 01101000 01110100 01110100 01110000 00111010 00101111 00101111 01001111 01110000 01100101 01101110 01000110 01000001 01010011 01010100 00101110 01101111 01110010 01100111 00101111 01001111 01110000 01100101 01101110 01000110 01000001 01010011 01010100 00101111 00110001 00101110 10110001=>http://OpenFAST.org/OpenFAST/1.1
5) 11000000=>One more presence map
6) 10111101=>Template ID 61
7) 00000100 01001011 01110011 00101100 00010010 01110111 10110000=>Sending time 20200129084336
8) 01001001 01101110 01110110 01100001 01101100 01101001 01100100 01010101 01110011 01100101 01110010 01001111 01110010 01010000 01100001 01110011 01110011 01110111 01101111 01110010 11100100=>InvalidUserOrPassword

Without Hello MSG in front just passing Login template 63 gives server response:
1) 11000000 => Presence Map
2) 01111101 10000011 => Template ID 16003
3) 10000010, 10001011, 10000000=> for me meaningless numbers: 2, 11, 0
4) 01010100 01100101 01101101 01110000 01101100 01100001 01110100 01100101 00100000 01101110 01101111 01110100 00100000 01110011 01110101
01110000 01110000 01101111 01110010 01110100 01100101 11100100 => Template not supported

Where is mistake?
AErglis3996
Posts: 24
Joined: Nov 26, 2019


Posted: Jan 30, 2020 @ 12:10 PM             Msg. 15 of 17
All my problems boils down to simple thing:

in https://gainfutures.com/GFAPI/ GAIN Futures -> Fast

in the middle (bit upper) part is title: FAST Session Control Protocol 1.1 with text: Session should be started with HELLO handshake...

What is this HELLO handshake?

Thank you in advance for any useful help! Pointing to SCP1.1 specification is not in any use. I know it all by hart and am able to quot it in big chunks. :)
Arturs
AErglis3996
Posts: 24
Joined: Nov 26, 2019


Posted: Jan 30, 2020 @ 01:01 PM             Msg. 16 of 17
Let me boil down this question to yes/no.
Are fields:
1) PresenceMap = 11000000
2) Template ID = 16002
3) Username = myUsername
4) VendorId = http://OpenFAST.org/OpenFAST/1.1
correct for Hello Handshake? Is something missing?
Arturs
AErglis3996
Posts: 24
Joined: Nov 26, 2019


Posted: Feb 04, 2020 @ 02:19 AM             Msg. 17 of 17
Yes it is almost correct. Instead of myUsername GAIN FAST server more like just string "client". Regarding mistake in binary code - mistake is in the fact that you do not need to pass HeartbeetInt and MsgType at all:
...........
3) 10111111 =>”A” => MsgType, Mandatory field regarding GF API documentation <- not needed
.........
5)10110110 => Heartbeat 30 <- also not needed
........
The rest is perfectly OK.
Arturs