金融信息交换协议（FIX）5.0 FIXT1.1（3）

 

4.5 Logon消息的NextExpectedMsgSeqNum处理

NextExpectedMsgSeqNum (789)域从FIX4.4开始加入到Logon消息中，用以支持一个FIX会话的重同步。这个新方法是可选的。其适用必须得到参与方的共同同意。

NextExpectedMsgSeqNum (789)的使用如下：

在Logout的请求阶段，会话发起者把期望从会话接收者的下一个MsgSeqNum（34）的值赋于NextExpectedMsgSeqNum (789)。通常，Logon请求发送头部MsgSeqNum（34）的值表示下一个序列号值。

会话接收者校验Logout请求，包括NextExpectedMsgSeqNum (789)，确认没有间隙存在。然后，构建一个Logout响应，其NextExpectedMsgSeqNum (789)值包含了期望从会话发起者接收到的MsgSeqNum（34）值。如果那是一个期望的序列号，MsgSeqNum（34）会被递加。发送头部MsgSeqNum（34）按照常规进行构造。

会话发起者等待发送应用消息直到接收到Logon响应。当接收到Logon响应，发起者要校验该响应和NextExpectedMsgSeqNum (789)以确认没有消息间隙。

会话双方采用以下方式对收到的NextExpectedMsgSeqNum (789)进行处理：

1、如果等于下一个期望序列号值，则从该编号开始发送新消息。

2、如果小于下一个期望序列号值，从之前最后传送的消息到NextExpectedMsgSeqNum (789)按顺序恢复所有丢失消息，然后间隙填充将跨过Logon使用的序列号，使用比原Logon大1的序列号继续发送新的排队消息。

3、如果大于下一个期望序列号值，发送Logout终止会话。

除了希望自动进行那个间隙填充外，任何一方应给予接收的Logon消息的MsgSeqNum（34）产生一个ResendRequest。如果间隙由Logon消息的MsgSeqNum（34）导致，接收逻辑应希望自动填充间隙以恢复间隙的任何消息序列。

4.6 Standard Message Header标准消息头

任何管理和应用消息都紧跟在一个标准头部之后。头部标示了消息的类型、长度、目标、序列号，来源及创建时间。

两个域用于协助重发消息。PossDupFlag为‘Y’表明一个会话级事件导致的消息重传（如，使用同一个序列号重传一个消息）。PossResend为‘Y’表明使用新的序列号重新发出一个消息（如，重新发送一个Order指令）。接收程序应按下述方法进行处理：

PossDupFlag 如果一个消息的序列号表明之前已经收到，忽略该消息；如果没有，进行正常处理。

PossResend 将消息传递给应用程序以判断是否之前已经收到（如，验证Order的ID号和参数）。

Message Routing Details – One Firm-to-One Firm (point-to-point)

Message Routing Details – One Firm-to-One Firm（Point-to-point）消息路由-点对点

下表展示了使用SenderCompID，TargetCompID，DeliverToCompID，和OnBehalfOfCompID在两个企业间的一个单一的FIX会话。假设A为卖方，B为买方

 

SenderCompID

OnBehalfOfCompID

TartgetCompID

DelivrToCompID

A 到B

A

 

B

 

B 到 A

B

 

A

 

Message Routing Details-Third Party Message Routing消息路由-第三方消息路由

FIX会话协议具备支持一个FIX会话包含多个参与这者的能力。包括1对多，对对1，或者1对1的形式。此外，一些第三方可以与其它第三方连接，在消息发起者和最终的接收者间形成一个多跳的链。SenderCompID，TargetCompID，DeliverToCompID，和OnBehalfOfCompID域用于路由消息。

当一个第三方在另一个企业中间发送一个消息时（使用OnBehalfOfCompID），可以选择在NoHops重复组中加入它的细节信息。这个重复组构建了消息在第三方重新发送的的一个历史列表。NoHops重复组不用于协助路由，而是为接收消息方对参与的第三方进行审计时提供痕迹。当一个第三方转发一个消息给下一跳（可能是最终接收者，或另一个第三方）时，此第三方可以将其跳信息加到NoHops重复组中（如，将其SenderCompID作为HopCompID，其SendingTime作为HopSendingTime，将接收消息的MsgSeqNum或其他引用数据作为HopRefID ）。

注意：如果OnBeHalfOfCompID或DeliverToCompID消息源识别/路由方法在一个FIX会话中使用，那么该方法必须在通过此会话传送的所有消息中使用。

下表提供了在单一FIX会话中表名多个企业参与时SenderCompID，TargetCompID，DeliverToCompID和OnBehalfOfCompID的使用方法。假设A=卖方，B和C表示买方，Q=第三方。

 

SenderCompID

OnBehalfOf

CompID

TargetCompID

DeliverTo

CompID

DeliverTo

CompID

HopSendingTime

从A通过Q到B

1 A到Q

A

 

Q

B

 

 

2 Q到B

Q

A

B

 

Q

A的发送时间

B通过Q响应A

1 B到Q

B

 

Q

A

 

 

2 Q到A

Q

B

A

 

Q

B的发送时间

A通过Q发送到B和C

1A到Q

A

 

Q

B

 

 

2Q到B

Q

A

B

 

Q

A的发送时间

3A到Q

A

 

Q

C

 

 

4Q到C

Q

A

C

 

Q

A的发送时间

B和C通过Q发送到A

1B到Q

B

 

Q

A

 

 

2Q到A

Q

B

A

 

Q

B的发送时间

3C到Q

C

 

Q

A

 

 

4Q到A

Q

C

A

 

Q

C的发送时间

 

注意，由于在一个给定的FIX会话中，一些域（如在一个新Order指令中的ClOrdID）必须是唯一的。因此，当使用OnBehalfOfCompI（或DeliverToCompID）进行寻址时，推荐的做法是在OnBehalfOfCompI（或DeliverToCompID）之后加上源地址。这样，如果A发送消息到Q的ClOrdID为“123”，那么Q将“A-123”作为ClOrdID的值发送到C，以确保唯一性。

 

标准消息头部如下

Standerd Message Header

Tag

（标记）

FieldName

（域名）

Req’d

（必选）

备注

8

BeginString

Y

FIXT.1.1(不能加密，必须是消息的第一个域)

9

BodyLength

Y

(不能加密，必须是消息的第二个域)

35

MsgType

Y

(不能加密，必须是消息的第三个域)

1128

ApplVerID

N

使用SP标示方法标明应用版本。ApplVerID用于一个特定消息的场景

1129

CstmApplVerID

N

用于支持客户共同协商认可的功能

49

SenderCompID

Y

（不能被加密）

56

TargetCompID

Y

（不能被加密）

115

OnBehalfOfCompID

N

通过第三方发送消息时交易参与者企业ID（可以内置于坚密数据部分）

128

DeliverToCompID

N

通过第三方发送消息时交易参与者企业ID（可以内置于坚密数据部分）

90

SecureDataLen

N

用于标示消息加密部分的长度时必选（不能加密）

91

SecureData

N

消息体加密时必选。总紧跟在SercureDataLen域之后

34

MsgSeqNum

Y

（可以内置于坚密数据部分）

50

SenderSubID

N

（可以内置于坚密数据部分）

142

SenderLocationID

N

发送者的LocationID（如，地理位置和或席位（desk））（可以内置于坚密数据部分）

57

TargetSubID

N

为管理消息保留，不针对一个特定用户。（可以内置于坚密数据部分）

143

TargetLocationID

N

交易参与者LocationID（如，地理位置和或席位（desk））（可以内置于坚密数据部分）

116

OnBehalfOfSubID

N

交易参与者SubID，用于通过第三方传送消息。（可以内置于坚密数据部分）

144

OnBehalfOfLocation

N

交易参与者的LocationID（如，地理位置和或席位（desk））（可以内置于坚密数据部分）

129

DeliverToSubID

N

交易参与者SubID，用于通过第三方传送消息。（可以内置于坚密数据部分）

145

DeliverToLocationID

N

交易参与者的LocationID（如，地理位置和或席位（desk））（可以内置于坚密数据部分）

43

PossDupFlag

N

当重传消息时总是必选，无论是由发送方系统提示，还是作为重传请求的响应结果。（可以内置于坚密数据部分）

97

PossResend

N

当消息可能是另一个消息的复制消息且使用一个不同的序列号时必选。（可以内置于坚密数据部分）

52

SendingTime

Y

（可以内置于坚密数据部分）

122

OrigSendingTime

N

当作为一个ResendRequest的返回结果重传消息时必选。如果数据不可用，则与SendingTime值相同（可以内置于坚密数据部分）

212

XmlDataLen

N

当标示XmlData消息体长度时必选。（可以内置于坚密数据部分）

213

XmlData

N

包含XML格式的消息块（如FIXML）。总紧跟在XmlDataLen后。（可以内置于坚密数据部分）

347

MessageEncoding

N

在消息的“Encode”域中使用的消息编码格式（非ASCII编码）。使用编码域时必选。

369

LastMsgSeqNumProcessed

N

FIX引擎到收到、下游应用（如交易系统、指令路由系统）处理过的的最后一个MsgSeqNum值。在每个消息发送时确定。用于参与方侦测消息积压（未被处理？）。

627

NoHops

N

 

-〉

628

HopCompID

N

 

 

629

HopSendingTime

N

 

-〉

630

HopRefID

N

 

4.7 Standard Message trailer标准消息尾部

每个消息，管理或应用消息，以一个标准尾部结束。该尾部用于分割消息并包含描述Checksum值的3个数字字符。

Standard Message Trailer

Tag

（标记）

FieldName

（域名）

Req’d

（必选）

备注

93

SignatureLength

N

如果尾部包含签名则必选。注意，不能包含在SecureData域中。

89

 

Signature

N

注意，不能包含在SecureData域中。

10

CheckSum

Y

（不能加密，总是消息的最后一个域）