[This message was posted by joel louis of <[email protected]> to the "4.2 Changes" discussion forum at http://fixprotocol.org/discuss/5. You can reply to it on-line at http://fixprotocol.org/discuss/read/7db68739 - PLEASE DO NOT REPLY BY MAIL.]
Hi All, Just to add my cents to the conversation if I understood. A single fix engine, using one port for two sessions, only a physically issue on the port on both side will stop any data transfer. Otherwise anything else (i.e the connection has been dropped for a sequence issue)will not disable the port so the second session will still live. In layman word the port is like a motrway if one direction or one lane is blocked the others will still functioning. Hope that help... Joel One FIX engine to support the connection between client and sell-side. Client always initiates the session by and Sell-side replys <-LOGON>. After the session established, data flows in duplex mode. Tha advantage is only one port used. If the session fail, no data to transfer between both sides. If you have to sessions, and one of them is not connected. What do you do? You can send order to trade, but no report back for updating your order management system. > > The inbound and outbound FIX engines are logical units which could be > > handled by a single physical FIX engine instance. > > > > What are the advantages / disadvantages of this approach of using a > > single physical FIX Engine instance as inbound session acceptor and > > outbound session initiator versus using two FIX engine instances one > > as inbound session acceptor and another as outbound session initiator > > ? What is the usual industry practice ? > > > > > I take exception on the answer to question (5). A sell side can > > > certainly use a single FIX engine to handle the communication with > > > both tthe buy side and the exchange. > > > > > > A typical example is an order routing engine at brokage. The broker > > > firm could "inject" their business logic between the in-orders and > > > the out-orders. > > > > > > > > > > > > > > > > Note my answer(s) below > > > > > > > > (1) FIX is primarily used for buy-side to sell-side communication. > > > > (2) FIX is also used for sell-side to exchange communication. > > > > > > > > FIX is being used for both of the above. > > > > > > > > (3) For FIX communication between buy-side and sell-side, we would > > > > need a FIX engine on both sides and a session needs to be > > > > maintained between the 2 engines for any communication to > > > > happen. > > > > > > > > Yes > > > > > > > > (4) For FIX communication between sell-side and exchange, we would > > > > need a FIX engine on both sides and a session needs to be > > > > maintained between the 2 engines for any communication to > > > > happen. > > > > > > > > Yes > > > > > > > >(5) Assuming the above is true, I believe the sell-side can use > > > > a single FIX engine for communication with buy-side as well > > > > as exchange. > > > > > > > > No. There is one Session Acceptor FIX engine which receives > > > > inbound FIX Sessions from Buy side(s). Another Session initiator > > > > FIX engine sends outbound FIX Sessions to Exchanges / other > > > > venues. Between the inbound FIX engine and the outbound FIX engine > > > > there is an application which applies business logic and decides > > > > which exchange would receive the order or slice of the order. > > > > Since one is a Session Acceptor and another is a Session > > > > initiator, two FIX engines are needed at a Sell side. > > > > > > > > (6) Most of the sample code that I see is a buy-side communicating > > > > with a sell-side wherein the sell-side simulates a response. I > > > > want to understand the end-to-end scenario with an exchange > > > > also in picture. Lets say buy-side places an order. Sell-side > > > > receives the order and instead of simulating a response needs > > > > to send the order to the exchange. I am imagining that the sell- > > > > side application picks up the order from buy-side-sell-side- > > > > session, probably makes changes to the sendercompid and > > > > targetcompid, and sends the order on the sell-side- exchange > > > > session to the exchange. Thus an end-to-end scenario will > > > > always involve 2 FIX sessions. Is this correct? > > > > > > > > The two FIX Sessions one between Buy side <-> Sell side and > > > > between Sell side <-> Exchange are independent of each other. Your > > > > description of end-to- end scenario is correct. > > > > > > > > (7) I have some folks telling me that "buy sides will not have a > > > > FIX engine but they will be able to send FIX messages using > > > > some adapter. Only the sell side will have a fix engine to > > > > receive and process these messages.". I believe this is > > > > incorrect. Am I correct? > > > > > > > > Not always, many buy sides would have a FIX engine. There could be > > > > scenarios where the buy side does not have a FIX engine but > > > > instead connects to a service provider who translates between non- > > > > FIX to FIX using an adapter and sends out FIX orders to the Sell > > > > side and translates the FIX executions into non-FIX format and > > > > hands it out to the Buy side. > > > > > > > > The converse is also true. There are exchanges which have non-FIX > > > > interfaces in which case a service provider translates from FIX to > > > > non- FIX Exchange specific format and back. > > > > > > > > > I have a few BASIC questions bothering me and would like to > > > > > understand if I am on the right track. Can you please > > > > > confirm/answer the following: > > > > > > > > > > (1) FIX is primarily used for buy-side to sell-side > > > > > communication. > > > > > > > > > > (2) FIX is also used for sell-side to exchange communication. > > > > > > > > > > (3) For FIX communication between buy-side and sell-side, we > > > > > would need a FIX engine on both sides and a session needs to > > > > > be maintained between the 2 engines for any communication to > > > > > happen. > > > > > > > > > > (4) For FIX communication between sell-side and exchange, we > > > > > would need a FIX engine on both sides and a session needs to > > > > > be maintained between the 2 engines for any communication to > > > > > happen. > > > > > > > > > >(5) Assuming the above is true, I believe the sell-side can > > > > > use a single FIX engine for communication with buy-side as > > > > > well as exchange. > > > > > > > > > > (6) Most of the sample code that I see is a buy-side > > > > > communicating with a sell-side wherein the sell-side > > > > > simulates a response. I want to understand the end-to-end > > > > > scenario with an exchange also in picture. Lets say buy-side > > > > > places an order. Sell-side receives the order and instead of > > > > > simulating a response needs to send the order to the > > > > > exchange. I am imagining that the sell- side application > > > > > picks up the order from buy-side-sell-side- session, > > > > > probably makes changes to the sendercompid and targetcompid, > > > > > and sends the order on the sell-side- exchange session to > > > > > the exchange. Thus an end-to-end scenario will always > > > > > involve 2 FIX sessions. Is this correct? > > > > > > > > > > (7) I have some folks telling me that "buy sides will not have a > > > > > FIX engine but they will be able to send FIX messages using > > > > > some adapter. Only the sell side will have a fix engine to > > > > > receive and process these messages.". I believe this is > > > > > incorrect. Am I correct? > One FIX engine to support the connection between client and sell-side. > Client always initiates the session by <LOGON> and Sell-side replys <- > LOGON>. After the session established, data flows in duplex mode. Tha > advantage is only one port used. If the session fail, no data to > transfer between both sides. If you have to sessions, and one of them is > not connected. What do you do? You can send order to trade, but no > report back for updating your order management system. > > Good luck, peng [You can unsubscribe from this discussion group by sending a message to mailto:[email protected]] -- You received this message because you are subscribed to the Google Groups "Financial Information eXchange" group. To post to this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/fix-protocol?hl=.
