3.如果入向消息序号>NxtIn，那么表明有消息被遗漏。
因为LFIXT使用TCP为传输协议，出现这种情况说明发生了严重异常错误，应立刻终止当前会话。
二.1.6心跳
在消息交换的空闲期间，连接双方将以规定的时间间隔产生心跳消息。
通过心跳消息可以监控通讯连接的状态并识别出入向消息序号的缺口。
心跳间隔时间由会话发起人通过登录消息的HeartBtInt字段确定。
在传送了任何消息（而不仅仅是心跳消息）之后，都应立即重置心跳间隔计时器。
心跳间隔时间应该得到连接双方的确认，由会话发起人给出，并得到会话接受方的确认。
连接双方应使用相同的心跳间隔时间。
每个心跳消息都将占用一个MsgSeqNum消息序号。
二.1.7有序消息处理
LFIXT会话协议采用TCP连接作为底层通信机制，会话建立后，在同一个TCP连接的延续期间，接收方在发现入向消息缺口时，说明发生了严重异常，建议接收方终止该会话并断开TCP连接。
如果接收方为会话的发起方，则应根据需要重建会话。
二.1.8可能的消息重复传送
本会话协议采用TCP连接作为底层通信机制，会话双方在建立TCP连接之后，通过Logon消息进行序号协商，其后则是基于TCP进行的连续通信，正常情况下，不应该出现前面消息丢失却收到后面消息的情形。
所以，1）在发现入向消息序号缺口时，LFIXT会话协议的实现者不会发送重传请求，而是回送Logout后直接断开连接，但2）允许在入向消息中出现重传请求（比如基于标准FIX引擎的通信对手方虽然收到前面的消息但自己没保存，并期望能按标准FIX会话层协议通过重传请求取回），对此LFIXT会话协议实现者将简单回送SeqReset-Reset消息予以打发，3）允许在入向消息中出现PossDupFlag=Y的消息（比如基于标准FIX引擎的通信对手方虽未收到本方发出的重传请求，但仅仅因为怀疑本方可能错过某些消息，而向本方发送这类PossDupFlag=Y的消息）。
二.1.9可能的消息重新发送
在LFIXT会话协议中，应用层重发的标志应在应用层协议中明确设置，而不应该体现在会话层消息的标志位上。
由于互操作的对方必须遵从同样的应用层协议，因此LFIXT会话协议将不会给出向消息打上任何PossibleResend标志。
LFIXT会话协议允许在入向消息头中出现PossibleResend标志，但将忽略该标志，直接将不附带该标志的消息交由应用层处理。
二.1.10消息完整性
消息数据内容的完整性可以用两种方式来验证：
验证消息长度，及字符的简单校验和。
消息长度被包括在BodyLength字段中，可以通过清点消息之中跟在BodyLength字段之后、直至并包括直接先于CheckSum域号（”10=”）出现的那个域界定符之间的字符来验证。
校验和的验证方法是：
从消息头中‘8=’中的‘8’开始、直到并包括直接先于CheckSum域号‘10=’出现的字符，将每个字符的二进制值加总后，将计算值的最低8位同CheckSum字段中的值进行比较。
二.1.11混乱的消息（garbledmessage）
根据标准FIXT协议的附录，当至少出现以下情形之一时，一条消息被称为“混乱的”：
BeginString（tag8）不是消息的第一个标签，或不以8=FIXT.n.m的形式出现。
BodyLength（tag9）不是消息的第二个标签，或未包含正确的字节计数
MsgType（tag35）不是消息的第三个标签
CheckSum（tag10）不是最后的标签，或其取值不正确
若MsgSeqNum（tag34）缺失，必须立刻终止FIX连接，因为这表明出现了严重的应用错误，很可能只能通过修改软件来绕过。
二.1.12消息确认
由于会话层协议是基于乐观的消息传输模式，通过监视消息序号发现缺口，不支持对每个消息收发的确认。
但大量消息收发的确认可在应用层定义。
在应用层接受和拒绝是允许的。
二.1.13加密
LFIXT会话层不对数据进行加密处理，会话双方可考虑使用通信层的加密机制。
二.2会话管理
LFIXT会话协议采用TCP连接作为底层通信机制。
若LFIXT会话协议的实现者作为会话的主动发起方，必须在每次新建TCP连接之后通过置位序号重设标志（ResetSeqNumFlag）的Logon消息来将起始消息序号重置回1，因此，此时会话和TCP连接是一一对应的。
虽然LFIXT会话协议可以被设计成底层使用两个独立的TCP连接，每个连接都以单工模式工作，但由于在TCP连接上实现全双工的通信并不困难且维护简单，因此LFIXT会话协议规定：
对于单个会话而言，同时只使用一个全双工的TCP连接。
若LFIXT会话协议的实现者作为会话的接收方，由于该会话的发起方可能是标准的FIX引擎，此时建立的会话可以跨越多个TCP连接。
在单次TCP连接内部，每个会话都分为三个部分：
建立会话、消息交换、终止会话。
二.2.1建立会话
建立会话包含三个步骤：
建立连接（即为建立TCP连接）、身份认证、消息同步。
二.2.1.1建立连接
LFIXT会话的发起方与接受方建立TCP连接。
LFIXT会话协议的实现者在TCP连接建立后，应当总是初始化NxtIn=1,NxtOut=1。
二.2.1.2身份认证
1.会话发起方发送登录消息（Logon），接受方认证发起方身份的合法性。
2.如果发起方身份通过认证，则接受方发送一个登录消息作回应。
3.如果认证失败，会话接受方则在可选地发送一个含失败说明的注销消息（Logout）后关闭连接。
发送注销消息并非是必须的，因为这样做会消耗一个序号，在某些情况下可能会引起其他问题。
4.会话发起方必须等待来自接受方的确认Logon消息，方可向接受方发送其他消息。
否则，接受方可能尚未准备好接收它们。
5.在发起方被认证后，接受方将立即回应一个确认Logon消息。
发起方将把从接受方返回的Logon消息作为“一个会话已经建立”的确认。
二.2.1.3消息同步
LFIXT会话协议并不提供真正的会话层重传机制，因此LFIXT会话协议的实现者作为会话的发起方，可通过会话重置消息（即ResetSeqNumFlag=Y的Logon消息）将会话双方的消息序号重置，来完成会话层消息同步。
LFIXT会话协议的实现者作为会话接受方，可以利用Logon消息中的NextExpectedMsgSeqNum来完成会话层消息同步。
这种方式提供了对标准FIX会话协议的消息同步的兼容，具体机制参见“登录消息处理”一节。
二.2.2消息交换
在建立会话之后，会话双方可以开始进行正常的消息交换。
交换的消息包括“管理消息”和“应用消息”，本规范仅对管理消息进行描述。
应用消息请参见具体的数据接口规范。
二.2.3注销会话
LFIXT会话的正常结束是通过连接双方互相发送注销消息（Logout），注销时不需要进行消息缺口检查。
若结束时没有收到回送的注销消息（Logout），则把对方视作已注销。
除此之外的其它方式的会话结束视为非正常，并应按错误来处理。
在结束会话之前，注销消息（Logout）的发起方应该等待对方回送的注销消息（Logout）。
如果接收方在一定时间内没有答复，那么会话就可以立即中断。
二.3恢复
LFIXT会话协议的会话层恢复机制是为了与标准Fix会话协议兼容，不能作为真正的消息恢复机制使用，会话对端应通过应用层的消息恢复机制来获得缺失的数据。
LFIXT会话协议的实现者只在建立会话阶段存在消息序号同步，在会话持续期间不提供真正的消息恢复，而是简单地通过回应SeqReset-Reset消息来打发消息重传请求。
二.3.1登录消息处理
LFIXT会话协议的实现者作为会话接收方,只需将本方NxtIn设置为发起方Logon消息的MsgSeqNum+1，NxtOut设置为发起方Logon消息中的NextExpectedMsgSeqNum（789）即可。
会话接收方不需要检查任何缺口，会话接收方也不会向发起方请求重传任何消息。
如果发送方没有提供NextExpectedMsgSeqNum字段，则NxtOut设置为1.
二.3.2重传请求消息处理
作为LFIXT会话协议的实现者不会主动发送重传请求，但可能收到标准的FIX会话协议实现者发送的重传请求。
当LFIXT会话协议的实现者收到重传请求时，会使用SeqReset-Reset消息重置发送方序号，而不会提供历史消息的重传。
二.3.3序号重设消息处理
LFIXT会话协议的实现者收到序号重设消息时，会根据序号重设消息中的NewSeqNo来重置本方NxtIn。
三、消息定义
三.1消息结构
每一条消息都由消息头、消息体、消息尾组成。
消息总是由标准消息头开始，标准消息尾结束。
三.1.1消息头
会话双方所有交换的消息具有如下标准的消息头。
每一个消息都由一个标准消息头开始。
消息头定义了消息的类型，长度，目的地，顺序号，起始点和时间等数据域，均不加密传输。
其中有两个域用于消息重发。
当作为会话级事件的结果而重复传送消息时，PossDupFlag被设置为Y，发送时沿用原来的消息序号；当[应用级]重新发送消息时，使用新的消息序号，并将PossResend设置为Y。
接收者应按以下方法处理上述消息：
PossDupFlag=Y：
如果以前曾经收到过带有该消息序号的某条消息，则忽略本消息，如果不是，则按正常步骤处理。
PossResend=Y：
不附带本标志地将消息传递给应用层，由其确定此前是否收到该消息
Tag
域名
必须
字段描述
8
BeginString
Y
起始串FIXT.1.1（总是不加密，必须是消息的第一个域）
9
BodyLength
Y
消息体长度（总是不加密，必须是消息的第二个域）
35
MsgType
Y
消息类型（总是不加密，必须是消息的第三个域）
49
SenderCompID
Y
发送方代码字符串（总是不加密）
56
TargetCompID
Y
接收方代码字符串（总是不加密）
34
MsgSeqNum
Y
消息序号，整数类型
43
PossDupFlag
N
会话层可能重传标志，重复传送时，作此标记
97
PossResend
N
应用层可能重发标志。
LFIXT会话层协议的实现者不会在出向消息中主动设置本字段，对于入向消息中出现的本字段将简单忽略
52
SendingTime
Y
发送时间，UTCTimestamp类型
347
MessageEncoding
N
消息中编码域的字符编码类型，缺省为GBK
三.1.2消息尾
会话双方所有交换的消息具有如下标准的消息尾。
每一个消息（管理或应用消息）都用一个消息尾终止。
消息尾可用于分隔多个消息，包含有3位数的校验和值。
Tag
域名
必须
字段描述
10
CheckSum
Y
校验和，总是消息的最末域，总是不加密
三.2管理消息
LFIXT会话协议支持标准FIX会话协议的所有管理消息，但不会主动发送所有管理消息。
LFIXT会话协议分两种模式：
精简模式和兼容模式，各自有不同的使用范围。
已知通信对手方为LFIXT会话协议实现者时，可以采用精简模式，此时只需要支持如下消息的接收和发送处理。
此时由于本方不会主动发送ResendRequest，因此根据协议也不会触发对方回应SeqReset-Reset，因此不需要处理入向的SeqReset-Reset消息：
管理消息类型
来自对方
本方发送
Heartbeat
是
是
Logon
是
是
Reject
是
是
Logout
是
是
表1 精简模式：
仅和LFIXT实现者通信时
当需要和基于标准FIX引擎的对手方进行通信时，必须采用兼容模式。
此时LFIXT会话协议实现者需要支持所有管理消息的接收，但仍然不需要支持所有管理消息的发送。
兼容模式和精简模式主要的区别只在于前者需要处理更多的入向管理消息。
管理消息类型
来自对方
本方发送
Heartbeat
是
是
Logon
是
是
TestRequest
是
否
ResendRequest
是
否
Reject
是
是
SeqReset-Reset
是
是
SeqReset-GapFill
是
否
Logout
是
是
升级会员 