Version1.00 轻量级STEP会话层接口规范 2015-08-28
(NxtIn)，用以监视接收的消息序号，以保证消息缺口的发现和处理。
会话建立后，当LFIXT协议实现者接收到的消息序号不等于预期接收的消息序号(NxtIn)时，需要考虑进行修正处理。这里有几种情况：
1. 如果入向消息序号< NxtIn，且不属于前文脚注中注明的若干种情况之一时：表明发生了严重的错误，必须立即结束会话，并开始进行人工干预。 2. 如果入向消息序号< NxtIn，且属于前文脚注中注明的若干种情况之一，不属于错误，应进行正常处理。
3. 如果入向消息序号> NxtIn，那么表明有消息被遗漏。因为LFIXT使用TCP为传输协议，出现这种情况说明发生了严重异常错误，应立刻终止当前会话。 2.1.6 心跳
在消息交换的空闲期间，连接双方将以规定的时间间隔产生心跳消息。通过心跳消息可以监控通讯连接的状态并识别出入向消息序号的缺口。
心跳间隔时间由会话发起人通过登录消息的HeartBtInt字段确定。在传送了任何消息(而不仅仅是心跳消息)之后，都应立即重置心跳间隔计时器。心跳间隔时间应该得到连接双方的确认，由会话发起人给出，并得到会话接受方的确认。
连接双方应使用相同的心跳间隔时间。每个心跳消息都将占用一个MsgSeqNum消息序号。
2.1.7 有序消息处理
LFIXT会话协议采用TCP连接作为底层通信机制，会话建立后，在同一个TCP连接的延续期间，接收方在发现入向消息缺口时，说明发生了严重异常，建议接收方终止该会话并断开TCP连接。如果接收方为会话的发起方，则应根据需要重建会话。
2.1.8 可能的消息重复传送
本会话协议采用TCP连接作为底层通信机制，会话双方在建立TCP连接之后，通过Logon消息进行序号协商，其后则是基于TCP进行的连续通信，正常情况下，不应该出现前面消息丢失却收到后面消息的情形。所以，1) 在发现入向消息序号缺口时，LFIXT会话协议的实现者不会发送重传请求，而是回送Logout后直接断开连接，但2)允许在入向消息中出现重传请求（比如基于标准FIX引擎的通信对手方虽然收到前面的消息但自己没保存，并期望能按标准FIX会话层协议通过重传请求取回），对此LFIXT会话协议实现者将简单回送SeqReset-Reset消息予以打发，3）允许在入向消息中出现PossDupFlag = Y3的消息（比如基于标准FIX引擎的通信对手方虽未收到本方发出的重 3. 除了REJECT消息之外，其他管理消息理论上都不应被重发，而是通过发送带有同样消息序号的、带有
PossDupFlag标志的SeqReset-GapFill消息对原消息进行替代。在此过程中，被替代的SeqReset-GapFill
第4页共38页
Version1.00 轻量级STEP会话层接口规范 2015-08-28
传请求，但仅仅因为怀疑本方可能错过某些消息，而向本方发送这类PossDupFlag =Y的消息4）。
2.1.9 可能的消息重新发送
在LFIXT会话协议中，应用层重发的标志应在应用层协议中明确设置，而不应该体现在会话层消息的标志位上。由于互操作的对方必须遵从同样的应用层协议，因此LFIXT会话协议将不会给出向消息打上任何Possible Resend标志。
LFIXT会话协议允许在入向消息头中出现Possible Resend标志，但将忽略该标志，直接将不附带该标志的消息交由应用层处理。
2.1.10 消息完整性
消息数据内容的完整性可以用两种方式来验证：验证消息长度，及字符的简单校验和。
消息长度被包括在BodyLength字段中，可以通过清点消息之中跟在BodyLength字段之后、直至并包括直接先于CheckSum域号（”10=”）出现的那个域界定符
校验和的验证方法是：从消息头中‘8=’中的‘8’开始、直到并包括直接先于CheckSum域号‘10=’出现的
2.1.11 混乱的消息(garbled message)
根据标准FIXT协议的附录，当至少出现以下情形之一时，一条消息被称为“混乱的”：
BeginString(tag 8) 不是消息的第一个标签，或不以 8=FIXT.n.m 的形式出现。 BodyLength(tag 9)不是消息的第二个标签，或未包含正确的字节计数 MsgType(tag 35) 不是消息的第三个标签
CheckSum(tag 10)不是最后的标签，或其取值不正确
若MsgSeqNum(tag 34)缺失，必须立刻终止FIX连接，因为这表明出现了严重的应用错误，很可能只能通过修改软件来绕过。
消息本身虽然仍然以同样的消息序号、带上同样被置位的PossDupFlag标志出现，也被FIX标准解释为
“替代”而非“重发”。
4. （PossDupFlag =Y）为Y的管理消息请参见具体的消息定义
第5页共38页
Version1.00 轻量级STEP会话层接口规范 2015-08-28
2.1.12 消息确认
由于会话层协议是基于乐观的消息传输模式，通过监视消息序号发现缺口，不支持对每个消息收发的确认。但大量消息收发的确认可在应用层定义。在应用层接受和拒绝是允许的。
2.1.13 加密
LFIXT 会话层不对数据进行加密处理，会话双方可考虑使用通信层的加密机制。
2.2 会话管理
LFIXT会话协议采用TCP连接作为底层通信机制。
若LFIXT会话协议的实现者作为会话的主动发起方，必须在每次新建TCP连接之后通过置位序号重设标志(ResetSeqNumFlag)的Logon消息来将起始消息序号重置回1，因此，此时会话和TCP连接是一一对应的。
虽然LFIXT会话协议可以被设计成底层使用两个独立的TCP连接，每个连接都以单工模式工作，但由于在TCP连接上实现全双工的通信并不困难且维护简单，因此LFIXT会话协议规定：对于单个会话而言，同时只使用一个全双工的TCP连接。
若LFIXT会话协议的实现者作为会话的接收方，由于该会话的发起方可能是标准的FIX引擎，此时建立的会话可以跨越多个TCP连接。
在单次TCP连接内部，每个会话都分为三个部分：建立会话、消息交换、终止会话。 2.2.1 建立会话
建立会话包含三个步骤：建立连接（即为建立TCP连接）、身份认证、消息同步。 2.2.1.1 建立连接
LFIXT会话的发起方与接受方建立TCP连接。LFIXT会话协议的实现者在TCP连接建立后，应当总是初始化NxtIn = 1, NxtOut = 1。 2.2.1.2 身份认证
1. 会话发起方发送登录消息（Logon），接受方认证发起方身份的合法性。 2. 如果发起方身份通过认证，则接受方发送一个登录消息作回应。
3. 如果认证失败，会话接受方则在可选地发送一个含失败说明的注销消息
（Logout）后关闭连接。发送注销消息并非是必须的，因为这样做会消耗一个序号，在某些情况下可能会引起其他问题5。
4. 会话发起方必须等待来自接受方的确认Logon消息，方可向接受方发送其他消
息。否则，接受方可能尚未准备好接收它们。
5. 在发起方被认证后，接受方将立即回应一个确认Logon消息。发起方将把从接 5. 这个问题和标准FIX引擎对于报文所属会话的认定方式有关 ,单在LFIXT引擎方面则并无不妥。
第6页共38页
Version1.00 轻量级STEP会话层接口规范 2015-08-28
受方返回的Logon消息作为“一个会话已经建立”的确认。
2.2.1.3 消息同步
LFIXT会话协议并不提供真正的会话层重传机制，因此LFIXT会话协议的实现者作为会话的发起方，可通过会话重置消息（即ResetSeqNumFlag=Y的Logon消息）将会话双方的消息序号重置，来完成会话层消息同步。
LFIXT会话协议的实现者作为会话接受方，可以利用Logon消息中的NextExpectedMsgSeqNum来完成会话层消息同步。这种方式提供了对标准FIX会话协议的消息同步的兼容，具体机制参见“登录消息处理”一节。 2.2.2 消息交换
在建立会话之后，会话双方可以开始进行正常的消息交换。交换的消息包括“管理消息”和“应用消息”，本规范仅对管理消息进行描述。应用消息请参见具体的数据接口规范。 2.2.3 注销会话
LFIXT会话的正常结束是通过连接双方互相发送注销消息（Logout），注销时不需要进行消息缺口检查。若结束时没有收到回送的注销消息（Logout），则把对方视作已注销。除此之外的其它方式的会话结束视为非正常，并应按错误来处理。
在结束会话之前，注销消息（Logout）的发起方应该等待对方回送的注销消息（Logout）。如果接收方在一定时间内没有答复，那么会话就可以立即中断6。 2.3 恢复
LFIXT会话协议的会话层恢复机制是为了与标准Fix会话协议兼容，不能作为真正的消息恢复机制使用，会话对端应通过应用层的消息恢复机制来获得缺失的数据。
LFIXT会话协议的实现者只在建立会话阶段存在消息序号同步，在会话持续期间不提供真正的消息恢复，而是简单地通过回应SeqReset-Reset消息来打发消息重传请求。 2.3.1 登录消息处理
LFIXT会话协议的实现者作为会话接收方,只需将本方NxtIn 设置为发起方Logon消息的MsgSeqNum + 1，NxtOut 设置为发起方 Logon消息中的
NextExpectedMsgSeqNum(789)即可。会话接收方不需要检查任何缺口，会话接收方也不会向发起方请求重传任何消息。如果发送方没有提供NextExpectedMsgSeqNum字段，则NxtOut 设置为1. 2.3.2 重传请求消息处理
作为LFIXT会话协议的实现者不会主动发送重传请求，但可能收到标准的FIX会话协议实现者发送的重传请求。当LFIXT会话协议的实现者收到重传请求时，会使用 6. 注销不影响任何订单的状况。所有有效的订单都可在注销（Logout）之后执行。
第7页共38页
相关推荐：
loading