【FIX协议】金融信息交换协议（FIX）5.0 FIXT1.1（4）

5 ADMINISTRATIVE MESSAGES管理消息

管理消息强调协议的应用需求。以下部分内容描述了每个管理消息，提供消息的图表。

管理消息由连接各方产生。

5.1 Heartbeat 心跳消息

心跳消息监控通信链路的状态，用于识别一连串消息中最后没有收到的消息。

当如果一个FIX连接的任何一方在超过HeartBtInt规定的时间间隔后没有收到任何数据，将发送一个Hearbeat消息。当如果一个FIX连接的任何一方在超过HeartBtInt规定的时间间隔加上一些传输时间后没有收到任何数据，将发送一个Test Request测试请求消息。如果在超过HeartBtInt规定的时间间隔加上一些传输时间后仍然没有收到Heartbeat消息，那么应视为连接断开并应采取纠错处理。如果HearBtInt设置为0，则不会产生常规的Heartbeat消息。注意，一个测试请求消息能够不间隔HeartBtInt的值被发送，用于强制请求一个Heartbeat消息。

Heartbeat消息作为测试请求消息的响应，必须包含在请求测试消息中的TestReqID值，用于验证Heartbeat消息是测试请求消息的响应而不是常规超时的响应。

Heatbeat消息格式如下：

Heartbeat

5.2 Logon   登陆消息

Logon消息认证一个连接到一个远程系统的用户。Logon消息必须是应用程序用于请求初始化一个FIX会话的第一个消息。

HeartBtInt（108）域用于申明产生心跳消息的时间间隔，连接双方使用形同的HeartBtInt值。其值应被双方企业一致同意，由Logon消息发起者初始化，并被Logon接收者回应。

当接收到Logon消息，会话接收者将认证参与者的连接请求，并发出一个Logon消息确认连接请求被接受。这个确认Logon消息也能用于发起者验证连接已经与对端正确建立。

在接收到Logon消息后会话接收者必须立即准备好开始处理消息。会话发起者可以选择在收到Logon确认消息前传输FIX消息，但推荐在收到返回的Logon消息后，完成加密秘要协商后进行正常的消息传输。

确认Logon消息可以用于加密秘要协商。如果一个会话密钥被认为是弱秘要，一个推荐的新的更加强状的会话秘要将在Logon消息中返回。这仅在加密协议允许秘要协商时有效。

Logon消息能用于确定支持的消息最大长度MaxMessageSize（能用于控制将大消息进行分节的规则）。也能用于确定双方接收和发送所支持的消息的类型MsgType。

下表是Logon消息的格式：

Logon

5.3 Test Request 测试请求消息

测试请求消息强制对方发送一个Heartbeat消息。测试请求消息检查序列号或验证通信线路状态。对端应用程序响应一个包含TestReqID的Heartbeat消息。

TestReqID用于检查对端应用是依据测试请求消息产生的Heartbeat消息，而不是通常的超时。对端应用程序将TestReqID包含在响应Heartbeat消息中。任何字符串可以被用于TestReqID（一个建议是使用时间戳字符串）。

测试请求消息格式如下：

Test Request

5.4 Resend Request 重传请求消息

重传请求消息由接收用用程序发送用于开始消息的重传。这个功能在序列号间隙被侦测到时，在接受应用程序丢失消息时，或者作为一个初始化处理功能时非常实用。

重传请求消息能用于请求一个单一消息，一定范围内的消息，或者一个特定消息的所有后续消息。

注意：发送应用程序可能希望考虑重传消息的消息类型。如：如果在重传序列中的一个新指令消息在其最初发送后经过一段相当长的时间，那么发送方可能不希望重传该消息以提供改变市场条件的潜在可能性。（Seqence Reset-GapFill消息用于发送方不希望发送二跳过这类消息。）

注意：接收程序必须按照顺序处理消息。如：如果收到消息8和9，消息7丢失，程序应忽略消息8和9，并要求重传消息7到9，或者最好重传消息7到0（0表示序列号无穷大）。后者，作为当序列号出现混乱，双方同时尝试恢复一个间隙时，从当前的某些竞争条件下快速恢复的推荐方法。

1.         为请求一个单一消息， BeginSeqNo=EndSeqNo

2.         为请求一定范围内的消息，BeginSeqNo=请求范围内第一个消息，EndSeqNo=请求范围内最后一个消息。

3.         请求特定消息的所有后续消息：BeginSeqNo=请求范围内第一个消息，EndSeqNo=0。

重传请求消息格式如下：

Resend Request

5.5 Reject（session-level）驳回消息

当一个接收消息由于违背会话层规则，不能被正确的处理，应发送驳回消息。一个例子是：当一个接收消息通过解密，效验和检查，及数据体长度检查后没有有效的基础数据（如，MsgType=&），将产生一个驳回消息。结果是，这些消息将传递给交易应用程序，如果需要，将产生商业逻辑级的驳回。

驳回消息应记录到日志中，且接收序列号应增加。

注意：接收应用程序应忽略任何干扰消息，不能被解析的及未通过数据完整性检查的消息。处理下一个FIX消息将导致检测到一个序列号间隙并产生一个Resend Request消息。FIX引擎应包含处理在此情况下的无限重传循环。

生成和接收到一个驳回消息表明一个接收或发送程序的逻辑错误导致的严重的错误。

如果发送程序选择重传驳回消息，该消息应赋予一个新的序列号值，且PossResend设置为‘Y’。

无论何时，强烈推荐将描述失败原因在Text 域中描述（如，INVALID DATA（35））。

如果接收到的一个应用级消息满足所有会话级规则，该消息应在商业消息级被处理。如果在处理过程中检测到规则冲突，将产生发送一个商业绩驳回。许多商业级消息都有自己特定的驳回消息。如果没有，则产生发送一个Business Message Reject消息。

注意，在收到一个商业消息，满足会话级规则，但不能被传送给商业级处理系统时，一个带有BusinessRjectReason=“Application not available at this time”的Business Message Reject消息将被发出。

会话级驳回消息场景：

驳回消息格式：

Reject

5.6 Sequence Reset（Gap Fill）序列号复位（间隙填充）消息

序列号复位消息有两种模式：Gap Fill模式和Reset模式。

5.6.1Gap Fill 模式

在下列情况下，Gap Fill模式用于响应当出现一个或多个消息必须被跳过时的Resend Request消息

1.         在常规的重传处理过程中，发送应用程序可以选择不发送消息（如，一个过期的指令）。

2.         在常规的重传处理过程中，大量的管理消息将跳过而不重传（如：Heartbeat， TestRequest 消息）。

GapFillFlag（123）域为‘Y’时，为Gap Fill模式。

如果GapFillFlag（123）域设置为‘Y’，MsgSeqNum应同标准消息序列号规则保持一致（如，序列号Reset GapFill模式消息的MsgSeqNum应为GapFIll消息的最开始的MsgSeqNum,因为其值为远端程序希望接收的消息序列号）。

5.6.2Reset Mode 复位模式

复位模式包括了指定一个任意的、数值更大的、接收者期望的Reset-Reset消息序列号，并用于在出现不可恢复的应用程序错误时重新建立一个FIX会话。

复位模式由GapFillFlag为‘N’时，或被忽略时被指定。

如果GapFillFlag没有出现，或其值为‘N’，可以认为Sequence Reset消息的目标是从序列号混乱时的恢复。在序列号的Reset-Reset模式中，在消息头中的MsgSeqNum将被忽略（如，当接受到带有错误的MsgSeqNum序列号的Sequence Reset-Reset模式消息时，不产生重传请求）。序列号复位的Reset消息不应被当作揖个重传请求的常规响应（使用序列号复位的Gap Fill模式）。序列号复位的Reset模式仅在当使用序列号复位的Gap Fill模式无法恢复时进行灾难恢复。注意，使用序列号复位模式时有可能造成消息丢失。

5.6.3Rules for processing all Sequence Reset messages处理所有序列号复位消息的规则

发送程序将启动序列号复位。所有情况下，这个消息指定NewSeqNo以作为消息接收方期望接收的下一个消息的序列号的复位，紧接在消息和/或被挑过的序列号 ？

序列号复位，近能增加序列号。如果一个序列号复位消息尝试减小期望接收消息的序列号时，应被当作揖个严重错误而被拒绝。多个Resend Request重传请求可能在接连着被发起（如，5道10，接着5到11）。如果序列号8，10，11是应用消息而5到7和9是管理消息，那么重传请求的结果为：序列号复位GapFill模式下的NewSeqNo为8，消息8；序列号复位GapFill模式下的NewSeqNo为10，消息10。也可以是序列号复位GapFill模式下的NewSeqNo为8，消息8；序列号复位GapFill模式下的NewSeqNo为10，消息10，和消息11。必须小心地忽略尝试减少期望序列号值的复制的序列号复位GapFill模式消息。可以通过检查MsgSeqNum是否小于期望值来检查。如果是，那么该序列号复位GapFill模式消息为复制消息，应被忽略。

序列号复位消息格式：

Sequence Reset

5.7 Logout注销消息

Logout消息发起或确认一个FIX会话的终止。没有Logout消息交换的连接断开应被视为一个异常情况。

在实际的关闭会话前，Logout发起者应等待对端的Logout确认消息的响应。这样可以给远端在必要时执行一些Gap Fill操作的机会。如果远端在规定的时间间隔后没有响应，会话可以终止。

在发送Logout消息后，注销发起者不应发送任何消息，除非注销的接收者通过ResendRequest消息请求发送消息。

注销消息格式如下：

Logout

5.8 CheckSum Calculation 校验和计算

一个FIX消息校验和通过计算到ChechSum域（但不包括）的消息的每个字节和得到。然后，校验和被转换为模256的数字用于传送和比较。校验和在所有加密操作之后被计算。

为了便于传输，校验和必须以可打印字符形式进行传输，因此，校验和被转换位3个ASCII数字。

比如：如果消息的校验和为274，则模256后为18（256+18 = 274）。这个值将采用|10=018|进行传输，其中“10=”是校验和域的标签。

产生校验和的代码示列如下：

char *GenerateCheckSum( char *buf, long bufLen )

{

static char tmpBuf[ 4 ];

long idx;

unsigned int cks;

for( idx = 0L, cks = 0; idx < bufLen; cks += (unsigned int)buf[ idx++ ] );

sprintf( tmpBuf, “%03d”, (unsigned int)( cks % 256 ) );

return( tmpBuf );

}