Sequence mismatch when sender sends message before receiving session login response.

[ganeshka...@gmail.com]

I was doing some testing, here is the scenario:

A fix8 server which accepts multiple connections & a fix client (not fix8) which keeps sending messages to the fix8 server.

I noticed one issue with the client , it sends a 35=A to the fix8 server & instead of waiting for a response, it starts sending application messages (35=D, 35=8 etc..) immediately.

In the server i noticed that it replied back with a 35=A, but the sequence number was incremented to some higher value (34=20) & not 1.

After that even the gap fill request went with an incremented sequence number.

I understand that the issue is with the client , but i am wondering how the sequence number in fix8 server got incremented, also this might result in message dropping as the gap fill went with an incremented value.



- Ganesh.

[Ganesh Kawade]

Attaching log files for more information.

[Mazz Barker]

The FIX protocol specifically requires initiator and acceptor to exchange logins before proceeding. The error you're seeing is because the login response is used to sync sequence numbers. Sounds like you should be talking to the other guy about this.
Mazz

[Ganesh Kawade]

Thanks Mazz,

{The FIX protocol specifically requires initiator and acceptor to exchange logins before proceeding}

I was trying to find this in FIX official specifications to address the other guys about it, but couldn't find it mentioned officially anywhere.

Can you guide me , where can i find it.

Regards,

Ganesh K.

--

---
You received this message because you are subscribed to a topic in the Google Groups "fix8 support" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/fix8-support/yoL2kHEG3xU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to fix8-support...@googlegroups.com.
To post to this group, send email to fix8-s...@googlegroups.com.

Visit this group at http://groups.google.com/group/fix8-support.
For more options, visit https://groups.google.com/d/optout.

[dakka]

It's here in the FIX 4.4 spec, vol2, pp6-7

Logon -
Establishing a FIX connection involves three distinct operations: creation of a telecommunications level link,
authentication/acceptance of the initiator by the acceptor and message synchronization (initialization). The
sequence of connection follows:
• The session initiator establishes a telecommunication link with the session acceptor.
• The initiator sends a Logon message. The acceptor will authenticate the identity of the initiator by
examining the Logon message. The Logon message will contain the data necessary to support the
previously agreed upon authentication method. If the initiator is successfully authenticated, the acceptor
responds with a Logon message. If authentication fails, the session acceptor should shut down the
connection after optionally sending a Logout message to indicate the reason of failure. Sending a Logout in
this case is not required because doing so would consume a sequence number for that session, which in
some cases may be problematic. The session initiator may begin to send messages immediately following
the Logon message, however, the acceptor may not be ready to receive them. The initiator must wait for the
confirming Logon message from the acceptor before declaring the session fully established.
After the initiator has been authenticated, the acceptor will respond immediately with a confirming Logon
message. Depending on the encryption method being used for that session, this Logon message may or may
not contain the same session encryption key. The initiator side will use the Logon message being returned
from the acceptor as confirmation that a FIX session has been established. If the session acceptor has
chosen to change the session encryption key, the session initiator must send a third Logon back to the other
side in order to acknowledge the key change request. This also allows the session acceptor to know when
the session initiator has started to encrypt using the new session key. Both parties are responsible for
infinite loop detection and prevention during this phase of the session.
June 18, 2003 6 FIX 4.4 with Errata 20030618- Volume 2

/dakka 

On Thursday, 12 February 2015 18:35:48 UTC+11, Ganesh Kawade wrote:

Thanks Mazz,

{The FIX protocol specifically requires initiator and acceptor to exchange logins before proceeding}

I was trying to find this in FIX official specifications to address the other guys about it, but couldn't find it mentioned officially anywhere.

Can you guide me , where can i find it.

Regards,

Ganesh K.

On Thu, Feb 12, 2015 at 3:43 AM, Mazz Barker <mazzmail.com> wrote:

The FIX protocol specifically requires initiator and acceptor to exchange logins before proceeding. The error you're seeing is because the login response is used to sync sequence numbers. Sounds like you should be talking to the other guy about this.
Mazz

On Wednesday, January 28, 2015 at 9:18:09 PM UTC+11, Ganesh Kawade wrote:

On Wednesday, January 28, 2015 at 1:52:22 PM UTC+4, Ganesh Kawade wrote:
> I was doing some testing, here is the scenario:
>
> A fix8 server which accepts multiple connections & a fix client (not fix8) which keeps sending messages to the fix8 server.
>
> I noticed one issue with the client , it sends a 35=A to the fix8 server & instead of waiting for a response, it starts sending application messages (35=D, 35=8 etc..) immediately.
>
> In the server i noticed that it replied back with a 35=A, but the sequence number was incremented to some higher value (34=20) & not 1.
>
> After that even the gap fill request went with an incremented sequence number.
>
> I understand that the issue is with the client , but i am wondering how the sequence number in fix8 server got incremented, also this might result in message dropping as the gap fill went with an incremented value.
>
>
>
> - Ganesh.

Attaching log files for more information.

--

---

[Ganesh Kawade]

Thanks Dakka.