Session to disconnect with session level rejection (MsgType = 3)

, ,
1

Imported from previous forum

2

Dear All,

As a SELL side, we are issuing session level reject message (35 = 3) if tag not defined for message type is sent by the BUY side. (We are FIX 4.2. compliant)

After session level rejection we are disconnecting the session also.

Can we follow session disconnection after session level rejection or allow all other incoming mesage request without disconnecting the session?

Thanks in advance.

3

Seems a little harsh to disconnect the session as soon as a single message is received with an invalid tag.

Application level messages such as OrderStatusRequest or NewOrderSingle will not do you any harm. The rejection allows the submitter to take action and “try again”, obviously after he has changed something.

A rogue application firing invalid messages at you is a different story.

Have a look at the FIX Session protocol where severe scenarios are described when you should terminate the session. An invalid tag is a simple error.

Dear All,

As a SELL side, we are issuing session level reject message (35 = 3) if
tag not defined for message type is sent by the BUY side. (We are FIX
4.2. compliant)

After session level rejection we are disconnecting the session also.

Can we follow session disconnection after session level rejection
or allow all other incoming mesage request without disconnecting
the session?

Thanks in advance.

4

Hi Hanno Klein,

Thanks for your reply.
Can you please guide us to find in FIX session protocol (errata) severe scenarios mentioned where we can terminate the session.

Thanking again.

Seems a little harsh to disconnect the session as soon as a single
message is received with an invalid tag.

Application level messages such as OrderStatusRequest or NewOrderSingle
will not do you any harm. The rejection allows the submitter to take
action and “try again”, obviously after he has changed something.

A rogue application firing invalid messages at you is a different story.

Have a look at the FIX Session protocol where severe scenarios are
described when you should terminate the session. An invalid tag is a
simple error.

Dear All,

As a SELL side, we are issuing session level reject message (35 =
3) if tag not defined for message type is sent by the BUY side.
(We are FIX
4.2. compliant)

After session level rejection we are disconnecting the session also.

Can we follow session disconnection after session level rejection or
allow all other incoming mesage request without disconnecting the
session?

Thanks in advance.

5

Look into fix-42-with_errata_20010501.pdf, pages 17-35.

In general, out of sequence errors are the main cause for disconnects because they are very hard to recover from. Typically, it only gets worse, once the sequencing is messed up.

Page 31 talks about rejects and does not describes disconnects as a consequence.

Hi Hanno Klein,

Thanks for your reply. Can you please guide us to find in FIX session
protocol (errata) severe scenarios mentioned where we can terminate
the session.

Thanking again.

Seems a little harsh to disconnect the session as soon as a single
message is received with an invalid tag.

Application level messages such as OrderStatusRequest or
NewOrderSingle will not do you any harm. The rejection allows the
submitter to take action and “try again”, obviously after he has
changed something.

A rogue application firing invalid messages at you is a
different story.

Have a look at the FIX Session protocol where severe scenarios are
described when you should terminate the session. An invalid tag is a
simple error.

Dear All,

As a SELL side, we are issuing session level reject message (35 =
3) if tag not defined for message type is sent by the BUY side. (We
are FIX
4.2. compliant)

After session level rejection we are disconnecting the session also.

Can we follow session disconnection after session level rejection or
allow all other incoming mesage request without disconnecting the
session?

Thanks in advance.

6

Also refer to FIX Session-level Test Cases and Expected Behaviors. “Explicitly identifies the various test cases and expected behavior for FIX Session-level communication. Applies to all 4.x versions of FIX. {SEE ALSO VOLUME 2 OF FIX 4.x SPEC}”

http://fixprotocol.org/documents/614/FIX_TestCase_SessionLevel20010710.doc