Imported from previous forum
what is the major tag to login the FIX? what is the login syntax to
logon the FIX system?
what is the major tag to login the FIX? what is the login syntax to
logon the FIX system?
Vivian,
The Logon Message should always be the FIRST message process on any FIX Session. The message is defined by the MsgType Field(35=A). Logins should always be relayed between parties before any application messages are transmitted.
I’d suggest taking a look at the FIX Spec - 4.0 Session - for details.
You can also take a look at www.openfix.net
dan saad - “I do the FIX”
what is the major tag to login the FIX? what is the login syntax to
logon the FIX system?Vivian,
The Logon Message should always be the FIRST message process on any FIX
Session. The message is defined by the MsgType Field(35=A). Logins
should always be relayed between parties before any application messages
are transmitted.I’d suggest taking a look at the FIX Spec - 4.0 Session - for details.
You can also take a look at www.openfix.net
dan saad - “I do the FIX”
In many cases the logon desires the username and password validation for business layer like Risk Management System. There are no such tags defined in earlier version of FIX i.e 4.0,4.1. In that case you might want to agree with the thirdparty and come up with custom tags which is allowed under the FIX Protocol. Also you can find the existing tags used by other vendors listed under http://www.fixprotocol.org/specifications/fields/6000-6999.
You will have to find the tags used for username / password so that you are along with majority.
[ original email was from Sunil Singh - sunil.singh@gs.com ]
Hi Vivian,
Here’s a sample logon fix message:
2008/02/23 16:28:13:142: CommServer: Received connection from: Socket[69.184.53.24/202.207.181.177, port=62559,localport=8000]
2008/02/23 16:28:13:148: FIXCommConnection: Connection from : Socket[addr=/69.184.53.24,port=62559,localport=8000] accepted and identified as: ABCUAT
2008/02/23 16:28:13:148: FIXPump: Received data on connection {ABCUAT} [8=FIX.4.0_9=0078_35=A_49=ABCUAT_56=XYZTEST_34=1_52=20080223-16:28:07_98=0_108=30_10=214_]
2008/02/23 16:28:13:149: FIXConnectionData: Sending data on connection {ABCUAT} [8=FIX.4.0_9=0069_35=A_34=1_49=XYZTEST_56=ABCUAT_52=20080223-16:28:13_98=0_108=30_10=190_]
2008/02/23 16:28:13:149: FIXFormatter: FIX session established on connection: ABCUAT
Regards,
Sunil Singh
what is the major tag to login the FIX? what is the login syntax to
logon the FIX system?Vivian,
The Logon Message should always be the FIRST message process on any FIX
Session. The message is defined by the MsgType Field(35=A). Logins
should always be relayed between parties before any application messages
are transmitted.I’d suggest taking a look at the FIX Spec - 4.0 Session - for details.
You can also take a look at www.openfix.net
dan saad - “I do the FIX”
Dan,
Your message touches on something that I’ve encountered recently and I wondered if you, or anyone else, could clarify something for me. I don’t know whether you meant to imply that authentication handshaking (i.e. the exchange of Logon messages) must be completed before application messages can be sent, but the FIX.4.0 spec does not seem to me to be so clear.
For instance, in the section “SESSION PROTOCOL” it states “A FIX session is comprised of three parts: logon, message exchange and logout.”, which kind of implies that logon must be completed before message exchange can begin. However, shortly after this in the same section, in the subsection “Logon” it states “The session initiator may begin to send messages immediately following the Logon message, however, the session may not be supported by the other side at this time. The initiator must wait for the confirming Logon message from the acceptor before declaring the session fully established.”
Does this mean that the initiator may send application messages before receiving a Logon message from the acceptor if the parties concerned have a bilateral agreement in place? Obviously, messages received before a session is “fully established” should not be processed, but they could be queued.
Wayne.
Dan,
Your message touches on something that I’ve encountered recently and I
wondered if you, or anyone else, could clarify something for me. I
don’t know whether you meant to imply that authentication handshaking
(i.e. the exchange of Logon messages) must be completed before
application messages can be sent, but the FIX.4.0 spec does not seem to
me to be so clear.For instance, in the section “SESSION PROTOCOL” it states “A FIX session
is comprised of three parts: logon, message exchange and logout.”, which
kind of implies that logon must be completed before message exchange can
begin. However, shortly after this in the same section, in the
subsection “Logon” it states “The session initiator may begin to send
messages immediately following the Logon message, however, the session
may not be supported by the other side at this time. The initiator must
wait for the confirming Logon message from the acceptor before declaring
the session fully established.”Does this mean that the initiator may send application messages before
receiving a Logon message from the acceptor if the parties concerned
have a bilateral agreement in place? Obviously, messages received before
a session is “fully established” should not be processed, but they could
be queued.Wayne.
Wayne, there is no prohibition in the FIX spec that prevents the initiator from sending messages as soon as a Logon message has been sent. But it’ll likely make state handling and encryption a good deal more difficult.
From the acceptor side, there’s no reason why it couldn’t queue up the messages – that’s really just a transport issue.
Before discussing how someone might do this, I’d ask for the use-case. Is there really a reason that an initiator would want to send a series of messages before the connection has been established? I’m not closed to the idea, just interested what reasons there might be. The one reason I could think off-hand is that an initiator is occasionally bringing up a FIX message to blast some messages really quickly before shutting down the session. But that’d probably trying to fix a transport/bandwidth issue and would be better solved via FIX 5.0 with a change of transport semantics.
Wayne, there is no prohibition in the FIX spec that prevents the
initiator from sending messages as soon as a Logon message has been
sent. But it’ll likely make state handling and encryption a good deal
more difficult.From the acceptor side, there’s no reason why it couldn’t queue up the
messages – that’s really just a transport issue.Before discussing how someone might do this, I’d ask for the use-case.
Is there really a reason that an initiator would want to send a series
of messages before the connection has been established? I’m not closed
to the idea, just interested what reasons there might be. The one reason
I could think off-hand is that an initiator is occasionally bringing up
a FIX message to blast some messages really quickly before shutting down
the session. But that’d probably trying to fix a transport/bandwidth
issue and would be better solved via FIX 5.0 with a change of transport
semantics.
Sean,
Thanks for your reply. What you say makes perfect sense and fits in with my reading of the FIX.4.0. I don’t have a specific use-case, I’m just trying to get a handle on the FIX protocol. I have experience with other protocols and it seemed a little unusual, so I wanted to ensure that I hadn’t misunderstood the spec.
Wayne.