CN101133380A - 基于硬件的消息传递设备 - Google Patents
基于硬件的消息传递设备 Download PDFInfo
- Publication number
- CN101133380A CN101133380A CNA2005800461011A CN200580046101A CN101133380A CN 101133380 A CN101133380 A CN 101133380A CN A2005800461011 A CNA2005800461011 A CN A2005800461011A CN 200580046101 A CN200580046101 A CN 200580046101A CN 101133380 A CN101133380 A CN 101133380A
- Authority
- CN
- China
- Prior art keywords
- message
- transmission device
- message transmission
- hardware based
- module
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
- Computer And Data Communications (AREA)
Abstract
消息发布/订购***被要求处理大量消息,同时减少等待时间和性能瓶颈。本发明提出的基于硬件的消息传递设备被设计用于大量、低等待时间的消息传递(图1)。该基于硬件的消息传递设备是发布/订购中间件***的一部分。利用该基于硬件的消息传递设备,该***操作用于减少利用基于邻居的路由选择的中间跳,引入有效的本地到外部以及外部到本地协议转换、实时监控包括等待时间在内的***性能、采用基于话题的和基于信道的消息通信,以及动态优化***互连配置和消息传输协议等。
Description
对在先提交的申请的引用
本申请要求以下申请的优先权,并且这些申请通过引用结合于此:2005年1月6日提交的题为“Event Router Systems and Method”的美国临时申请No.60/641,988;以及2005年6月8日提交的题为“Hybrid FeedHandlers And Latency Measurement”的美国临时申请No.60/688,983。
本申请涉及以下申请,并且该申请通过引用结合于此:2005年12月23日提交的题为“End-To-End Publish/Subscribe Middleware Architecture”的美国专利申请No._________(律师卷号No.50003-00004)。
技术领域
本发明涉及数据消息传递中间件体系结构,更具体地说,涉及具有发布和订购(下文称作“发布/订购”)中间件体系结构的消息传递***中的基于硬件的消息传递设备。
背景技术
数据消息传递基础设施所要求的日益提高的性能水平强迫联网基础设施和协议的发展。基本上,数据分发涉及各种数据源和目的地,以及各种类型的互连体系结构和数据源和目的地之间的通信模式。现有数据消息传递体系结构的示例包括轮轴轮辐式(hub-and-spoke),对等式和存储转发式。
利用轮轴轮辐***配置,所有通信都通过轮轴传输,这在处理量大时通常会导致性能瓶颈。因此,这种消息传递***产生了等待时间。绕过这种瓶颈的一种方法是布署更多的服务器,并且在这些不同的服务器之间分布网络负载。但是,这种体系结构表现出可扩展性和操作问题。与具有轮轴轮辐配置的***相比,具有对等配置的***对应用产生了不必要的压力以处理和过滤数据,并且仅与其最慢的客户或节点一样快。而具有存储转发***配置的***为了提供持久性,要在将数据转发到路径中的下一个节点之前存储该数据。存储操作通常通过索引和将消息写到存储盘来实现,这可能产生性能瓶颈。此外,在消息量增大了时,索引和写入任务可能相当慢,因此可能引入额外的等待时间。
现有数据消息传递体系结构共有一些不足。一个共同的不足是在现有体系结构中数据消息传递依赖于驻留在应用层上的软件。这意味着消息传递基础设施要经历OS(操作***)排队和网络I/O(输入/输出),这可能产生性能瓶颈。此外,传统***中路由选择是以软件方式实现的。另一个共同的不足是现有体系结构静态地而不是动态地使用数据传输协议,即使在某些情形下其他协议可能更合适也是如此。常见协议的一些示例包括可路由多播、广播或单播。实际上,现有体系结构中的应用编程接口(API)未被设计为实时地在传输协议之间切换。
另外,网络配置判决通常是在布署时进行的,并且通常被定义为在特定假设下对一组网络和消息传递条件进行优化。与静态(固定的)配置相关联的限制排除了实时动态网络重配置。换言之,现有体系结构是针对特定传输协议配置的,而该传输协议并不总是适合所有网络数据传输负载条件,因此,现有体系结构总是不能实时地应对改变或增大的负载能力需求。
此外,在数据消息传递去往特定的接收者或者接收者群组时,现有消息传递体系结构使用可路由多播来将数据传输过网络。但是,在针对多播建立的***中,存在对可以用来分发数据的多播群组的数目的限制,结果,消息传递***不再将数据发送向未被向其订购的目的地(即,不是该特定数据的订户的客户)。由于数据过滤,这增大了客户的数据处理负载和丢弃率。因此,由于任何原因变为过载并且不能跟上数据流的客户最终丢弃进入数据,并且稍后要求重传。重传对整个***造成影响,因为所有客户都接收重复的传输,并且所有客户都对进入数据进行重新处理。因此,重传可能导致多播风暴,并且最终可能使整个***瘫痪。
在***是针对单播消息传递建立来作为减少丢弃率的一种方法时,该消息传递***可能因为数据复制而经历带宽饱和。例如,如果多于一个客户订购了感兴趣的给定话题,则消息传递***必须将该数据递送到每个订户,实际上,***将该数据的不同拷贝发送到每个订户。尽管这解决了客户滤除非订购数据的问题,但是单播传输是不可扩展的,因此基本上不适合订购特定数据的大量客户群组或者消费模式极度重叠的情形。
另外,在发布者和订购者之间的路径中,消息在应用之间的跳中传播,其中每跳引入了应用和操作***(OS)等待时间。因此,总的端到端等待时间随着跳数增多而增大。另外,在将消息从发布者路由到订购者时,沿路径的消息吞吐量受到该路径中的最慢节点的限制,在现有***中没有方法来实现端到端消息传递流控制来克服该限制。
现有体系结构的另一个共同不足是它们的协议变换较慢并且数量非常多。这是因为企业应用集成(EAI)领域中的IT(信息技术)权宜(band-aid)策略所致,在该领域中,越来越多的新技术被与遗留***集成。
因此,在多个领域中都需要提高数据消息传递***性能。其中性能可能需要提高的示例有速度、资源分配、等待时间等。
发明内容
本发明部分基于前述观察和利用不同的方法可以解决这种不足使得具有更好的结果这一观点,其中所述不同方法包括基于硬件的解决方案。这些观察使得开发出用于大量、低等待时间消息传递的端到端消息发布/订购中间件体系结构,特别是基于硬件的消息传递设备(MA)。因此,具有根据本发明原理的端到端消息发布/订购中间件体系结构的数据分发***可以有利地在极低等待时间的情况下路由大量的消息,这是通过利用基于邻居的路由选择和网络非居间化(disintermediation)减少中间跳,引入高效的本地到外部和外部到本地协议转换、实时监控***性能(包括等待时间)、布署基于话题和基于信道的消息通信、以及动态并且智能地对***互连配置和消息传输协议进行优化,等等来实现的。另外,这种***可以利用数据缓存提供有保证的递送服务质量。
结合资源分配,根据本发明的数据分发***带来了实时动态分配可用资源的优点。就此而言,与传统的静态配置方法相反,本发明设想了一种***,该***具有用于资源分配的实时、动态、学习的方法。其中可以对资源分配进行实时优化的示例包括网络资源(带宽、协议、路径/路由的利用)和客户***资源(CPU、存储器和盘空间的利用)。
结合监控***拓扑和性能,根据本发明的数据分发***有利地区分开消息级和帧级等待时间测量。在某些情形中,这些测量之间的相关性提供了有竞争力的商业优点。换言之,等待时间的本质和程度可以指示最佳数据和数据源,而其又可以用在商业过程中,并且提供有竞争力的优势。
因此,根据所示并且在这里宽广描述的本发明的目的,具有发布/订购中间件体系结构的一种示例性***包括:一个或多个消息传递设备,其被配置为用于接收和路由消息;介质;以及经由所述介质链接的设置和管理设备,其被配置用于与每个消息传递设备交换管理消息。在这种***中,消息传递设备通过动态选择消息传输协议和消息路由路径,来执行消息的路由选择。
进一步根据本发明的目的,消息传递设备(MA)被配置为边沿MA或核心MA,其中每个MA具有高速互连总线,通过该总线各个硬件模块被链接,另外,边沿MA还具有协议翻译引擎(PTE)。在每个MA中,硬件模块本质上被划分成三个平面模块组,分别为控制平面、数据平面和服务平面。
总而言之,从这里的描述,所附权利要求书以及后面将描述的附图可以更好地理解本发明的这些和其他特征、方面和优点。
附图说明
被结合到说明书中并且作为说明书的一部分的附图说明了本发明的各个方面,并且与说明书一起说明本发明的原理。只要方便,在所有附图中相同的标号将用于指代相同或类似的元件。
图1示出了根据本发明原理的端到端中间件体系结构。
图1a是示出了覆盖网络(overlay network)的图。
图2是示出了利用根据本发明原理的端到端中间件体系结构实现的企业基础设施的图。
图2a是示出了具有创建网络骨干网非居间化的消息设备(MA)的企业基础设施物理布署的图。
图3示出了基于信道的消息传递***的体系结构。
图4示出了一种可能的基于话题的消息格式。
图5示出了基于话题的消息路由选择和路由选择表。
图6a-d是示出了基于硬件的消息传递设备的各个方面的图。
图6e示出了基于硬件的消息传递设备的功能方面。
图7示出了对自适应消息流控制的影响。
具体实施方式
这里的说明提供了消息发布/订购***的端到端中间件体系结构的多个细节,具体而言,根据本发明各个实施例的基于硬件的消息传递设备(MA)的细节。但是,在概括这多个实施例的细节之前,下面简单说明在本说明中使用的术语。注意,该说明仅是为了澄清并且向读者给出对可能如何使用这些术语的理解,但是不是将这些术语限于使用它们的上下文中,也不是要因此限制权利要求书的范围。
术语“中间件”在计算机工业中作为一个一般术语使用,针对在两个分离的通常已存在的程序之间协调的任何编程。添加中间件的目的是从应用卸下与信息交换相关联的一些复杂性,其中这是通过定义网络中的所有参与者(发布者和订购者)之间的通信接口等来实现的。一般而言,中间件程序提供消息传递服务,以使得不同的应用程序可以通信。利用中间件软件层,可以无缝地执行应用之间的信息交换。通常通过利用中间件将不同的应用程序在***上连结到一起被称作企业应用集成(EAI)。但是,在这种上下文中,“中间件”可以是一种更广的术语,用在在源和目的地之间的消息传递和布署来实现这种消息传递的设备的上下文中;因此,中间件体系结构单独或者与下面将描述的组合覆盖了实现高效数据消息传递的联网和计算机硬件与软件组件。此外,术语“消息传递***”或者“中间件***”可以被用在发布/订购***的上下文中,在该***中,消息传递服务器对在发布者和订购者之间的消息路由选择进行管理。实际上,消息传递中间件中发布/订购的范式是可扩展的,因此是一种有力的模型。
术语“客户”可以用在客户机-服务器应用等的上下文中。在一个实例中,客户是这样一种***或应用,其利用应用编程接口(API)注册到中间件***,以订购信息,并且接收该中间件***递送的数据。中间件体系结构边界内部的API是一种客户;并且外部客户是不使用该API的任何发布/订购***(或者外部数据目的地),并且为了与之通信,消息要通过协议变换(稍后将描述)。
术语“外部数据源”可以用在数据分发和消息发布/订购***的上下文中。在一个示例中,外部数据源被认为是位于企业专用网络内或者外部的***或应用,其采用常用协议之一或者其自己的消息协议发布消息。外部数据源的一个示例是市场数据交换,其发布股市报价,股市报价经由中间件***被分发到交易员。外部数据源的另一个示例是事务性数据。注意,在后面将更详细描述的本发明的典型实现方式中,中间件体系结构采用其唯一的本地协议,来自外部数据源的数据一旦进入该中间件***域就被转换成该唯一的本地协议,从而避免了传统***中典型的多协议变换。
术语“外部数据目的地”也用在数据分发和消息发布/订购***的上下文中。例如,外部数据目的地是位于企业专用网络内或外部的***或应用,其订购经由本地/全局网络被路由的信息。外部数据目的地的一个示例可以是对由交易员发布的事务订单进行处理的前述市场数据交换。外部数据目的地的另一个示例是事务性数据。注意,在前述中间件体系结构中,去往外部数据目的地的消息从本地协议被翻译成与该外部数据目的地相关联的外部协议。
从这里的描述可以确认,可以利用作为基于硬件的解决方案被实现在中间件体系结构内的各种配置种的消息传递设备以各种方式来实现本发明。因此,说明从图1示出的端到端中间件体系结构的示例开始。
这种示例性体系结构组合了许多有益特征,这些有益特征包括:消息传递公共概念、API、容错、设置和管理(P&M)、服务质量(QoS-合并的,尽力而为的、有保证同时连接的、有保证同时不连接的,等等)、有保证递送QoS的持久缓存、命名空间和安全***的管理、发布/订购生态***(核心、入口和出口组件)、传输透明的消息传递、基于邻居的消息传递(一种作为轮轴轮辐、对等和存储转发之间的混合体的模型,该模型使用基于订购的路由选择协议,可以在必要时将订购传播到所有邻居)、迟计划绑定、部分发布(与所有数据相对,仅发布改变的信息)和动态分配网络和***资源。后面将说明,发布/订购中间件***有益地结合了中间件体系结构的容错设计。在每个发布/订购生态***中,存在至少一个或多个(通常是两个或更多个)消息传递设备(MA),其中每个消息传递设备被配置为充当边沿(出口/入口)MA或核心MA。注意,发布/订购生态***的核心MA部分使用前述本地消息传输协议(对于中间件***本地的),而入口和出口部分,边沿MA则分别向该本地协议翻译或者从该本地协议翻译。
除了发布/订购***组件之外,图1的图还示出了它们之间的逻辑连接和通信。从图可见,所示的中间件体系结构是分布式***的中间件体系结构。在具有这种体系结构的***中,两个截然不同的物理组件之间的逻辑通信是利用消息流和相关联的消息协议建立起来的。消息流包含两类消息之一:管理和数据消息。管理消息用于管理和控制不同的物理组件、管理对数据的订购,等等。数据消息用于在源和目的地之间传输数据,并且在典型的发布/订购消息传递中,存在数据消息的多个发送者和多个接收者。
利用所示结构配置和逻辑通信,该具有发布/订购中间件体系结构的分布式消息传递***被设计来执行多种逻辑功能。一种逻辑功能是消息协议翻译,该功能有利地在边沿消息传递设备(MA)组件处执行。这是因为发布/订购中间件***的边界内的通信是利用针对消息的本地协议独立于下层传输逻辑被执行的。这就是将这种体系结构称为传输透明基于信道的消息传递体系结构的原因。
第二种逻辑功能是将消息从发布者路由到订购者。注意,这些消息被路由过整个发布/订购网络。因此,路由选择功能由其中传播消息的每个MA执行,即,从边沿MA 106a-b(或者API)到核心MA 108a-c,从一个核心MA到另一个核心MA,最终到达边沿MA(例如,106b)或者API110a-b。API 110a-b经由程间通信总线(套接字、共享存储器等)与应用1121-n通信。
第三种逻辑功能是针对不同类型的有保证的递送服务质量存储消息,包括例如有保证同时连接的和有保证同时不连接的。这是通过添加存储转发功能来实现的。第四种功能是将这些消息递送到订购者。(如图所示,API 106a-b将消息递送到订购应用1121-n)。
在这种发布/订购中间件体系结构中,***配置功能以及其他管理和***性能监控功能由P&M***管理。配置涉及发布/订购中间件***网络和组件的物理和逻辑配置。监控和报告涉及对所有网络和***组件的健康进行监控并且自动报告结果,这是按照每个要求进行的或者被记入日志。P&M***利用管理消息执行其配置、监控和报告功能。另外,P&M***允许***管理员定义与被路由遍该发布/订购***的每个消息相关联的消息命名空间。因此,发布/订购网络可以物理地和/或逻辑地被划分成基于命名空间的子网络。
P&M***管理具有一个或多个MA的发布/订购中间件***。这些MA取决于它们在***中的角色被布署为边沿MA或者核心MA。边沿MA在大多方面与核心MA类似,除了其包括协议翻译引擎之外,协议翻译引擎将消息从外部协议翻译成本地协议和从本地协议翻译成外部协议。因此,一般来说,消息传递***中发布/订购中间件体系结构的边界(即,端到端发布/订购中间件***边界)由其中存在边沿MA 106a-b和API110a-b的边沿表征;并且在这些边界内,存在核心MA 108a-c。
注意,***体系结构不被限制到特定的受限的地理区域,并且实际上,***体系结构被设计为超越区域或国家边界,甚至跨越大洲。在这种情形中,一个网络中的边沿MA可以经由现有的联网基础设施与地理上远离的另一个网络中的边沿MA通信。
在典型的***中,核心MA 108a-c将在该发布/订购中间件***内部发布的消息路由向边沿MA或API(例如,API 110a-b)。尤其是在核心MA中的路由选择图被设计为用于最大量、低等待时间并且高效的路由选择。此外,核心MA之间的路由选择可以实时动态改变。对于穿过多个节点(核心MA)的给定的消息传递路径,路由选择的实时改变是基于一个或多个度量的,这些度量包括网络利用、总的端到端等待时间、通信量、网络和/或消息延迟、丢失和抖动。
或者,不是从两条或多条不同的路径中动态选择最佳执行路径,而是MA可以基于消息复制执行多路径路由选择,并且从而通过所有路径发送相同的消息。位于不同路径的汇聚点处的所有MA将丢弃复制的消息,仅转发第一个到达的消息。这种路由选择方法具有使消息传递基础设施针对低等待时间被最优化的优点;但是这种路由选择的缺点是基础设施需要更多的网络带宽来传送复制的流量。
边沿MA具有这样的能力:将进入消息的任何外部消息协议转换成中间件***的本地消息协议;以及从本地消息协议转换成外出消息的外部协议。即,在消息进入发布/订购网络域(入口)时,外部协议被转换成本地(例如,TervelaTM)消息协议;并且在消息离开发布/订购网络域(出口)时,本地协议被转换成外部协议。边沿MA还操作用于将已发布的消息递送到订购的外部数据目的地。
另外,边沿和核心MA 106a-b和108a-c都能够在转发消息之前存储消息。可以实现该功能的一种方法是利用缓存引擎(CE)118a-b。一个或多个CE可以被连接到相同的MA。理论上,不认为API具有这种存储转发能力,尽管实际上API 110a-b可以在将消息递送到应用之前存储消息,并且其可以在将从应用接收到的消息递送到核心MA、边沿MA或者另一个API之前存储它们。
在MA(边沿或核心MA)具有到CE的活动连接时,其将被路由的消息的全部或者子集转发到CE,CE将它们写到存储区域中以实现持久性。在预定时间段中,这些消息然后可在被请求时用于重传。其中实现了这种特征的示例有数据中继、部分发布和各种服务质量级别。部分发布在减少网络和客户负载方面是有效的,因为其要求仅发送更新的信息,而不是所有信息。
为了说明路由选择图可能如何实现路由选择,图1中示出了发布/订购路由选择路径的数个示例。在该图示中,发布/订购网络的中间件体系结构在发布者和订购者之间提供了五条或更多的通信路径。
第一通信路径将外部数据源链接到外部数据目的地。从外部数据源1141-n接收到的已发布消息被翻译成本地(例如,TervelaTM)消息协议,然后被边沿MA 106a路由。本地协议消息可以从边沿MA 106a被路由的一条路线是到外部数据目的地116n。该路径被称作通信路径1a。在这种情形中,本地协议消息被转换成适于该外部数据目的地的外部协议消息。本地协议消息可以从边沿MA 106a被路由的另一条路线是内部通过核心MA 108b。该路径被称作通信路径1b。沿着该路径,核心MA 108b将本地消息路由到边沿MA 106a。但是,在边沿MA 106a将本地协议消息路由到外部数据目的地1161之前,其将它们转换成适于该外部数据目的地1161的外部消息协议。可见,这种通信路径不要求API将消息从发布者路由到订购者。因此,如果发布/订购***被用于外部源到目的地的通信,则该***无需包括API。
被称作通信路径2的另一条通信路径利用API 110b将外部数据源114n链接到一个应用。从外部数据源接收到的已发布的消息在边沿MA106a处被翻译成本地消息协议,然后被该边沿MA路由到核心MA 108。从第一核心MA 108a出发,这些消息被路由过另一个核心MA 108c到达API 110b。从该API出发,这些消息被递送到订购应用(例如,1122)。因为该通信路径是双向的,所以在另一个实例中,消息可以沿着反向路径从订购应用1121-n到达外部数据目的地116n。在每个实例中,核心MA接收本地协议消息并且路由本地协议消息,而边沿MA接收外部或者本地协议消息,并且分别路由本地或外部协议消息(边沿MA将这种外部消息协议翻译成本地消息协议/从本地消息协议翻译成这种外部消息协议)。每个边沿MA可以将入口消息同时路由到本地协议信道和外部协议信道两者,不管该入口消息是作为本地协议消息还是作为外部协议消息到来的。结果,每个边沿MA可以将入口消息同时路由到外部和内部客户,其中内部客户消耗本地协议消息,而外部客户消耗外部协议消息。这种能力使得消息传递基础设施能够与遗留应用和***无缝并且平滑地集成。
被称作通信路径3的另一条通信路径链接两个应用,这两个应用都利用API 110a-b。这些应用中的至少一个发布消息或者订购消息。已发布的消息到订购应用的递送或者来自发布应用的已发布消息的递送是利用位于发布/订购网络边沿的API实现的。在应用订购消息时,核心或者边沿MA之一将消息路由向该API,该API然后在数据正准备被递送到它们时通知订购应用。从应用发布的消息经由该API被发送到该API被“注册”到其的核心MA 108c。
注意,通过“注册”(登录)到一个MA,该API变为在逻辑上连接到该MA。API通过发送注册(“登录”请求)消息到MA来发起到该MA的连接。在注册之后,该API可以通过将其订购消息发送到该MA来订购特定的感兴趣的话题。话题被用于发布/订购消息传递,来定义共享的访问域和消息的目标,因此,订购一个或多个话题允许接收和发送具有这种话题注释的消息。P&M将周期授权更新发送到网络中的MA,每个MA相应地更新其自己的表格。因此,如果发现API要被授权来订购特定的话题(该MA利用路由选择授权表来验证该API的授权),则该MA激活到该API的逻辑连接。然后,如果该API被适当地注册到核心MA 108c,则核心MA 108c将数据路由到第二API 110,如图所示。在其他示例中,该核心MA 108b可以通过额外的一个或多个核心MA(未示出)路由消息,这一个或多个核心MA将消息路由到API 110b,AP 110b然后将消息递送到订购应用1121-n。
可见,通信路径3不要求存在边沿MA,因为其不涉及任何外部数据消息协议。在一个对这里通信路径给出示例的实施例中,企业***被配置有新闻服务器,该新闻服务器向雇员发布关于多种话题的最新新闻。为了接收到新闻,雇员经由利用API的新闻浏览器应用订购它们感兴趣的话题。
注意,中间件体系结构允许订购一个或多个话题。此外,这种体系结构通过允许消息注释中的通配符,从而利用单个订购请求订购一组相关的话题。
被称作通信路径4的又一条通信路径是与P&M***102和104相关联的多条路径之一,这些路径中的每条将P&M链接到发布/订购网络中间件体系结构中的MA之一。在P&M***和每个MA之间往返的消息是管理消息,管理消息用于对该MA进行配置和监控。在一种***配置中,P&M***直接与MA通信。在另一种***配置中,P&M***通过其他MA与一些MA通信。在又一种配置中,P&M***可以直接或者间接与MA通信。
在典型的实现方式中,中间件体系结构可以被布署在网络上,该网络具有交换机、路由器和其他联网设备,并且其采用基于信道的消息传递,该消息传递能够通过任何类型的物理介质通信。这种架构不可知的基于信道的消息传递的一种示例性实现方式是基于IP的网络。在这种环境中,所有发布/订购物理组件之间的所有通信都通过UDP(数据报协议)执行,并且传输可靠性由消息传输层实现。图1a示出了根据本原理的覆盖网络。
如图所示,覆盖通信1、2和3可以经由交换机214a-c、路由器216和子网218a-c在三个核心MA 208a-c之间发生。换言之,这些通信路径可以建立在下层网络之上,所述下层网络包括联网基础设施,例如子网、交换机和路由器,并且如上所述,这种体系结构可以跨越较大的地理区域(不同的国家甚至不同的大洲)。
很明显,根据本发明原理的前述和其他端到端中间件体系结构可以被实现在各种商业环境中的各种企业基础设施中。图2示出了一种这样的实现方式。
在该企业基础设施中,市场数据分发工厂12被构建在发布/订购网络之上,该发布/订购网络用于将来自各个市场数据交换设备3201-n的股票市场报价路由到交易员(未示出的应用)。这种覆盖解决方案依赖于下层网络提供例如MA之间和这种MA和P&M***之间的互连。到API 3101-n的市场数据递送是基于应用订购的。利用这种基础设施,利用应用(未示出)的交易员将来自API 3101-n的交易单通过发布/订购网络(经由核心MA308a-b和边沿MA 306b)放置回市场数据交换设备3201-n。
图2a中示出了下层物理布署的一个示例。如图所示,MA被直接彼此连接,并且被直接***到网络和子网,在网络和子网中消息传递流量的客户和发布者被物理连接。在这种情形中,互连应当是直接连接,即,MA之间的直接连接和它们与P&M***之间的直接连接。这使得能够实现网络骨干网非居间化,以及消息传递流量与其他企业应用流量物理分离。有效地,MA可以被用来移除对用于消息传递流量的传统路由网络的依赖。
在物理布署的这种示例中,诸如市场数据交换设备之类的外部数据源或者目的地被直接连接到边沿MA,例如,边沿MA 1。诸如市场交易应用之类的消息传递流量消耗或发布应用被直接连接到子网1-12。这些应用具有至少两条路线,用于订购、发布或者与其他应用通信;它们可以或者利用企业骨干网或者利用消息传递骨干网,其中企业骨干网包括多层冗余的路由器和交换机,它们传送所有的企业应用流量,包括但不限于,消息传递流量;消息传递骨干网包括经由集成交换机彼此直接互连的边沿和核心MA。利用替换骨干网具有这样的优点:将消息传递流量与其他企业应用流量隔离,从而更好地控制消息传递流量的性能。在一种实现方式中,位于子网6中的应用逻辑上或者物理上连接到核心MA 3,利用TervelaAPI订购或者发布本地协议的消息流量。在另一种实现方式中,位于子网7中的应用逻辑上或者物理上连接到边沿MA1,订购或者发布外部协议的消息传递流量,其中该MA利用集成的协议变换引擎模块执行协议变换。
逻辑上,发布/订购网络的物理组件被构建在类似于开放***互连(OSI)参考模型的1到4层的消息传输层之上。OSI模型的1到4层分别是物理层、数据链路层、网络层和传输层。
因此,在本发明的一个实施例中,发布/订购网络通过例如在所有网络交换机和路由器或者网络交换机和路由器的子集中***一个或多个消息传递线路卡,从而可以被直接布署到下层网络/构架中。在本发明的另一个实施例中,发布/订购网络可以作为网状覆盖网络(其中,所有物理组件都被彼此连接)而被有效地布署。例如,4个MA的完全网状网络是这样的网络,其中,每个MA被连接到其3个对等MA中的每个。在典型实现方式中,发布/订购网络是下述组件的网状网络:一个或多个外部数据源和/或目的地、一个或多个设置和管理(P&M)***、一个或多个消息传递设备(MA)、一个或多个可选缓存引擎(CE),以及一个或多个可选应用编程接口(API)。
后面将更详细地说明,在企业操作中,可靠性、可用性和一致性通常都是必需的。为此,发布/订购中间件***可以被设计用于容错,其中其组件中的若干个被布署为容错***。例如,MA可以被布署为容错MA对,其中第一MA被称作主MA,第二MA被称作副MA或者容错MA(FTMA)。同样,对于存储转发操作,CE(缓存引擎)可以被连接到主或副核心/边沿MA。在主或副MA具有到CE的活动连接时,其将所路由的消息的全部或者子集转发向该CE,该CE将它们写入存储区域以实现持久性。在预定时间段内,这些消息然后可用于根据请求用于重传。
如前所述,每个发布/订购中间件***的边界内的通信是独立于下层传输逻辑利用针对消息的本地协议来执行的。这就是将这种体系结构称作传输透明基于信道的消息传递体系结构的原因。
图3更详细地示出了基于信道的消息传递体系结构320。一般而言,消息传递源和目的地之间的每条通信路径被限定为一条消息传递信道。每条信道3261-n利用信道源和信道目的地之间的接口3281-n通过物理介质建立。每条这样的信道是针对专门的消息协议建立的,所述消息协议例如是本地(例如,TervelaTM)消息协议或其他。仅边沿MA(对发布/订购网络的入口和出口进行管理的那些MA)利用信道消息协议(外部消息协议)。基于信道消息协议,信道管理层324确定进入和外出消息是否要求协议翻译。在每个边沿MA处,如果进入消息的信道消息协议不同于本地协议,则信道管理层324将在将要处理的消息传递到本地消息层330之前,通过将它们发送过协议翻译引擎(PTE)332,从而执行协议翻译。同样,在每个边沿MA处,如果外出消息的本地消息协议不同于信道消息协议(外部消息协议),则信道管理层324将在将要处理的消息路由到传输信道3261-n之前,将它们发送过协议翻译引擎(PTE)332,从而执行协议翻译。从而,信道对与物理介质的接口3281-n、与该物理介质相关联的特定网络和传输逻辑、以及消息组件或者片段进行管理。
换言之,信道管理OSI传输层322。对信道资源的优化基于每条信道被执行(例如,基于消耗模式对物理介质的消息密度优化,所述消耗模式包括带宽、消息大小分布、信道目的地资源和信道健康统计)。然后,因为通信信道是构架不可知的,所以不要求特定类型的构架。实际上,任何构架介质都将工作,例如,ATM、Infiniband或者以太网。
顺便提及,在例如单个消息被分割到多个帧或者多个消息被打包到单个帧中时,可能需要消息分段或重组。消息分段或重组在消息被递送到信道管理层之前被执行。
图3进一步示出了在具有中间件体系结构的网络中的多种可能的信道实现方式。在一种实现方式340中,通信是利用通过太网交换的网络的多播,经由基于网络的信道执行的,其中以太网交换的网络充当用于这种通信的物理介质。在这种实现方式中,源从其IP地址经由其UDP端口将消息发送向具有其关联UDP端口的目的地群组(被定义为IP多播地址)。在这种实现方式的变体342中,源和目的地之间的通信是利用UDP单播通过以太网交换的网络实现的。源从其IP地址经由其UDP端口将消息发送向在其相应的IP地址处具有UDP端口的选择目的地。
在另一种实现方式344中,信道是利用本地Infiniband传输协议通过Infiniband互连建立的,其中Infiniband架构是物理介质。在这种实现方式中,信道是基于节点的,并且源和目的地之间的通信是利用它们各自的节点地址基于节点的。在又一种实现方式346中,信道是基于存储器的,例如RDMA(远程直接存储器访问),并且在这里被称作直接连接(DC)。利用这种类型的信道,消息从源机器被直接发送到目的地机器的存储器,从而绕过CPU处理来应对从NIC到应用存储器空间的消息,并且可能避免了将消息封装成网络分组的网络开销。
至于本地协议,一种方法利用前述本地TervelaTM消息协议。概念上,TervelaTM消息协议与基于IP的协议类似。每个消息包含消息头部和消息有效载荷。消息头部包含多个字段,其中一个字段用于话题信息。如上所述,话题由客户用来订购共享的信息域。
图4示出了一个可能的基于话题的消息格式。如图所示,消息包括头部370和主体372和374,主体372和374包括有效载荷。示出了两类消息,即,数据和管理消息,这两类消息具有不同的消息体和有效载荷类型。头部包括用于以下内容的字段:源和目的地命名空间标识、源和目的地会话标识、话题序列号和希望时间戳,另外,其还包括话题注释字段(该字段优选是可变长度的)。话题可以被定义为基于标记的字符串,例如,NYSE.RTF.IBM 376,该字符串是包含IBM股票实时报价的消息的话题字符串。
在一些实现方式中,消息中的话题信息可能被编码或者被映射到一个关键字,关键字可以是一个或多个整数值。然后,每个话题会被映射到一个唯一的关键字,并且话题和关键字之间的映射数据库将由P&M***维护,并且通过线路被更新到所有MA。结果,在API订购或者发布一个话题时,MA能够返回用于消息的话题字段的关联的唯一关键字。
优选地,订购格式将遵循与消息话题相同的格式。但是,订购格式还支持与任何话题子字符串匹配的通配符以及与话题子字符串匹配的正则表达式模式。通配符到实际话题的映射可以依赖于P&M***,或者根据通配符或模式匹配请求的复杂度由MA处理。
例如,模式匹配可以遵循例如以下规则:
示例#1:具有通配符T1.*.T3.T4的字符串将与T1.T2a.T3.T4、T1.T2b.T3.T4匹配,但是不与T1.T2.T3.T4.T5匹配
示例#2:具有通配符T1.*.T3.T4.*的字符串将不与T1.T2a.T3.T4、T1.T2b.T3.T4匹配,但是与T1.T2.T3.T4.T5匹配
示例#3:具有通配符T1.*.T3.T4.[*](第五个元素可选)的字符串将与T1.T2a.T3.T4、T1.T2b.T3.T4、以及T1.T2.T3.T4.T5匹配,但是不与T1.T2.T3.T4.T5.T6匹配
示例#4:具有通配符T1.T2*.T3.T4的字符串将与T1.T2a.T3.T4、T1.T2b.T3.T4匹配,但是不与T1.T5a.T3.T4匹配
示例#5:具有通配符T1.*.T3.T4.>(任何数目的结尾元素)的字符串将与T1.T2a.T3.T4、T1.T2b.T3.T4、T1.T2.T3.T4.T5和T1.T2.T3.T4.T5.T6匹配
图5示出了基于话题的消息路由选择。如图所示,话题可以被定义为基于标记的字符串,例如,T1.T2.T3.T4,其中T1、T2、T3和T4是可变长度的字符串。可见,具有特定话题注释400的进入消息被有选择地路由到通信信道404,并且路由选择确定是基于路由选择表402作出的。话题订购到信道的映射定义路由,并且用来将消息传递遍整个发布/订购网络。所有这些路由或者说订购和信道之间的映射的超集定义路由选择表。路由选择表也被称作订购表。用于利用基于字符串的话题进行路由选择的订购表可以以多种方式被构造,但是优选配置为对其大小以及路由选择查找速度进行优化。在一种实现方式中,订购表可以被定义为动态散列图结构,而在另一种实现方式中,订购表可以被布置在树结构中,如图5中的图所示。
树包括由边连接的节点(例如,T1、…、T10),其中话题订购的每个子字符串对应于树中的一个节点。映射到给定的订购的信道被存储在订购的叶子节点上,每个叶子节点指示该话题订购来自的信道的列表(即,通过其接收到订购请求)。该列表指示哪个信道应接收其话题注释与该订购匹配的消息的拷贝。如图所示,消息路由选择查找将消息话题作为输入,然后利用该话题的每个子字符串对树进行解析,来定位与进入消息话题相关联的不同信道。例如,T1,T2,T3,T4和T5被导向信道1、2和3;T1、T2和T3被导向信道4;T1、T6、T7、T*和T9被导向信道4和5;T1,T6,T7,T8和T9被导向信道1;以及T1、T6、T7、T*和T10被导向信道5。
尽管对路由选择表的结构的选择是要对路由选择表的查找进行优化,但是查找的性能还取决于用于找到与进入消息话题匹配的一个或多个话题订购的搜索算法。因此,路由选择表结构应当能够适应这种算法,反之亦然。减小路由选择表的大小的一种方式是允许路由选择算法有选择地将订购传播遍整个发布/订购网络。例如,如果订购看来是已被传播的另一个订购的子集(例如,整个字符串的一部分),则无需传播该子集订购,因为MA已具有该订购的超集的信息。
基于前述,优选的消息路由选择协议是基于话题的路由选择协议,其中授权在订户和相应的话题之间的映射中指示出。授权是针对每个订户或者订户群组/类别指定的,指示该订购有权消耗何种消息或者该发布者可以产生(发布)哪些消息。这些授权是在P&M机器中定义的,被传输到发布/订购网络中的所有MA,然后被MA用来创建和更新它们的路由选择表。
每个MA通过追踪何人被***(请求订购)到何种消息中来更新其路由选择表。但是,在将路由添加到其路由选择表之前,MA必须针对发布/订购网络的授权对订购进行检查。MA验证可能是邻居MA、P&M***、CE或者API的订购实体被授权如此执行。如果该订购是有效的,则路由将被创建并且被添加到路由选择表。然后,因为一些授权可能是预先已知的,所以***可以被布署以预定义授权,并且在引导时这些授权可以被字段加载。例如,诸如配置更新之类的一些特定管理消息可能总是被转发遍网络,并且因此在启动时被自动载入。
给定上面对具有发布/订购中间件体系结构的消息传递***的描述,可以理解消息传递设备(MA)在这种***中具有重要作用。因此,现在描述根据本发明原理配置的基于硬件的消息传递设备(MA)的细节。在本发明的一种实现方式中,MA是独立设备。在本发明的另一种实现方式中,MA定义诸如路由器或交换机之类的任何网络物理组件内部的嵌入式组件(例如,线路卡)。图6a、6b、6c和6d是在各种详细程度上示出了基于硬件的MA的框图。图6e从功能视角示出了MA。
一般而言,MA的体系结构是基于高速互连总线建立的,其中各种硬件模块被连接到该高速互连总线。图6a和6b分别示出了边沿和核心MA106和108的基本体系结构,其中高速互连总线508将各个硬件模块502、504和506互连。边沿MA(106,图6a中)被示为配置有协议翻译引擎(PTE)模块510,而核心MA(108,图6b中)被示为未配置PTE模块。如进一步所示,在一种实施例中,高速互连总线被构造为PCI/PCI-X总线树,其中硬件模块是PCI/PCI-X***设备。PCI(***组件互连)通常被认为是用于计算机高速操作的互连***。PCI-X(扩展的***组件互连)是用于更高速度计算机操作的一种计算机总线技术(计算机部件之间的“数据管道”)。在替换实施例中,高速互连总线被构造为Infiniband或者直接存储器连接介质。在又一个实施例中,硬件模块是经由交换的构架背板(例如,高级电信计算体系结构,ATCA)连接的刀片(blade)。
每个MA的各种硬件模块本质上可以被划分成三组,控制平面模块组502、数据平面模块组504和服务平面模块组506。控制平面模块组处理MA管理功能,包括配置和监控。MA管理功能的示例包括配置网络管理服务、配置被连接到高速互连总线的硬件模块、以及对这些硬件模块进行监控。数据平面模块组处理数据消息路由选择和消息转发功能。该模块组处理由发布/订购中间件***传输的消息以及管理消息,但是管理消息也可以被递送到控制平面模块组。服务平面模块组处理可由控制和数据平面模块无缝使用的其他本地服务。在一个实施例中,本地服务可能是以下服务:利用GPS卡或者能周期性地接收毫秒粒度信号的任何外部同步的设备提供的用于等待时间测量的时间同步服务。这三种模块组将在下面结合图6c、以及图6a和6b更进一步地描述。
控制平面模块组502包括管理模块512。一般而言,管理模块结合有一个或多个运行操作***(OS)的CPU,所述操作***例如是Linux、Solaris、Windows或者任何其他OS。或者,管理模块结合有在安装在高速互连底板中的刀片(服务器)中的一个或多个CPU。在又一种配置中,管理模块结合有在高性能架装主机服务器(high-performance rack-mountedhost server)中运行的一个或多个CPU。
另外,管理模块512包括一个或多个逻辑配置路径。第一配置路径是通过串行接口或网络连接利用命令行接口(CLI)建立的,***管理员通过该命令行接口可以输入配置命令。通过CLI的逻辑配置路径一般被建立来向MA提供初始配置信息,以允许其建立与P&M***的连通性。这种初始配置提供例如但不限于以下信息:本地管理IP地址、默认网关、MA连接到的P&M***的IP地址。作为引导过程的一部分,这种配置的全部或者子集可能被用来对MA中的各个硬件组件进行初始化。
第二配置路径是利用通过发布/订购中间件***路由的管理消息来建立的。一旦MA具有了到一个或多个P&M***的连通性,其就将注册到至少一个P&M******,并且取回其配置。该配置经由在管理模块512本地递送的管理消息被发送到该MA。
从P&M***取回的MA配置信息包含参数、地址等。MA配置信息的示例可能包含Syslog配置参数、网络时间协议(NTP)配置参数、域名服务器(DNS)信息、经由SSH/Telnet和/或HTTP/HTTPS的远程访问策略、认证方法(Radius/Tacacs)、发布/订购授权、指示到相邻MA或者API的连通性的路由选择信息,等等。
整个MA配置可以在管理模块上被缓存到与该管理模块相关联的一个存储器资源或者存储器资源的组合中。MA配置可以被缓存在例如管理模块处的存储器空间中、易失性存储区域中(例如,用于引导文件***的RAM盘)、非易失性存储区域中(例如,存储器闪存卡或者硬盘驱动器),或者它们的任意组合中。如果重引导后仍存在,则该被缓存的配置可以在启动时由MA加载。
在一种实现方式中,缓存的配置还包含由P&M***提供的配置标识符(ID)。该配置ID可以用于比较,其中在MA上本地缓存的MA配置ID被与P&M***上当前的MA配置ID相比较。如果MA和P&M二者中的配置ID相同,则MA可以绕过配置传送阶段,采用本地缓存的配置。另外,在P&M***不可达的情况下,MA可以恢复到最近已知的配置,不管是不是最近的配置,而不是在没有任何配置的情况下启动。
一旦MA被启动并且运行,控制平面模块组(管理模块152)就对与MA的硬件模块内的各个逻辑组件相关联的健康和任何状态改变的标志(状态改变事件)进行监控。例如,状态改变事件可以指示API注册、MA注册,或者它们可以是订购/退订事件。这些和其他状态改变事件被生成并且可以在MA本地被存储一定时间。MA向***监控工具报告这些事件。
可以利用简单网络管理协议(SNMP),或者通过对从MA流向P&M的未经处理的统计数据进行追踪的P&M实时监控和/或历史趋势UI(用户界面)模块对MA进行远程监控。这种未经处理的统计数据可以根据时间段被分批,以减少正产生的监控流量的量。或者,这种未经处理的统计数据可以按照时间段被聚合和处理(例如,通过计算)。
MA的控制平面模块还负责将新的或者旧的固件版本加载到特定硬件模块上。在一个实例中,经由线路上的更新使得固件图像对MA可用。在这些维护窗口中,新的固件图像首先从P&M***被下载到MA。在接收到并且确认了该固件图像后,MA将该图像上传到目标硬件模块。在更新完成后,为了使升级生效,该硬件模块可能必须被重引导。存在多种方式来确认软件图像,一种方式涉及嵌入的签名。例如,MA检查该图像是否已由***提供者或者其被授权被许可者或者团体(例如,Tervela或者TervelaTM技术的任何被许可者)之一签名。
优选地,***管理消息的流量通过专用物理接口被路由。这种方法允许为管理和数据消息流量创建不同的虚拟LAN(VLAN)。这可以通过将被连接到特定物理接口的交换机端口配置为专用于这种到用于所有***管理消息流量的VLAN的接口来实现。然后,其余物理接口的全部或者子集将专用于数据消息的VLAN。通过在下层构架中区分并且分离不同类型的流量,可以独立地对每种类型的消息流量的性能进行管理。
控制平面模块组的另一个功能是对订购表的状态和关于MA和API之间的消息传递信道的统计进行监控的功能。基于该信息,MA中的协议优化服务(POS)决定是否例如从单播信道切换到多播信道,或者反之。类似地,在发现了较慢的客户的情形中,POS可以决定是否将较慢的客户从多播信道移动到单播信道,以保持多播信道的操作完整性。
前述数据平面模块组(502,图6a和6b中)包括一个或多个物理接口卡(PIC;514,图6a-c中),例如,快速以太网、G比特以太网、10G比特以太网、G比特速度存储器互连,等等。这些数据平面PIC在逻辑上由一个或多个消息处理器单元(MPU)控制。MPU被实现为网络处理器单元516、基于MIPS的网络处理卡、定制ASIC、或者任何平台上的嵌入式解决方案。
PIC 514对包含一个或多个消息的帧进行处理。帧通过入口PIC进入MA,入口PIC包含一个或多个芯片组来控制介质专用处理。在一种配置中,PIC还负责OSI第四层终止,这对应于信道传输专用终止,例如,TCP或UDP终止。结果,从PIC转发到MPU的数据可能仅包含来自进入帧的消息流。在另一种配置中,PIC将网络分组发送到在MPU上运行的信道引擎520。信道引擎在移交该网络分组中包含的消息之前,执行OSI第三层到第四层的处理。
在又一种配置中,PIC 514是利用信道专用传输协议将消息转发到信道引擎520的存储器互连接口。另外,在该情形中,信道引擎将具有信道专用处理适配器,用来解析并从进入数据中抽取消息。
在另一种配置中,PIC可能具有专用芯片集和板上存储器,用于执行消息帧的快速转发,这与将要被消息路由选择引擎518路由的这些帧传递到PMU相反。为了实现这种快速转发方法,全局路由选择(订购)表整个或者优选地部分从MPU被分发到PIC中的转发缓存。利用其转发缓存中的这种路由选择表,入口PIC可以对进入消息帧进行检查来在它们中识别一个或多个话题或者话题的任何子集,并且基于这种话题将帧直接转发到出口PIC。注意,如果被分发到PIC的转发缓存的订购表仅代表全局订购表的子集,则可以获得更快的路由选择查找以及作为结果的更快的消息转发的优点。
前述MPU 516利用其信道引擎520负责管理PIC和消息路由选择引擎518之间的通信接口。MPU还利用其消息路由选择引擎518负责维护订购表并且将进入消息与订购和信道相匹配。这些功能可以以多种方式实现,在这多种方式之一中,它们被配置来在不同的微引擎或者微芯片上运行,而在这多种方式中的另一种中,它们被配置来在分离的CPU核心上运行。在第二中情形中,每个核心采用标准的或者定制的网络栈。在又一种实现方式中,这些功能被配置来在实时OS之上的多核CPU中运行。
优选的MPU还具有嵌入的介质交换构架522。因为消息传递信道是构架不可知的,所以MPU可以接口到任何类型的物理介质524。从PIC转发的消息以及可选地从介质交换构架转发的消息都被信道引擎520接收到,然后被转发到消息路由选择引擎518。
信道引擎520对消息传递信道队列进行管理。图6d示出了利用临时消息缓存524的消息排队和利用信道引擎520的消息转发。
在接收方,消息被从信道队列移除。在一些实例中,消息传递信道可能具有专门的优先级。消息传递信道优先级在多于一个信道具有未决消息时是有用的。例如,消息重传请求应当首先被转发;因此,应当理解创建不同的信道用于重传请求。使重传请求延迟可能导致更多的重传请求;在广播/多播风暴时发生的一般就是这种情形。
对于边沿MA 108,信道引擎520中的协议交换机526检查消息是否要求协议翻译。如果必需翻译,则消息被发送到协议翻译引擎510。在该消息被协议翻译引擎转换成本地协议(例如,TervelaTM协议)格式后,其被转发到缓存组件528。缓存组件将该消息放入临时消息缓存524,其中该消息将临时可用于重传。在其时间段经过后,该消息将被移除或者被另一个消息覆写。在一种配置中,临时消息缓存被实现为与消息路由选择引擎518共享的简单存储器环状缓冲器。优选地,临时消息缓存查找被优化,以便通过例如维护将消息序列号映射到缓存中实际消息,从而加速重传过程。消息路由选择引擎518从临时消息缓冲524中取出消息,执行订购查找,然后返回信道列表以转发该消息的拷贝。
一些管理消息可能必须通过共享总线508(图6a、6b和6c)在管理模块512本地被递送。被本地递送的消息也可以被转发遍发布/订购中间件***。在一种实现方式中,消息路由选择引擎518将消息的拷贝推入每个信道的队列中。在另一种实现方式中,消息路由选择引擎518仅将对消息的引用或指向消息的指针入队列,其中消息自身仍在临时消息缓存中。这种方法具有优化MPU上的存储器利用的优点,因为多于一个队列可能引用同一个消息。另外,消息路由选择引擎518在订购消息队列532中附加对消息的引用(例如,指针),其中订购S1和S2的订购队列指向临时消息缓存524中的消息。
然后,每个队列维护对与其相关联的所有订购的一列引用。该方法具有这样的优点:使得能够实现订购级消息处理而不是仅信道级消息处理。有效地,这些订购队列提供了基于每个订购并且基于每个信道索引消息的方式;因此,如果对于给定的订购,需要对消息进行处理,则其缩短了查找时间。例如,在一个实施例中,实时合并逻辑基于每个订购被使用。这还允许MPU执行增值计算,例如,用于股票市场报价消息的成交量加权平均价(VWAP)计算。
在发送方,消息路由选择引擎518对具有未决排队消息的信道加标记或者标志。这允许信道调度器530了解哪条或者哪些信道要求注意或者具有专门的优先级。信道优先级可以被混淆来提供服务质量(QoS)功能。例如,QoS功能是单独基于消息头部字段或者基于消息头部字段和消息主题的组合实现的。此时,消息路由选择引擎518移动到消息缓存环状缓冲器中的下一个消息。
信道调度器530经过具有被排队的消息的所有信道,利用信道专用通信策略转发未决消息。策略确定使用哪种传输协议,是单播、多播还是其他。通信策略可以在创建信道时协商,或者其可能基于资源利用模式而被实时更新,所述资源利用模式例如是网络带宽利用,消息、分组延迟、抖动、丢失等。信道专用通信策略可以是进一步基于与一个或多个信道目的地(例如,邻近的MA或者API)协商的分组流控制参数的。例如,不是发送所有的消息,而是N个消息中可能丢弃一个消息。因此,与该策略相关联的一个方面是消息流控制。
图7示出了实时消息流控制(MFC)算法。根据该算法,信道队列的大小可以作为阈值参数操作。例如,通过特定信道递送的消息在接收设备方处的其信道队列中累积,并且随着该信道队列增大,其大小可以达到在信道不可能发生故障的情况下其不能安全地超过的高阈值,以跟上进入消息流。在接近这种其中信道处于达到其最大能力的危险的情形时,接收消息传递设备可以在信道队列超出限度之前激活MFC。该MFC在队列收缩并且其大小变为小于低阈值时被关闭。高和低阈值之间的差被设置为足以产生这种被称作滞后的行为,其中MFC在比其被关闭的较高队列大小值处被开启。这种阈值差避免了消息流控制的频繁开启-关闭振荡,这种振荡在队列大小在高阈值附近不断变化时会发生。因此,为了避免消息传递接收方的队列超出限度,进入消息的速率被实时动态MFC所约束,动态MFC使该速率保持低于最大信道能力。
作为对其中在信道队列接近其能力时丢弃消息的基于滞后的MFC算法的替换,实时动态MFC可以操作来混合数据或者对订购队列应用一些合并算法。但是,因为这种操作可能要求额外的消息变换,所以其可能回归到较慢的转发路径,而不是保留较快的转发路径。这会放置消息变换对消息传递通吐量的负面影响。该额外的消息变换由与协议变换引擎类似的处理器执行。这种处理器的示例包括NPU(网络处理单元)、语义处理器、MPU上的分离微引擎,等等。
为了更高的效率,实时合并或订购级消息处理可以在发送者和接收者之间分发。例如,在其中仅一个订购者请求订购级消息处理的情形中,将其推向接收者方上的下游而不是在发送者方对其进行执行是有意义的。但是,如果多于一个数据客户正请求相同的订购级消息处理,则在发送者方下游执行其是有意义的。在信道的发送者方和接收者方分发工作量的目的是最优地使用可用的组合处理资源。
传输信道自身对传输专门处理进行处理,该处理更可能是在接收方上利用***芯片在MPU或者PIC上被执行。在信道将多个消息打包到单个帧中时,其可以保持消息等待时间低于最大可接受等待时间,并且通过释放一些处理资源来减轻接收方的压力。有时更有效地是接收较少量的大帧而不是处理许多较小的帧。对于可能利用通用计算机硬件组件(包括CPU、存储器和NIC)在电信OS上运行的API尤其如此。一般而言,NIC被设计来针对每个接收到的帧生成OS中断,这又减少了API可用来将消息递送到订购应用的应用级处理时间。
如上所述,仅边沿MA具有协议翻译引擎(PTE)。在边沿MA中,数据平面模块能够将进入消息转发到PTE(510,图6a、6c和6d中)。这种转发判决由作为信道引擎520的一部分运行的协议开关526在MPU 512处作出。在进入和外出消息协议与本地消息协议不同时,该消息被转发到PTE。
可以以利用处于任何组合的硬件和软件的多种方式实现PTE,包括利用例如语义处理器、FPGA、NPU、或者实时执行的嵌入式软件模块、在面向网络的***芯片或者基于MIPS的处理器上运行的嵌入式OS。如图6c的示例中所示,PTE具有流水线化的面向任务的微引擎,包括消息解析、消息规则查找、消息规则应用和消息格式引擎。构建这种硬件模块时的体系结构约束是保持消息变换等待时间较低,同时允许协议之间的多个复杂的语法变换。另一个约束是使协议转换句法(语法)的固件更新非常灵活,并且独立于下层硬件。
首先,在流水线中,消息解析引擎540取出从PTE入口队列548出队列的消息,然后解析、标识该消息并对该消息加标记。消息解析引擎然后将结果转发到消息规则查找引擎542。消息规则查找引擎基于消息内容执行规则查找,取回需要被应用的匹配规则。消息内容和匹配规则然后被传递到消息规则应用引擎544。规则应用引擎根据匹配规则对该消息的标记进行变换,然后得到的加标记的消息被转发到消息格式引擎546。消息格式引擎根据本地或者外部消息协议重建消息体和头部,然后将其发送回PTE出口队列550。经处理的(翻译的)消息被运送回共享总线508上去往信道引擎520。
如图6a和6b所示,每个MA的各种硬件模块本质上可以被划分成三个组,其中的上述控制平面模块组502和数据平面模块组504与由服务平面模块组506所提供的服务接口并且利用所述服务。就此而言,服务平面模块组包括用于控制平面模块组和数据平面模块组二者的服务模块的集合。服务模块的一个示例是外部时间源,例如GPS(全球定位***)卡。这种服务模块可由任何其他硬件模块用来获得准确的时间戳。例如,通过数据平面路由的每个帧或消息在其进入和/或退出MA时可以被加上时间戳。这种嵌入的时间戳信息在后面可以用来执行等待时间测量。
结果,外部等待时间计算例如涉及将来自数据流的嵌入时间戳与帧进入MA时测得的时间戳相关。然后,通过随时间追踪这种外部等待时间,MA能够建立等待时间趋势,并且检测外部等待时间的任何漂移,并且将该信息嵌入回数据流。这种等待时间漂移随后可以被消息传递路径中的下游节点或者订购应用采用来进行商业级判决和获得有竞争力的优势。
为了追踪等待时间和其他消息传递***统计量,MA具有一个或多个存储设备。这些存储设备保存临时数据,例如从不同硬件组件获得的统计数据、联网和消息传递流量简档,等等。在一种实现方式中,一个或多个存储设备包括保存用于MA启动(引导或重引导)的初始化数据的闪存设备。为了此目的,这种非易失性存储器设备包含核和根ram盘,这些对于管理模块的引导操作是必须的;并且优选还包含默认、启动和运行配置。
这种非易失性存储器还可以保存用于管理消息安全传输的加密密钥、数字签名和证书。在一个示例中,SSL(安全套接字层)协议使用公钥和私钥(非对称)加密***,其还包括使用数字证书。类似地,PKI(公钥基础设施)使得诸如因特网之类的公网的用户能够通过使用通过受信机构获得并共享的公共和私有密码密钥对来实现安全并且私密的数据交换。
可以针对硬件模块所提供的功能对硬件模块进行描述,如图6e所示。消息传递设备的功能方面有网络管理栈602、物理接口管理606、***管理服务614、时间戳服务624、消息传递层608和在边沿消息传递设备中的协议翻译引擎618。这些功能方面与硬件模块相关,如下所述。
例如,网络管理栈(602)在管理模块(512)上运行。TCP/UDP/IP栈(604)是在管理模块的CPU上运行的操作***的一部分。NTP、SNMP、Syslog、HTTP/HTTPS web服务器、Telnet/SSH CLI服务都是在OS之上运行的标准网络服务。
***管理服务(614)也在管理模块(512)上运行。这些***管理服务对网络管理栈和消息传递组件之间的接口进行管理,包括对该***进行配置和监控。
时间戳服务(624)可能被分布到多个硬件组件。要求准确时间戳的任何硬件组件(包括管理模块)包括与服务平面硬件模块时间资源接口的时间戳服务。
总线616a和616b是连接逻辑/功能模块的逻辑总线,其与连接硬件和软件模块的硬件或软件总线相对。
TVA消息层(610)被分布在管理模块和在消息处理单元(516)上运行的消息路由选择引擎(518)之间。管理消息在本地被递送到在管理模块(512)上运行的管理消息引擎。消息路由选择引擎(620)运行在在消息处理单元(516)上的路由选择引擎微引擎上。消息传递层(612)主要在信道引擎微引擎(520)上运行。在一些情形中,信道传输逻辑的一部分被实现在某些传输感知PIC 514a-d上。在本发明的一个实施例中,这种传输感知PIC可以是执行TCP终止的TCP卸载引擎接口。结果,与将在信道引擎上执行相反,部分信道传输逻辑被在PIC上执行。消息Rx和Tx被分布在信道引擎和消息路由选择引擎之间,因为有两个微引擎彼此交流。协议翻译引擎(618)由可选的边沿MA的PTE(510)代表。
总言之,本发明提供了一种用于消息传递的新方法,更具体地说,提供了一种具有基于硬件的消息传递设备的新的发布/订购中间件***,该基于硬件的消息传递设备在提高消息传递***的效率时具有重要的作用。尽管已参考本发明的某些优选版本相当详细地描述了本发明,但是其他版本也是可能的。因此,所附权利要求书的精神和范围不应当被限于对这里所包含的优选版本的描述。
Claims (49)
1.一种发布/订购中间件***中的基于硬件的消息传递设备,包括:
互连总线;以及
经由所述互连总线互连的硬件模块,所述硬件模块被划分成多个组,第一组是用于处理消息传递设备管理功能的控制平面模块组,第二组是用于单独处理消息路由选择功能或者除消息变换功能之外还处理消息路由选择功能的数据平面模块组,并且第三组是用于对由所述硬件模块的第一组和第二组利用的服务功能进行处理的服务平面模块组。
2.如权利要求1所述的基于硬件的消息传递设备,其中,所述消息传递设备管理功能包括配置和监控功能。
3.如权利要求2所述的基于硬件的消息传递设备,其中,所述配置功能包括配置所述发布/订购中间件***。
4.如权利要求1所述的基于硬件的消息传递设备,其中,所述消息路由选择功能包括通过动态选择消息传输协议和消息路由选择路径而执行的消息转发和路由选择。
5.如权利要求1所述的基于硬件的消息传递设备,其中,所述服务功能包括时间源和同步功能。
6.如权利要求1所述的基于硬件的消息传递设备,其中,所述控制平面模块组包括管理模块和一条或多条逻辑配置路径。
7.如权利要求6所述的基于硬件的消息传递设备,其中,所述管理模块结合了计算机、刀片服务器或者主机服务器中的一个或多个中央处理单元(CPU)。
8.如权利要求7所述的基于硬件的消息传递设备,其中,所述管理模块中的CPU在任意操作***下执行程序代码,所述操作***包括Linux、Solaris、Unix和Windows。
9.如权利要求6所述的基于硬件的消息传递设备,其中,每条逻辑配置路径是多条路径之一,其中第一路径是通过串行接口或者网络连接经由命令行接口(CLI)建立的,并且第二路径是利用通过所述发布/订购中间件***路由的管理消息建立的。
10.如权利要求9所述的基于硬件的消息传递设备,其中,所述逻辑配置路径被用于配置信息,并且其中所述管理消息包含这种配置信息,所述配置信息包括以下一种或多种:Syslog配置参数、网络时间协议(NTP)配置参数、域名服务器(DNS)信息、远程访问策略、认证方法、发布/订购授权和消息路由选择信息。
11.如权利要求10所述的基于硬件的消息传递设备,其中,所述消息路由选择功能是基于邻居的,并且所述消息路由选择信息指示到每个邻近消息传递设备或者应用编程接口的连通性。
12.如权利要求10所述的基于硬件的消息传递设备,还包括存储器,如果所述配置信息是持久的,则所述配置信息被存储在所述存储器中,用于以后在重引导期间取回。
13.如权利要求12所述的基于硬件的消息传递设备,其中,所存储的配置信息具有与其相关联的配置标识,所述配置标识用于确定所述配置信息是否是当前的或者是否需要被更新的配置信息所替换。
14.如权利要求1所述的基于硬件的消息传递设备,其中,所述消息传递设备管理功能还包括健康监控功能和状态改变事件监控功能,在启动或者重引导正在进行或者完成后,这两种功能变为活动的。
15.如权利要求14所述的基于硬件的消息传递设备,其中,所述状态改变事件监控功能检测包括API(应用编程接口)注册、消息传递设备注册、以及订购和退订事件在内的事件。
16.如权利要求1所述的基于硬件的消息传递设备,其中,所述消息传递设备管理功能还包括将固件图像上传到所述硬件模块的功能。
17.如权利要求16所述的基于硬件的消息传递设备,其中,所述上传固件图像的功能包括核实所述固件图像。
18.如权利要求9所述的基于硬件的消息传递设备,还包括物理接口,所述物理接口中的一个或多个专用于处理与所述消息传递设备管理功能相关联的管理消息流量,并且其余物理接口可用于数据消息流量,从而使得管理消息流量不与数据消息流量混合,并且不会使得用于数据消息流量的物理接口过载。
19.如权利要求1所述的基于硬件的消息传递设备,还包括消息传输信道,其中所述消息传递设备管理功能还包括对与所述消息传输信道相关联的订购表和统计数据进行监控的功能。
20.如权利要求19所述的基于硬件的消息传递设备,其中,所述统计数据被监控以确定是否从一条信道切换到另一条信道,在发现较慢的客户的情形中,确定是否将所述较慢的客户移动到针对客户优化的信道。
21.如权利要求1所述的基于硬件的消息传递设备,其中,所述数据平面模块组包括一个或多个物理接口卡(PIC)和用于控制所述PIC的消息处理单元(MPU)。
22.如权利要求21所述的基于硬件的消息传递设备,还包括提供对所述管理模块的访问以允许命令行接口(CLI)的串行端口。
23.如权利要求21所述的基于硬件的消息传递设备,其中,所述PIC处理具有一个或多个消息的帧。
24.如权利要求21所述的基于硬件的消息传递设备,还包括全局路由选择表,所述全局路由选择表的一部分或者全部的拷贝被发送到与每个PIC相关联的转发存储器。
25.如权利要求24所述的基于硬件的消息传递设备,其中,所述消息路由选择功能涉及所述转发存储器中的基于话题的路由选择表查找。
26.如权利要求15所述的基于硬件的消息传递设备,其中,所述基于话题的路由选择表查找针对两个PIC之间的或者一个PIC与其自身之间的消息识别一条或者多条路径。
27.如权利要求1所述的基于硬件的消息传递设备,其中,所述服务平面模块组包括可由任意所述硬件模块访问以获得时间戳的外部时间源。
28.如权利要求27述的基于硬件的消息传递设备,其中,所述时间戳被嵌入到消息中并且以后被用于评估等待时间。
29.如权利要求28所述的基于硬件的消息传递设备,还包括非易失性存储器,用于随时间累积由包括所述等待时间在内的统计数据表征的消息流量简档,所累积的消息流量简档在等待时间漂移具体化的情况下建立指示等待时间漂移的趋势。
30.如权利要求29所述的基于硬件的消息传递设备,还包括为了安全性而用于保存加密密钥和证书的非易失性存储器。
31.如权利要求1所述的基于硬件的消息传递设备,被配置为边沿消息传递设备或者核心消息传递设备,其中所述边沿消息传递设备具有用于在外部和本地消息协议之间进行翻译的协议翻译引擎(PTE)。
32.一种发布/订购中间件***中的基于硬件的消息传递设备,包括:
互连总线;
管理模块,其具有彼此接口的管理服务和管理消息引擎,所述管理模块被配置用于处理配置和监控功能;
消息处理单元,其具有消息路由选择引擎和介质交换构架,以及在其间接口的信道引擎,所述消息处理单元被配置用于处理消息路由选择功能;
一个或多个物理接口卡(PIC),用于对由所述硬件消息传递设备接收或者路由的并且去往或者离开所述管理模块和所述消息处理单元的消息进行处理;
包括时间源的服务模块,其中所述管理模块、所述消息处理模块、所述一个或多个PIC和所述服务模块经由所述互连总线被互连。
33.如权利要求32所述的基于硬件的消息传递设备,还包括用于保存配置信息的非易失性存储器和在所述消息处理单元的存储器中维护的临时消息存储区。
34.如权利要求32所述的基于硬件的消息传递设备,对于每个所述PIC,还包括具有用于保存全局***路由选择表的任意部分的存储区的存储器。
35.如权利要求32所述的基于硬件的消息传递设备,其中,外部连通性是构架不可知的,并且因此所述PIC和介质交换构架可以具有任何构架类型。
36.如权利要求32所述的基于硬件的消息传递设备,还包括用于命令行接口的串行端口。
37.如权利要求32所述的基于硬件的消息传递设备,还包括用于在外部和本地消息协议之间进行翻译的协议翻译引擎(PTE)。
38.如权利要求37所述的基于硬件的消息传递设备,被配置为边沿消息传递设备或核心消息传递设备,其中所述边沿消息传递设备包括所述PTE。
39.如权利要求37所述的基于硬件的消息传递设备,其中,所述PTE包括流水线化引擎,所述流水线化引擎包括消息解析、消息规则查找、消息规则应用和消息格式引擎,以及消息入口和出口队列,并且其中所述PTE被连接到所述互连总线。
40.如权利要求32所述的基于硬件的消息传递设备,其中,所述消息路由选择功能是通过动态选择消息传输协议和消息路由选择路径来执行的。
41.如权利要求32所述的基于硬件的消息传递设备,其中,所述信道引擎包括用于处理进入和外出消息的多个传输信道和信道管理模块。
42.如权利要求41所述的基于硬件的消息传递设备,其中,所述信道管理模块包括用于临时缓存接收到的消息的消息缓存模块、用于对传输信道区分优先级的信道调度器,以及用于确定协议翻译需求的协议开关。
43.如权利要求41所述的基于硬件的消息传递设备,其中,所述多个传输信道中的每个具有消息入口和出口队列,所述队列的大小被用作激活消息流控制的标准。
44.如权利要求43所述的基于硬件的消息传递设备,其中,信道能力被视为高阈值,而一个较低的值被视为低阈值,所述消息流控制在所述队列的大小接近所述高阈值时被激活,并且在所述队列大小收缩到低于所述低阈值时被禁止。
45.一种具有发布/订购中间件体系结构的***,包括:
一个或多于一个消息传递设备,其被配置用于接收和路由消息,每个消息传递设备具有互连总线和经由所述互连总线互连的硬件模块,所述硬件模块被划分成多个组,第一组是用于处理消息传递设备管理功能的控制平面模块组,第二组是用于处理消息路由选择功能的数据平面模块组,并且第三组是用于对由所述硬件模块的第一组和第二组利用的服务功能进行处理的服务平面模块组;
互连介质;以及
经由所述互连介质链接的设置和管理设备,其被配置用于与每个消息传递设备交换管理消息,
其中,每个消息传递设备还被配置用于通过动态选择消息传输协议和消息路由选择路径来执行消息的路由选择。
46.如权利要求45所述的***,其中,所述消息传递设备包括一个或多个边沿消息传递设备和核心消息传递设备。
47.如权利要求46所述的***,其中,每个边沿消息传递设备包括协议变换引擎,用于将进入消息从外部协议变换到本地协议,以及用于将被路由的消息从所述本地协议变换到所述外部协议。
48.如权利要求1所述的基于硬件的消息传递设备,其可作为交换或路由选择设备中的嵌入式组件工作。
49.如权利要求45所述的***,其中,一个或多个所述消息传递设备被互连以提供网络非居间化。
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US64198805P | 2005-01-06 | 2005-01-06 | |
US60/641,988 | 2005-01-06 | ||
US60/688,983 | 2005-06-08 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN101133380A true CN101133380A (zh) | 2008-02-27 |
Family
ID=39086087
Family Applications (5)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CNA2005800460945A Pending CN101124566A (zh) | 2005-01-06 | 2005-12-23 | 端到端的发布/订购中间件体系结构 |
CNA200580046095XA Pending CN101124567A (zh) | 2005-01-06 | 2005-12-23 | 消息传递***中的缓存引擎 |
CNA2005800461011A Pending CN101133380A (zh) | 2005-01-06 | 2005-12-23 | 基于硬件的消息传递设备 |
CNA2005800460930A Pending CN101326508A (zh) | 2005-01-06 | 2005-12-23 | 智能消息传递应用编程接口 |
CNA2006800018954A Pending CN101151604A (zh) | 2005-01-06 | 2006-01-06 | 消息发布/订购***中的设置和管理 |
Family Applications Before (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CNA2005800460945A Pending CN101124566A (zh) | 2005-01-06 | 2005-12-23 | 端到端的发布/订购中间件体系结构 |
CNA200580046095XA Pending CN101124567A (zh) | 2005-01-06 | 2005-12-23 | 消息传递***中的缓存引擎 |
Family Applications After (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CNA2005800460930A Pending CN101326508A (zh) | 2005-01-06 | 2005-12-23 | 智能消息传递应用编程接口 |
CNA2006800018954A Pending CN101151604A (zh) | 2005-01-06 | 2006-01-06 | 消息发布/订购***中的设置和管理 |
Country Status (1)
Country | Link |
---|---|
CN (5) | CN101124566A (zh) |
Cited By (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102783090A (zh) * | 2009-12-23 | 2012-11-14 | 思杰***有限公司 | 用于多核***中的对象速率限制的***和方法 |
CN104579605A (zh) * | 2013-10-23 | 2015-04-29 | 华为技术有限公司 | 一种数据传输方法及装置 |
CN104756079A (zh) * | 2012-10-23 | 2015-07-01 | 日本电气株式会社 | 规则分配服务器、事件处理***和方法以及程序 |
CN107306248A (zh) * | 2016-04-19 | 2017-10-31 | 广东国盾量子科技有限公司 | 一种光量子交换机及其通信方法 |
CN108390917A (zh) * | 2018-01-25 | 2018-08-10 | 珠海金山网络游戏科技有限公司 | 智能发送消息方法和装置 |
CN110431586A (zh) * | 2017-03-16 | 2019-11-08 | 软银股份有限公司 | 中继装置和程序 |
TWI678087B (zh) * | 2018-11-22 | 2019-11-21 | 財團法人工業技術研究院 | 訊息佇列發佈與訂閱之同步方法及其系統 |
CN110830285A (zh) * | 2018-08-09 | 2020-02-21 | 塔塔咨询服务有限公司 | 用于fpga中间件框架的基于消息的通信和故障恢复的方法和*** |
CN115086403A (zh) * | 2022-04-27 | 2022-09-20 | 中国科学院上海微***与信息技术研究所 | 一种针对泛在异构接入的边缘计算网关微服务架构 |
Families Citing this family (18)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2011029821A (ja) * | 2009-07-23 | 2011-02-10 | Canon Inc | 情報処理装置、情報処理装置の制御方法、及び情報処理装置の制御プログラム |
EP2367309B1 (en) | 2010-02-10 | 2016-07-13 | Alcatel Lucent | Method for detecting a synchronization failure of a transparent clock and related protection schemes |
US20120135676A1 (en) * | 2010-11-26 | 2012-05-31 | Industrial Technology Research Institute | System and method for deployment and management of interactive regional broadcast services |
WO2013152312A1 (en) * | 2012-04-06 | 2013-10-10 | Interdigital Patent Holdings, Inc. | Optimization of peer-to-peer content delivery service |
WO2014049603A2 (en) * | 2012-08-28 | 2014-04-03 | Tata Consultancy Services Limited | Method and system for dynamic selection of reliability by data publishing protocol while publishing data |
CN103677549B (zh) * | 2012-09-11 | 2017-08-11 | 阿里巴巴集团控股有限公司 | 一种数据处理方法与装置 |
CN103534988B (zh) | 2013-06-03 | 2017-04-12 | 华为技术有限公司 | 消息发布与订阅的方法及装置 |
US9984158B2 (en) * | 2014-03-18 | 2018-05-29 | Axis Ab | Finding services in a service-oriented architecture (SOA) network |
CN104618466A (zh) * | 2015-01-20 | 2015-05-13 | 上海交通大学 | 基于消息传递的负载均衡和过负荷控制***及其控制方法 |
CN105991579B (zh) * | 2015-02-12 | 2019-05-28 | 华为技术有限公司 | 信息发送方法、相关网络设备以及*** |
US9407585B1 (en) * | 2015-08-07 | 2016-08-02 | Machine Zone, Inc. | Scalable, real-time messaging system |
US9608928B1 (en) * | 2016-07-06 | 2017-03-28 | Machine Zone, Inc. | Multiple-speed message channel of messaging system |
CN106210101B (zh) * | 2016-07-20 | 2019-06-18 | 上海携程商务有限公司 | 消息管理***及消息管理方法 |
CN107819734A (zh) * | 2016-09-14 | 2018-03-20 | 上海福赛特机器人有限公司 | 一种基于网络套接字的程序间通讯方法及通讯*** |
EP3767922B1 (en) * | 2019-07-17 | 2023-11-08 | ABB Schweiz AG | Method of channel mapping in an industrial process control system |
CN110532113B (zh) * | 2019-08-30 | 2023-03-24 | 北京地平线机器人技术研发有限公司 | 信息处理方法、装置、计算机可读存储介质及电子设备 |
CN112817779A (zh) * | 2021-01-29 | 2021-05-18 | 京东方科技集团股份有限公司 | 组件化应用程序通信方法、装置、设备及介质 |
CN114827307B (zh) * | 2022-04-14 | 2024-04-19 | 中国建设银行股份有限公司 | 基于多数据***的数据共享方法、***及服务器 |
-
2005
- 2005-12-23 CN CNA2005800460945A patent/CN101124566A/zh active Pending
- 2005-12-23 CN CNA200580046095XA patent/CN101124567A/zh active Pending
- 2005-12-23 CN CNA2005800461011A patent/CN101133380A/zh active Pending
- 2005-12-23 CN CNA2005800460930A patent/CN101326508A/zh active Pending
-
2006
- 2006-01-06 CN CNA2006800018954A patent/CN101151604A/zh active Pending
Cited By (17)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102783090A (zh) * | 2009-12-23 | 2012-11-14 | 思杰***有限公司 | 用于多核***中的对象速率限制的***和方法 |
CN102783090B (zh) * | 2009-12-23 | 2015-05-20 | 思杰***有限公司 | 用于多核***中的对象速率限制的***和方法 |
CN104756079A (zh) * | 2012-10-23 | 2015-07-01 | 日本电气株式会社 | 规则分配服务器、事件处理***和方法以及程序 |
CN104579605A (zh) * | 2013-10-23 | 2015-04-29 | 华为技术有限公司 | 一种数据传输方法及装置 |
CN104579605B (zh) * | 2013-10-23 | 2018-04-10 | 华为技术有限公司 | 一种数据传输方法及装置 |
US10069604B2 (en) | 2013-10-23 | 2018-09-04 | Huawei Technologies Co., Ltd. | Data transmission method and apparatus |
CN107306248A (zh) * | 2016-04-19 | 2017-10-31 | 广东国盾量子科技有限公司 | 一种光量子交换机及其通信方法 |
CN107306248B (zh) * | 2016-04-19 | 2023-04-28 | 广东国盾量子科技有限公司 | 一种光量子交换机及其通信方法 |
CN110431586A (zh) * | 2017-03-16 | 2019-11-08 | 软银股份有限公司 | 中继装置和程序 |
CN110431586B (zh) * | 2017-03-16 | 2020-11-17 | 软银股份有限公司 | 中继装置 |
CN108390917B (zh) * | 2018-01-25 | 2021-02-02 | 珠海金山网络游戏科技有限公司 | 智能发送消息方法和装置 |
CN108390917A (zh) * | 2018-01-25 | 2018-08-10 | 珠海金山网络游戏科技有限公司 | 智能发送消息方法和装置 |
CN110830285A (zh) * | 2018-08-09 | 2020-02-21 | 塔塔咨询服务有限公司 | 用于fpga中间件框架的基于消息的通信和故障恢复的方法和*** |
CN110830285B (zh) * | 2018-08-09 | 2022-03-25 | 塔塔咨询服务有限公司 | 用于fpga中间件框架的基于消息的通信和故障恢复的方法和*** |
TWI678087B (zh) * | 2018-11-22 | 2019-11-21 | 財團法人工業技術研究院 | 訊息佇列發佈與訂閱之同步方法及其系統 |
US10841390B2 (en) | 2018-11-22 | 2020-11-17 | Industrial Technology Research Institute | Method and system for synchronizing publication and subscription of message queues |
CN115086403A (zh) * | 2022-04-27 | 2022-09-20 | 中国科学院上海微***与信息技术研究所 | 一种针对泛在异构接入的边缘计算网关微服务架构 |
Also Published As
Publication number | Publication date |
---|---|
CN101326508A (zh) | 2008-12-17 |
CN101151604A (zh) | 2008-03-26 |
CN101124566A (zh) | 2008-02-13 |
CN101124567A (zh) | 2008-02-13 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN101133380A (zh) | 基于硬件的消息传递设备 | |
US9253243B2 (en) | Systems and methods for network virtualization | |
US20060168070A1 (en) | Hardware-based messaging appliance | |
US20110185082A1 (en) | Systems and methods for network virtualization | |
US20150271255A1 (en) | Systems and methods for adaptive load balanced communications, routing, filtering, and access control in distributed networks | |
CN111612466B (zh) | 一种共识和资源传输方法、设备及存储介质 | |
KR20050002604A (ko) | 데이터 전송 관리 시스템 및 방법 | |
US10652310B2 (en) | Secure remote computer network | |
Borky et al. | Developing the network dimension | |
Endo et al. | A distributed architecture for massively multiplayer online services with peer-to-peer support | |
Panda et al. | Commodity High Performance Interconnects | |
Geetha et al. | Optimized Scheduling Algorithm for Energy-Efficient Wireless Network Transmissions. | |
Selim et al. | A low cost and resilient message queuing middleware |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
REG | Reference to a national code |
Ref country code: HK Ref legal event code: DE Ref document number: 1120315 Country of ref document: HK |
|
C02 | Deemed withdrawal of patent application after publication (patent law 2001) | ||
WD01 | Invention patent application deemed withdrawn after publication |
Open date: 20080227 |
|
REG | Reference to a national code |
Ref country code: HK Ref legal event code: WD Ref document number: 1120315 Country of ref document: HK |