免费医院网页模板,seo网站优化培,wordpress 报错,如何做酒网站理由FIX协议由一个会话层协议#xff0c;一个应用层协议和一套域数据字典组成。后两者不依赖于FIX会话。而且#xff0c;由于FIX会话作为Point-to-point#xff08;点-对-点#xff09;通信#xff0c;并不适合于发布/订阅模式#xff08;如为大量接收者提供市场数据一个应用层协议和一套域数据字典组成。后两者不依赖于FIX会话。而且由于FIX会话作为Point-to-point点-对-点通信并不适合于发布/订阅模式如为大量接收者提供市场数据。本应用注释文档定义了FIX消息怎样通过多播传输技术如IP多播进行发布。此注释并不描述具体的多播技术而是讨论如何修改FIX回沪协议以使用该技术进行通信。 会话层概述 为保证在一个多播环境中正确检测消息间隙除了在下面提到的一个特定的主题应只有一个发布者。在本文中“主题”指的是接收者如何侦听及侦听的对象以及发布者如何通过它发送信息如主题明TCP侦听端口等等。多播技术及其实现的特征如发布者使用一个主题接收从多个接收者发来的重传请求将控制是否由一个特定的发布者发送的消息能按照顺序进行传送。一个特定的主题可以有任意数量的订阅者或接收者。 为了检测在会话中存在的消息间隙在每个消息中的序列号应基于每一个主题进行赋值。如果不这样做接收者没有订阅所有主题将无法检测到消息实际存在的消息间隙。这样接收者必须为每个主题维护一个期望的序列号。 与标准的FIX会话层协议不同FIX4.0或更高版本所有的管理消息将不占用序列号同FIX3.0一样。在多播环境下的数据传输类型是单向的从发布者到接收者这样将不会出现在双向FIX3.0会话中可能存在的竞争。这样FIX4.0及后续版本中对管理信息占用一个序列号的需求可以忽略。在这样的情况下管理消息应包含下一个发送消息的MsgSeqNum而不是占用活增加MsgSeqNum的值。任何发送的会话层消息应增加下一个发送序列号使得接收者可以检测消息间隙并至此执行消息间隙处理。 在所有消息中的TargetCompID应设置成一些预先定义好的值由发布者赋值如消息发送所基于的主题名。在所有消息中的SenderCompID应设者为预先定义的由发布者赋值的用于识别发布者身份的值。 Logon 登陆消息 同通常的双向FIX会话登陆不同在发布/订阅或多播环境下的登陆应采用从发布者到订阅者的单向方式。用于通知订阅者发布者会话已经开始。 Heartbeats 心跳消息 Heartbeat消息作为在应用消息交互期间保持链路活动测试包使用。Heartbeat消息应只能由发布者发送。 Resend Request 如果接收者在发布者发送的消息中检测到一个序列号间隙它可以通过另一个定义好的Resend Request主题发送一个Resend Request消息。当发布者接收到一个Resend Request消息可选择立即响应、定时响应或根本不响应该请求。由于Reject消息不在多播环境中使用发布者应忽略无效的Resend Request如序列号过大火重复消息。如果在响应一个Resend Request时发布者希望跳过一个或多个消息它应发送一个Sequence Reset/Gap Fill消息用于提示这个间隙应自动填充。由于发布者可能不立即响应接收应用程序应细细考虑是否为了顺序传递应延迟处理后续消息。 如果要发布多个应用主题应为每个应用主题定义一个单独的Resend Request主题。为了使应用主题发布者识别请求的主题Resend Request消息应通过TargetSubID域明确所期望的应用主题。此外也可以建立一个单独的主题让接收者在主要的主题外侦听Resend Request响应。 一些多播技术如IP多播不允许发布者响应一个特定订阅者的重传请求也不提供通过主要的主题分发通道对所有订阅者进行同样的响应。订阅者必须具备忽略比期望序列号小的消息的能力。 Rejects驳回消息 在此模式下会话层驳回消息将不再使用。 Logout注销消息 同通常的双向FIX会话注销不同在多播环境下的注销应采用从发布者到订阅者的单向方式。用于通知订阅者发布者会话已经结束。 Additional Implementation Details 额外的实现细节 与实际商业的多播环境下的更多的实现细节应由参与方制定相关文档并达成共识。多播传输技术通常被认为在分发大批量相同数据到大量接收者的一种非常有效的方式。在提供重要交易数据服务的金融组织中该技术被广泛使用。IP多播网络提供一个支持将IP数据包转发给一组在多个位置的接收者的机制。IP单播网络支持将IP数据报发送给一个特定位置的单个接收者而IP广播则支持将IP数据包发送给一个特定位置的所有接收者。IP多播网络优势的本质在于一个单一的IP数据包可以由一个服务产生然后被转发给一组感兴趣的接收者。这种方式即优化了应用又优化了网络资源。由于应用服务器只需对所有的接收者产生一个单一的数据包服务器容量及执行效率不再受到接收者数量增长的影响这将影响CPU内存网络连接等资源并且应用服务器不再需要考虑维护会话的开销。同样由于只有一个单一的数据包需要通过给定的路径转发那么这些应用数据流发送的网络带宽将会减少。在结构上实际的标准网络协议模式是一个稀疏模型模式数据通过网络到感兴趣的接收者所捆绑的网络设备间进行多播。与推送模式相关的稠密模型模式已经逐渐被淘汰。作为优化交易数据各方面工作的一部分FIX正致力于将其规范扩展到多播传输技术和交易数据传输的应用领域。在研究多播数据传输的行业机构的协助下提出了后面的推荐方案。Multicast Configuration 多播配置IP多播在传输层使用UDP协议应用数据被封装在一个个IP|UDP数据桢中。当一个服务器能够很容易地发送淹没网络贷款的突发数据的时候突发控制就至关重要。所有的多播源应当具备某种使其网络带宽能够受控使用的调步由接收站来控制发送站的传输速率以避免超速或堵塞的一种技术机制。由传输设备将需要发送的数据进行逻辑分节是行业的通常做法。然后这些数据通过一个公认的UDP端口号和一个多播组地址进行传输。这就具备了创建分离的数据通道或链路的效果。数据通道和数据链路的创建引入一种分级的服务间隔粒度能够用于创建产品集以及允许共享处理消耗。然而太多的间隔粒度将引入网络和其他处理的消耗例如将会导致大量的多播组的存在。所以在对数据进行分节的时候注意将多播组的数量保持在一个适当的最小数量。在多播分划中的一个关键问题是组搅动。任何允许客户订阅/退订分隔粒度太好的组消息的模式反而起不了好作用如一个股票代码一个组。分组大小和网络带宽占间得有个取舍。太多分组占用太多带宽而分组太少没有达到分划的效果。因此通常的实践是采取一种引入适当分隔粒度进行内容的逻辑分组采取允许数据能够通过相对平均地跨越传输通道进行共享数据的方式进行分组。典型的包含信息内容如证券、期权和数据量如一组“A到D”的工具集。为了给应用服务提供商网络服务提供商及订阅者的集成提供便利使用全球唯一的IP源和目标地址是做好的做法。对单播IP源地址而言将会是一个在IANA组织登记的IP地址或对应用或网络服务提供商登记的适当IP地址。对多播目标多播分组地址而言应用服务提供商应仅使用由IANA或遵循RFC3180的地址。优化网络和服务资源通过将多个消息打包围当个的数据包以最小化开销被认为是目前最好的习惯实践。这就要求应用程序在某个最小的有效时钟周期期满内传送一个数据包在时钟周期结束前数据被完整打包。被传送的数据包应在一个绝对的范围内能被唯一识别并且这些包应不被它们彼此的关系参照这也被认为是当前做好的做法。这就使对方问一个特定考虑应用程序生成的数据包大小。正如上面提到的推荐在每个包中承载多个消息以优化处理和转发。然而一般而言推荐包的大小不要超过MTU大小小于1400字节。这也是网络封装发生时必须的。Live/Live ConfigurationIP数据包在特定的环境下在传输过程中可能会发生顺序混乱、重复或丢失。类似IPUDP是面向无连接的协议它不提供类似于TCP协议那样的确保不丢包或不发生数据包顺序混乱的机制。由此应用程序应负责管理数据乱序重复数据包和数据包丢失。加入多播组的应用程序接收到多播数据包时应能处理重复的和乱序的数据包。应用服务提供商应用各种机制为多播应用提供重传服务。此外应用服务提供商采用常见方法/机制减少订阅者没能接收到数据包的风险。该方法就是复制每个数据包然后通过另外的通道多播组|UDP端口进行传输。这些通道能通过单独的物理网络架构进行传送以扩展多样性和减少丢包的风险。其目的是期望数据的订阅者或接收者应对两个通道进行侦听并负责在两者之间进行判断以构建一个单一的集合。Channel Grouping and Definition 通道分组和定义应该尽量注意将通道数保持在一个适当的最小数量。作为实际的例子对于一个总数为20个通道Live/Live配置的情况下大约需要10个主要的通道。对通道数的限制的一个原因是可能会导致全球唯一多播ID的缺少多播仅拥有一个有限的IP地址范围。许多因素在确定通道数时需要去考虑。比如传输数据量的大小是一个决定因素我们不能期望10个通道仅有1Kbi/s的数据传输率。通讯通道ID当前好的实践是将分组、端口等的定义进行分离从实际的转发机制中构建一个通道。因此不鼓励在消息数据内容部分包含IP地址信息包括多播组地址。将这些地址从消息数据内容中分离出来也提供了在IP或UDP地址使用方面的伸缩性。为支持该方法一个推荐的方法应被用于产品定义和属性的传输例如其产品符号在多播组地址中可用。Multicast Session Layer 多播会话层这个部分讨论当通过多播技术传送市场数据时使用的会话层控制。通常在使用一个多播范列中推荐使用一个轻量级FIX会话层。然而这里仍然有几个会话层控制对于管理一个多播会话是有用的。Entitlement授权 如果通道用户直接连接到供应商的分发网络其授权可以由供应商在网络边界的PIM过滤或IGMP控制机制来控制。该授权行为可以替代一个登陆验证。但该方法不能用于用户没有直接连接到供应商控制的网络比如Intenet。为了对模板交换以及在发送者到接收者间使用消息类型进行的通信产生影响一个单独的会话层登陆是必要的。简而言之一个显示的由接收者发起的注册一个通道或一组通道的登陆不是必须的。Sequnce Gap Handling 序列号间隙处理由于几个原因在多播场景里与常规的FIX序列号间隙处理相比间隙处理将有不同。首先对于潜在的序列号丢失Live/Live配置要求质询双方的反馈。序列号间隙处理仍然能被执行但其算法必须诊断是否消息序列号是否存在于每一个反馈中。其次由于可靠性的问题不推荐通过多播会话创建重传请求。在每一个反馈中如果序列号不可用那么对丢失数据的重传带外请求可以使用一个重传请求消息创建。推荐使用一个单独的、使用TCIP-IP协议的的会话连接用于提供重传请求的可靠传送。通过重传请求消息发起的重传请求必须指定所请求消息传输的原始主通道。单独的开始和结束序列号是不够的应为不能保证在所有通道中的唯一性。注意既然通道的ID是一个主体那么要改变它们应当在Resend Request消息中创建一个可配置的参数。Heartbeat心跳心跳信号用于接收者判断连接的是否仍然活跃。心跳消息必须在每个通道中传送并携带消息序列号MsgSeqNum/Tag为34。每个通道将有其自己的一套序列号并且在通道中保持唯一而不是在所有通道中保持唯一。MsgSeqNum能用于接收者验证feed的完整性。如果心跳消息中的MsgSeqNum等于接收者期望接收的下一个序列号那么feed是完整的。否则表明feed已经被破坏此时需要创传或重新连接。Time Beacon 时间信号灯时间信号灯消息同HeartBeat心跳信号的有大致形同的作用用于通告一个通道的活动性。然而时间信号灯并不携带下一个希望接收的序列号。Retransmission of Data由于UDP是不可靠的无连接的数据报传输机制因此应用层应负责处理数据包的重复接收乱序和丢失。注意就包转发而言TCP和UDP都会因此受到影响。因此即便是在LIVE|LIVE这样的多播传递机制里多数分发关键数据的应用也支持重传机制。现在有多种不同特征的重传机制正在进行使用。事实上所有这些机制都使用一种“带外”请求机制。带外请求机制被认为是最好并推荐的机制用于使用TCP/IP单播请求模式。基于带内多播的请求则不提倡。在这种模式下接收者主机设备将同合适的应用服务提供设备可以是也可以不是发布多播数据流设备建立TCP会话并请求一个或一定范围的数据包的重发。被请求重发的数据包可以通过多种途径进行传输1使用主要的|多播创建组进行重发2数据包由TCP/IP单播会话返回3数据包由单独的当做重传组进行传输。推荐使用第3种可选方案在此一个或多个分离通道独立于主要的数据生产转发机制被采用这样仍然可以保持多播的高效率。多数情况下当这种模式被采用时也存在多个多播重传组。如果存在多个组那么当前最好的实践是将每一个重传组同数据内容关联起来。Retransmission Channels推荐运用IP多播来实现重传机制的数据包重传。而且推荐重传的数据包不应在原始数据包传输的通道上进行传输。因此尽力一组重传组使得期望或需要接收重传数据的参与这可以加入到其中接收数据。然而一般而言期望应用重传机制的参与者通常能加入其特别需要专注的重传组。重传应总是通过单独的专门的目的通道进行。一般而言这里应该有一个单独得通道发布所有的重传数据。在一些通道连接状态下一个边界路由将静态的脚如通道一位着该通道将总是注意活动状态并且订阅数据源。这个配置具有简单的特性在这种情况下所有的重传数据经总是通过一个单独得通道接收。这种方式的一个小的却缺陷是没有优化使用带宽。重传通道将加载被所有交易参与这请求的数据不仅仅是接收者侦听的数据。一个可能的替代方案是在需要重传时连接通道不需要是则断开。另一个可能的替代方案是建立多个重传通道也许是一个主通道就有一个重传通道。这个方法的优点在于接收者可以知道那个数据生成组通过给定的重传通道被接收。缺点则是对保持一个合理的最小数量通道与多播基础设施的增长存在冲突。因此这个方案不值得推荐。Application-Level Requests for Retransmission应用级重传请求经通过Market Data Request消息进行支持。建议重传请求通过一个可靠的请求传递的TCP/IP连接来实现。由请求响应得接收者负责消息接收的确认。为扩展请求的执行有效性Market Data Request Reject消息能由请求响应者发起并携带“不能处理”和指明拒绝的理由的响应。一个重传请求一般由以下几个情况下被创建l 在指定了开始和结束时间标签的一个时间范围l 通道IDl 责任l Book的当前状态注意Market Data Request应不请求消息序列号的重传它在会话层自动被执行。Multicast Entitlement 使用IP多播技术支持数据发布的常用架构模式是一种单向模式在此模式下应用服务提供者发布数据订阅者则在网络层订阅其需要的数据。因此通常当前存在非点-对-点双向的应用层通讯以支持登录序列交换能够用于验证订阅者是具备接受发布数据的权限。多播不是最好的任意定制接收技术。因此一个受信网络提供者可能是应用服务提供者或单独的网络服务提供者应负责在网络层提供一种认证模式。在非受信的网络中必须使用数据加密。然而数据加密通常不在多播交易数据传输中使用。通常除非数据在非受信网络比如Internet上进行数据传输时数据加密通常是没有必要的。由私密专用链路或私密外联网提供的安全性将产生额外的由不易察觉的数据加密引入的延迟。认证模式最主要的目标应该是提供1、多播发布数据的安全传输也同时保证发送者是经认证的2、数据只分发给受信的接收者。多播认证为发送者提供了一个数据安全层。只有核准的数据接收者可以加入到一个通道中。它不为发送者提供保护其内部资源的安全但它协助确保只有核准的接收者获得通道数据。静态配置Static Configuration决定谁能够加入到一个通道中。接收者必须在发送者的路由里进行设置使其能加入到一个多播通道中。PIM Filters PIM过滤器用于在路由器上提供认证。不必进行LDAP查询或其它验证。IP多播的特性在于消除了那些在单播传输中的机制用于认证请求者并且这里不存在业界普遍认可的替代方式。因此最常采用的方式是运用网络层在边界设备中实现确保数据仅分发给核准的接收者。Message Header 消息头部这个部分讨论FIX消息头部及其在多播环境中的应用。FIX头部作为应用消息的一部分进行传输与多播头部不冲突多播头部指定了其他的一些数据如发送者的IP地址。由于多播是广播与单播传输不同消息能够使用FIX头部的部分域来创建就足够。在多播环境中最少应包含BeginStringMsgTypeMsgSequNum和BodyLength域。 当前的FIX规范要求提供SenderCompID和TargetCompID。然而这些域在多播环境会话中将失去作用只是在点—对—点会话中有用。当消息被作为一个Resend Request消息的响应被传送时被重传的消息可以选择携带PosDupFlag域该域在标准的FIX会话中被使用。
