金融信息交换协议(FIX)5.0 FIXT1.1(4)

原创 2007年09月28日 16:25:00
 
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
Tag
(标记)
FieldName
(域名)
Req’d
(必选)
备注
 
StandardHeader标准头部
Y
MsgType=0
112
TestReqID
N
当Heartbeat消息是Test Request消息的响应时必选
 
StandartTrailer
Y
 
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
Tag
(标记)
FieldName
(域名)
Req’d
(必选)
备注
 
StandardHeader标准头部
Y
MsgType=A
98
EncryptMethod
Y
不能加密
108
HearBtInt
Y
双方使用同一个值
95
RawDataLength
N
由一些认证方法使用
96
RawData
N
由一些认证方法使用
141
ResetSeqNumFlag
N
表示FIX会话双方应复位序列号
789
NextExpectedMsgSeqNum
N
可选,双方检测和恢复消息间隙的候选协商方法参照“Logon消息NextExpectedMsgSeqNum
383
MaxMessageSize
N
能用于指定所支持接收消息的最大字节数
384
NoMsgTypes
N
指定RefMsgTypes的重复次数
-
372 RefMsgType
N
制定一个特定的、被支持的MsgType。如果NoMsgTypes大于0时必选。从Logon消息的发送者角度应当被指定。
-
385 MsgDirection
N
表明所支持MsgType的接收或发送方向。当NoMsgTypes大于0时必选。从Logon消息的发送者角度应当被指定。
-
1130 RefApplVerID
N
在会话层指定一个消息的应用SP发行版本。SP发行时付值的枚举域。
-
1131 RefCstmApplVerID
N
再会话层指定一个用户扩展消息的应用。
464
TestMessageIndicator
N
用于指定此FIX会话将发送、接收 “Test” “production”消息。
553
Username
N
 
554
Password
N
注意,没有传输层加密时存在最小安全性。
1137
DefaultApplVerID
Y
由FIXT承载的FIX的默认版本。
 
StandartTrailer
Y
 
5.3 Test Request 测试请求消息
测试请求消息强制对方发送一个Heartbeat消息。测试请求消息检查序列号或验证通信线路状态。对端应用程序响应一个包含TestReqID的Heartbeat消息。
TestReqID用于检查对端应用是依据测试请求消息产生的Heartbeat消息,而不是通常的超时。对端应用程序将TestReqID包含在响应Heartbeat消息中。任何字符串可以被用于TestReqID(一个建议是使用时间戳字符串)。
测试请求消息格式如下:
Test Request
Tag
(标记)
FieldName
(域名)
Req’d
(必选)
备注
 
StandardHeader标准头部
Y
MsgType=A
112
TestReqID
Y
不能加密
 
StandartTrailer
Y
 
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
Tag
(标记)
FieldName
(域名)
Req’d
(必选)
备注
 
StandardHeader标准头部
Y
MsgType=2
7
BeginSeqNo
Y
不能加密
16
EndSeqNo
Y
 
 
StandartTrailer
Y
 
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消息将被发出。
 
会话级驳回消息场景:
SessionRejectReason
0=Invalid tag number    无效的tag编号
1=Required tag missing  tag丢失
2=Tag not defined for this message type 这类消息的Tag没有被定义
3=Undefined Tag       未知Tag
4=Tag specified without a value 缺少Tag值
5=Value is incorrect (out of range) for this tag tag值错误(超界)
6=Incorrect data format for value   错误值数据
7=Decryption problem            解密错误
8=Signature problem             签名错误
9=CompID problem              企业ID错
10=SendingTime accuracy problem 发送时间不正确
11=Invalid MsgType             无效的MsgType
12=XML Validation error         XML语法验证错误
13=Tag appears more than once    Tag重复出现
14=Tag specificed out of required order 指定的Tag顺序错误
15=Repeating group fields out of order 重复组域顺序错误
16=Incorrect NumInGroup count for repeating group 重复组NumInGroup错误
17=Non “data” value includes field delimiter(SOH character) 包含了SOH分界符的错误数据
99=Other 其它错误
注意:其他的会话级规则冲突可能存在,SessionRejectReason值为99(Other),并在Text域中进行详细描述。
驳回消息格式:
Reject
Tag
(标记)
FieldName
(域名)
Req’d
(必选)
备注
 
StandardHeader标准头部
Y
MsgType=3
45
RefSeqNum
Y
被驳回消息的MsgSeqNum
371
RefTagID
N
被参照的FIX域tag值
372
RefMsgType
N
被参照的FIX消息MsgType值
373
SessionRejectReason
N
会话级驳回消息错误代码
58
Text
N
解释驳回原因的文本信息
354
EncodedTextLen
N
如果使用EncodeText域,必选,且EncodeText必须紧跟在该域之后
355
EncodedText
N
使用MessageEncoding
域制定的编码规则对Text域内容的编码数据(非ASCII码)
 
StandartTrailer
Y
 
  
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
Tag
(标记)
FieldName
(域名)
Req’d
(必选)
备注
 
StandardHeader标准头部
Y
MsgType=4
123
GapFillFlag
N
 
36
NewSeqNo
Y
 
 
StandartTrailer
Y
 
5.7 Logout注销消息
Logout消息发起或确认一个FIX会话的终止。没有Logout消息交换的连接断开应被视为一个异常情况。
在实际的关闭会话前,Logout发起者应等待对端的Logout确认消息的响应。这样可以给远端在必要时执行一些Gap Fill操作的机会。如果远端在规定的时间间隔后没有响应,会话可以终止。
在发送Logout消息后,注销发起者不应发送任何消息,除非注销的接收者通过ResendRequest消息请求发送消息。
注销消息格式如下:
Logout
Tag
(标记)
FieldName
(域名)
Req’d
(必选)
备注
 
StandardHeader标准头部
Y
MsgType=5
58
Text
N
 
354
EncodedTextLen
N
如果使用EncodeText域,必选,且EncodeText必须紧跟在该域之后
355
EncodedText
N
使用MessageEncoding
域制定的编码规则对Text域内容的编码数据(非ASCII码)
 
StandartTrailer
Y
 
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 );
}
版权声明:本文为博主原创文章,未经博主允许不得转载。

相关文章推荐

金融信息交换协议(FIX)5.0 FIXT1.1(4)

金融信息交换协议(FIX)5.0 FIXT1.1

金融信息交换协议(FIX)5.0 FIXT1.1(1)

下一篇金融信息交换协议(FIX)

金融信息交换协议(FIX)5.0 FIXT1.1(6)

金融信息交换协议(FIX)5.0 FIXT1.1

金融信息交换协议(FIX)5.0 FIXT1.1(2)

下一篇金融信息交换协议(FIX)5.0 FIXT1.1

金融信息交换协议(FIX)5.0 FIXT1.1(7)

金融信息交换协议(FIX)5.0 FIXT1.1

金融信息交换协议(FIX)5.0 FIXT1.1(5)

金融信息交换协议(FIX)5.0 FIXT1.1

金融信息交换协议(FIX)v5.0读书笔记(2)

金融信息交换协议(FIX)

金融信息交换协议(FIX)v5.0读书笔记(1)

金融信息交换协议(FIX)

金融信息交换协议(FIX)v5.0

1.   什么是FIX        Financial Information eXchange(FIX)金融信息交换协议的制定是由多个致力于提升其相互间交易流程效率的金融机构和经纪商于1992年共...

【FIX协议】金融信息交换协议 - 0 - 简介

什么是FIX
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:深度学习:神经网络中的前向传播和反向传播算法推导
举报原因:
原因补充:

(最多只允许输入30个字)