Session Management

, ,
1

Imported from previous forum

2

There are two questions really

  1. If a fix engine receives the logon(A) message with a sequence number(34) that is greater that expected. Should it reply with a logon(A) and then send the resend request(2) for the missing messages, or should it send the resend request immediately.

  2. The reject message contains a text field(58) to help describe the error that occured.
    There is nothing in the documentation that specfies what content this field should have or not have. I say this because if the text field contains the delimitor char(1) (SOH), then this causes problems on parsing. A length of the text field or rule to not allow SOH will solve this.

3

  1. It should reply with a Logon and then a ResendRequest to fill the gap. See "Response by Message Type" within "Message Recovery" in the "SECTION PROTOCOL" section of FIX 4.1. "After sending a Logon confirmation back, senda ReesendRequest if a message gap was detected in the Logon sequence number".

  2. The Text field on the Reject message in FIX 4.1 is not required. If one has text to specify then they can, if not then that field would simply not appear in the message (vs. no 58=<SOH>). There is a rule that if a tag is specified, a value must exist (e.g. "58=<SOH>" is cause for rejection). The Reject message in FIX 4.1 and earlier does not have any way other than free-form text to identify the reason for the rejection, however, in FIX 4.2 we have added better, more codified means of identifying the reason for the rejection. Specifically FIX 4.2 adds: RefTagID, RefMsgType, and SessionRejectReason (an enumeration vs. free-form text).

> There are two questions really
>
> 1. If a fix engine receives the logon(A) message with a sequence number(34) that is greater that expected. Should it reply with a logon(A) and then send the resend request(2) for the missing messages, or should it send the resend request immediately.
>
> 2. The reject message contains a text field(58) to help describe the error that occured.
> There is nothing in the documentation that specfies what content this field should have or not have. I say this because if the text field contains the delimitor char(1) (SOH), then this causes problems on parsing. A length of the text field or rule to not allow SOH will solve this.
>