Initiating FIX Sessions (Logon 35=A) | FIX API for Algorithmic Trading @ Darwinex

[Music] welcome back to this tutorial series on fix API for algorithmic traders and today we'll be talking about how to establish a fixed session between a trader and broker employing fix in terms of agenda will go through credentials and tcp/ip connectivity these being the prerequisites for establishing the fix connection we'll go through an overview of a typical fix authentication sequence this will however focus purely on pricing connections today if you're unfamiliar with pricing connections this is something that was touched upon in the previous tutorial on the anatomy of the fixed protocol I encourage you to watch that prior to watching this video tutorial as the concepts we discussed there and will prove immensely useful in order to understand how things progress in this tutorial today we'll go on from there to break the authentication sequence down into messages in terms of components required the flow required how they're constructed and some specifics some calculations in fact that will explain how how those are done inside the message once it's constructed for validation purposes at both ends the traders and the brokers and we'll conclude with talking about featured tutorials and how we'll take this conversation forwards from establishing a fixed connection to conducting business before we move on though it's important to address amid that circulates among a reasonable proportion of algorithmic traders who have considered fix or are considering fix as a protocol to use as a means to market at the moment and that is that the fixed protocol is somehow complicated and that's simply not true perhaps the reasoning behind that is to do with the fact that the fixed protocol is one of the few that is not as documented as algorithmic traders would prefer it to be there is perhaps a book or two that employees that discusses fix implementation particularly in a single master class or two but apart from that there is just the fixed protocol specification depending on the version that's available online through the fixed trading community website or from your broker who said who if they provide you fix access will of course provide you the fix specification to go with it as we do at Darwin ax so the reality there is that the fixed protocol isn't complicated it is simply a system of rules that are followed by the two parties employing fix and they use that to do two things they use it to recognize each other firstly and once they've recognized each other they conduct business thereafter and that's simply if there's no complication in the protocol per se because the protocol is a means of defining these relationships so rather than go straight into the messaging flow and structure and component tags thereof etc perhaps it will help us to go through this process the system of rules and talk about what the session that we're going to describe in more granular detail later a bit more visually and related to an example in our mineral lives for instance what do we do when someone knocks on our door odds are that if we don't know them we'd like to identify them so let's go through this in the terms with the fixed protocol and see how we can mirror the same example using the fixed protocol and to do that let's head straight to the drawing board assuming that this individual at your doorstep is the traitor and you are the broker and you're both using the fixed protocol to communicate with each other then the trader needs to offer up a few pieces of information that are essential for you to consider establishing a connection at all and these are the following four tags you have sender comp ID the target camp I D the trader also needs a unique username and a corresponding password using the fixed protocol this trader will then package this information into a log on request a special message of message type a if you remember the message type tag 35 from our previous video on the anatomy of the fixed protocol the trader here is going to compose this message and then send it across to the broker at this point in this fix session the broker would then go ahead and validate this information and have one of two responses to offer back in return if the credentials are correct and everything checks out then the broker will send its own logon message back to the trader that yes credentials check out logon requests with message type a sent back to you however if the if the credentials are incorrect or if there's anything else that is wrong with the way the message has been constructed the broker will issue a logout message back to the trader and terminate the connection that message will have value 5 message type equals 5 in fix terminology the trader is the initiator and the broker is the acceptor and to engineer a logon request in the first place not only does the message type of course need to be a 35 equals a but there are a few other flags that need to be set in a pricing connection that we're talking about today that are necessary for the connections we configured correctly and in this case the reset sequence number flag which is tacked 141 in the fixed version 4.4 protocol that needs to be set to why this indicates to both parties the in the indicates from the initiator to the acceptor that it is requesting that both parties reset their message sequence numbers and then make sense in a pricing connection by resetting the sequence numbers there's no possibility of entertaining any past messages the sequence is started afresh in a logon message whenever you start the session the message sequence number that needs to be specified in that message if you remember from the previous tutorial anatomy of the fixed protocol the MSG SEC num flag which is flag 34 needs to be set to 1 when initiating a logon request to start a session effects logon message also requires a few additional parameters that need to be sent across in the first instance and these include the encrypt method which is tagged 98 setting this to zero indicates that no encryption is being used we also need heartbeat interval which is tagged one zero eight will go through heartbeats in future tutorials but for now a heartbeat is essentially an invocation from one party to the other sent after a predefined number of seconds whereby the parties can inform each other that yes we are both alive on the connection and that were processing messages efficiently and that we're here if you need to send anything more that's that's all there is to it so the heartbeat interval message tag 1 0 8 in this case let's for example set it to 20 seconds I'd like to send a heartbeat every 20 seconds and entirely up to you and completely dependent on your implementation and the rest of the message needs to contain the header fields as we discussed in the previous tutorial video the standard header fields which include the begin string body length and sending time and of course these are all in addition to the credential values that we talked about earlier which are the sender comp ID target comp ID username and password now let's see what this message looks like when fully constructed into a fixed message with all its tag value pairs sequenced in the order that they're expected by the acceptor entity so as you can see we start off with the standard header we define the begin string as fixed point for point for the body length of 70 this is these are example values here as I've just written them on this slide they haven't been calculated as they should be in an actual fixed message so therefore these are purely for demonstration purposes this value may change and I'll explain the body length and checksum value shortly on how they're calculated what the procedure is calculate those as it is very important that those values are correctly sent across to the fix engine at the receiving end because if they are not then that will result in a rejection of the message so we start off begin string is fixed for point for body lengths of 17 in this case 35 equals a is the log on message 34 equals 1 as the first message sequence number 49 is your sender comp ID which we just used an example of ABCD 56 equals target comp ID which is e F G H 52 is the sending time is the the moment at which we've sent in UTC timezone the time at which we're sending this message across the encrypt method 98 is zero meaning no encryption used heartbeat interval of 108 a set at twenty seconds for example reset sequence number flag one for one set to Y and a user name tag five five three set to an example user name tag five five four is the password tag and with another example value and finally the checksum is set to one one one in this case purely for example purposes just to demonstrate what the entire message looks like but there is a particular procedure to calculating the checksum as I'll explain shortly as well as sending across the correct body length as I'll also explain shortly and while we're talking about all of this it's important to bear in mind that while this all may look fairly cumbersome on the surface of things with lots of tag value pairs to specify separation control characters to be put in place all of this is easily automated using scripts that will write in future tutorials also via using the quick fix fix engine that we'll be demonstrating in future tutorials and you needn't worry yourself with the structure of this in terms of having to construct this manually each time that is not at all the case and it'll be fairly easy to automate this generation in future tutorials as we will see for now let's talk about how the body length and checksum values are calculated before they're sent across to the acceptor the last field in any fixed message contains the checksum value for the entire message and this is calculated in in this case for example or our example here you contains Pyke characters separating each field tag value pair so in our case what we're going to do is simply replace all these pipe characters with the appropriate control character the start of header character /x is 0-1 as we discussed in the previous tutorial on the anatomy of the fixed protocol and once that's done we now have a string that we can encode in utf-8 and convert to bytes once that string everything before the checksum field has been converted encoded in utf-8 and converted to bytes we then simply need to take the sum of all those values and divide that number by 256 the modulo operation divided by 2 5 6 and whatever number we get equals the checksum bear in mind that if that number for instance is 2 digits not 3 the fix protocol specification version 4.4 dictates that the checksum has to be at least exactly three characters therefore for instance if the result of this operation resulted in for example 18 then you would set your checksum value to 10 equals 0 1 8 you essentially pad the remaining digit that needs to be in place with a zero and that constitutes the checksum value the body length forms part of the standard header and is much simpler to process than the checksum of course in the fixed message the number of characters that are in the fixed message excluding the begin string tag value pair the body length tag value pair the control character between them the checksum tag value pair once you exclude these things whatever characters you have left the number of characters there are equals the body length it's a very simple process now you may be wondering after listening to all of this that there seems to be a fair bit to do when processing a single message in fix and the answer that question is yes there is but the decision to do it all yourself is the only thing that will introduce the additional time into doing this the first time it is highly encouraged that you write reusable code and that's something we will be going through in future tutorials how to write you reusable code so you don't have to go about calculating checksums each time we write a new piece of code etc etc and then there is also the question of well fill tasks such as this calculating checksums figuring our body lengths etc do we really need to write the application code necessary for achieving all of these tasks and the answer is no because there are open source fix engines available such as quick fix that we'll be demonstrating in future tutorials and writing code using in fact these are calculations that need to be done for every single message therefore the fix engines ship with code that does this automatically as part of the application flow leaving you to focus more on the logic of your application as opposed to doing these lower-level calculations and constructions with fixed messaging so bear that in mind the objective here was to demonstrate and make you aware of what goes in to a fixed message how the different components are put together constructed which ones are required when and how what the responses are to a certain construction of a message from an initiator sent from an initiator to an acceptor and vice versa and the idea here was to demonstrate how all of this works and how all of it is put together future tutorials will of course focus on how to do this efficiently using open source fix engines in our case we'll be using the quick fix engine and describing in detail how to work on application flow so that you end up making a fix enabled trading strategy as opposed to spending too much time on doing the lower-level bits that need doing as part of everything as always if you enjoyed this presentation please do consider sharing it with your social networks colleagues co-workers and friends and do subscribe to that r1x YouTube channel so you remain up-to-date with all future videos that will be released in this series and other topics discussed on Darwin X thank you very much for your attention see you next time

Channel: Darwinex

Views: 11,318

Keywords: Forex Trading, FX trading, Investing, DARWINs, Darwinex, Investment, Risk, Hedge fund, fix api, fix protocol, fix api trading, fix trading, fix session, fix engine, algorithmic trading, algorithmic traders, algo trading, SenderCompID, TargetCompID, EncryptMethod, MsgSeqNum, ResetSeqNumFlag, BeginString, BodyLength, MsgType

Id: tpbzmL19tT4

Length: 14min 16sec (856 seconds)

Published: Wed May 01 2019