CN1783852A - 使用web服务可靠消息通信协议的高效消息传输 - Google Patents

使用web服务可靠消息通信协议的高效消息传输 Download PDF

Info

Publication number
CN1783852A
CN1783852A CNA2005101188767A CN200510118876A CN1783852A CN 1783852 A CN1783852 A CN 1783852A CN A2005101188767 A CNA2005101188767 A CN A2005101188767A CN 200510118876 A CN200510118876 A CN 200510118876A CN 1783852 A CN1783852 A CN 1783852A
Authority
CN
China
Prior art keywords
message
window size
transmission
message window
recipient
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.)
Granted
Application number
CNA2005101188767A
Other languages
English (en)
Other versions
CN1783852B (zh
Inventor
R·D·希尔
S·R·巴特雷斯
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Microsoft Corp
Original Assignee
Microsoft Corp
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Microsoft Corp filed Critical Microsoft Corp
Publication of CN1783852A publication Critical patent/CN1783852A/zh
Application granted granted Critical
Publication of CN1783852B publication Critical patent/CN1783852B/zh
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/40—Business processes related to the transportation industry
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/11—Identifying congestion
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/25—Flow control; Congestion control with rate being modified by the source upon detecting a change of network conditions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/26—Flow control; Congestion control using explicit feedback to the source, e.g. choke packets
    • H04L47/263—Rate modification at the source after receiving feedback
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/27—Evaluation or update of window size, e.g. using information derived from acknowledged [ACK] packets
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/30—Flow control; Congestion control in combination with information about buffer occupancy at either end or at transit nodes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Business, Economics & Management (AREA)
  • Health & Medical Sciences (AREA)
  • Economics (AREA)
  • General Health & Medical Sciences (AREA)
  • Human Resources & Organizations (AREA)
  • Marketing (AREA)
  • Primary Health Care (AREA)
  • Strategic Management (AREA)
  • Tourism & Hospitality (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Communication Control (AREA)
  • Computer And Data Communications (AREA)

Abstract

本发明根据Web服务可靠消息通信(RM－WS)协议提供流量和拥塞控制机制。对于流量控制，一个端点通过在响应消息中包括缓冲区大小信息，来通知另一个端点其可用缓冲区大小。通常为RM－WS基础结构消息的响应消息随即被用来确定为避免由于缓冲区过速而重新发送消息，可向接受者发送的消息个数的上限。在拥塞控制的情形中，各实施例规定增加传输中消息的个数，直至找到失败点。失败点以下的最后成功速率是最接近最优点的已知点。示例性实施例随即重置并将速率重新提高回最后已知好点，并使用逼近最优速率的算法来从该处起进行微调。

Description

使用WEB服务可靠消息通信协议的高效消息传输
相关申请的参照
无
技术领域
本发明一般涉及Web服务可靠消息通信。特别地，本发明根据用于在两个端点之间进行流量控制和网线上的拥塞控制的Web服务可靠消息通信协议，提供一种消息的高效传输。
背景技术
通过允许一个计算机或设备(下文称为“计算设备”或“计算系统”)使用电子消息通过网络与另一计算系统进行通信，计算机网络增强了我们通信和访问信息的能力。当在计算系统之间传输电子消息时，电子消息常常会通过协议栈，它对电子消息内的数据执行操作(例如，语法分析、路由、流量控制、等等)。开放系统互连(OSI)模型是用于实现协议栈的网络框架的一个例子。
OSI模型将用于传输电子消息的操作分解成7个不同的层，每一层都被指定在数据传输过程中执行某些操作。尽管协议栈可能能够实现每一个层，但是许多协议栈仅选择性地实现若干层，以供在通过网络传输数据中使用。当数据从计算系统被发送时，它始发于应用层，并被向下传递到若干中间较低层，然后传递到网络上。当从网络上接收数据时，它进入物理层，并被向上传递到若干较高中间层，最终在应用层处被接收。应用层——最上层——负责支持应用程序和端点用户处理。此外，在应用层内，可能驻留有若干其它层(例如，简单开放访问协议(SOAP)层)。大多数协议栈包括的另一个层是传输层。传输层的一个例子是传输控制协议(TCP)。
Web服务(WS)是发展计算系统之间的通信中的驱动力量，并正在彻底地改变我们构建和使用软件的方式。Web服务让应用程序共享数据以及——更强大的是——从其它应用程序调用各种能力，而无须考虑这些应用程序是如何构建的；它们在什么操作系统或平台上运行；以及使用什么设备来访问它们。Web服务是通过包括SOAP、XML(可扩展标记语言)、UDDI(统一、描述、发现和集成)、SWDL(Web服务描述语言)等工业标准协议的手段，通过因特网来调用的。尽管Web服务保持相互独立，但它们可将自身松散地链接成执行特定任务的协作组。
当前的WS技术提供发起者(例如，客户)和接受者(例如，服务)之间的直接SOAP消息通信。在普通双向消息通信实例中，SOAP请求消息从发起者被发送到接受者，响应于此，SOAP回复消息被发送。端点之间的另一种形式的通信是单向消息，其中发起者向接受者发送消息，而没有响应。
新兴的WS体系结构的一个关键优点是提供集成的、可互操作的解决方案的能力。但是，因为Web服务经由诸如因特网等不可靠的通信信道，提供来自不同商务、发源及其它服务供应者的各种服务，所以WS的可靠性成为越来越重要的因素。WS的可靠性受到若干因素的影响，包括但不限于，Web服务端点的可靠性、访问Web服务所通过的通信信道的可靠性特征、性能和容错性特征、以及Web服务能处理并发客户访问的程度。
人们试图通过选择可靠的传输协议在端点之间交换消息(例如，SOAP消息)来实现Web服务可靠消息通信。例如，可使用诸如消息队列等可靠消息通信传输在发起者和接受者之间可靠地传递消息。消息排队通信技术使不同系统上的应用程序能通过将消息发送到队列并从队列读取消息来相互通信，其中为可靠性起见，这些队列在发生失败时持续存储。
尽管排队系统提供可用于可靠地携带SOAP消息的传输，此类系统仍有若干缺点。例如，这些系统为孤立地传输和处理请求(可能还有其响应)的异步操作提供解决方案。由此，就资源而言，这些系统通常是重量级的，它们涉及具有持久事务化消息存储、并且部署、编程模型和管理复杂得多的多个中间方。所有这些对于可靠的直接通信来说都是不必要的，还损害了将等待时间最小化的目标。此外，该程序模型不直接支持请求-响应式的编程或会话。由此，排队通信模型和当前“交互式”Web服务模型不同，并且不解决关键性的“连接”情形和“交互式”应用程序。例如，它不太适用于以及时方式预期响应的情形，或者需要在发起者和接受者之间共享分布式事务上下文的情形。
人们还试图在基本不可靠的传输协议上定义可靠的传输层，例如，可靠HTTP或称HTTPR。但是，困扰此解决方案以及排队解决方案的一个常见问题是仅当为发起者和接受者之间的通信使用特定的可靠传输协议时才能实现可靠消息通信。Web服务的基本特性要求不依赖于特定供应商平台、实现语言和特定传输协议。在一般情形中，发起者可能不能使用特定协议向接受者直接发送消息(例如，接受者不支持该协议)，或者该消息在离开发送节点之后到达目标节点之前，可能需要通过多个中继段。根据特定中继段中所涉及的两个节点之间的连通性的特性，可能不得不选择不提供可靠消息通信特征的合适的传输协议。
中间方还可能存在于协议栈中的不同层处，并因此不提供完全的端对端可靠性。例如，传输协议可能通过较低层的中间方(例如，IP层的中间方——例如IP路由器)来提供可靠性。但是，传输协议可能在SOAP中间方或应用层处结束。由此，传输协议可能不能够通过该中间方来提供可靠性，即，没有通过应用层的端对端可靠性。
近来，例如WSReliableMessaging等Web服务的各种可靠消息通信协议(以下称为“RM-WS协议”)为当前可靠消息通信系统以上所标识的缺陷提供解决方案。这些协议是在存在软件组件、系统或网络失败时允许消息在端点应用程序之间被可靠传递的传输不可知连接协议。因此，RM-WS协议提供发起者和接受者之间可靠的、端对端的、面向会话的通信的解决方案。
这些RM-WS协议类似于TCP，因为TCP通过因特网协议(IP)路由器和多个网络，提供从TCP发送器到TCP接收器的可靠的、恰好一次的、按次序的字节流的传输。WS的可靠消息通信协议通过多个中间方(包括SOAP层中间方)、传输和连接，为消息提供相同和更多的传输方案(注意：传输的单元是消息，而不是字节)。尽管TCP和RM-WS协议都是“可靠”协议，因为RM-WS驻留在OSI模型中的应用层或SOAP层，所以无论使用什么传输协议来传输数据，RM-WS协议都提供可靠的消息通信。由此，RM-WS协议不依赖于用于在端点之间传输消息的特定传输或其它协议。
尽管若干种RM-WS协议已经存在了一段时间，这些协议规范仍有一些缺点和缺陷。例如，当前这些协议没有为端点之间消息的流量控制定义任何解决方案。通常，可靠消息交换中的接受者具有缓冲区，所接收的消息被存储在缓冲区中，以供向处理应用程序传递。这解决了系统中的灵活性，因为不需要处理应用程序在消息一被接收到时即可用于对其进行处理。但是，缓冲区的容量是有限的，因为任何系统都只有有限的资源可用(受硬件和/软件限制)。同样，如果接收应用程序处理消息的速率低于消息被发送和/或接收的速率，也可能产生问题。在此情形中，接受者缓冲区将被填满，且所接收到的消息不会从传输被读取或可能被丢弃(即从传输读取消息，但因为缺少空间而未将其捕获到缓冲区中的动作)；并因此没有为该消息发送接收确认。
消息丢弃是受典型RM-WS协议允许的，并且不被视为严重失败；因为在缺少来自接受者的接收确认时，发起者将重试传输。但是，重试引起网络和系统资源的浪费；因此产生对用于令发起者知道它可向接受者发送多少个消息而不会使它们被丢弃的高效机制的需求。
类似于上述的流量控制问题，网线上的拥塞控制也是一项议题。通常，通过网络发送的消息是通过由各个节点(例如，路由器)桥接的若干传输连接来传输的。不同的传输连接可能有不同的速度(例如，从发起者到一节点的100mbps以太网连接，和从该节点到接受者的56kbps拨号连接)。由于各传输连接的速度差异，从节点到接受者的连接可能积滞，即该网络不能取任何新内容用于传递，因为首先需要取走一些内容。这意味着在该节点能将传入消息发送到目的地之前，它不得不减慢使其缓冲区传入消息的分程传输。和其它计算资源类似，在节点必须开始丢弃新的传入消息之前，它们仅能缓冲这些数量的消息。尽管缓冲是用于处理瞬时通信量峰值的可接受的技术，但是为了将等待时间最小化，系统应当力争将中间方中所发生的缓冲量最小化。此外，丢弃消息的其它原因包括节点的许多传入链路都竞争同一传出链路，接受者处理请求缓慢，或者节点处活动的突发。
无论网络丢弃消息的原因是什么，如前所述，在可靠消息通信系统中，丢弃的消息需要被重试以确保传递。如果要求按次序的传递，那么对序列号大于丢弃消息的那些消息的处理将被延迟到丢弃消息被接收到之后，从而导致接受者方处理效率低下。此外，重试丢弃的消息导致从发起者到节点的链路上甚至更多的消息，这可能最终导致更多丢弃的消息——即，拥塞、性能障碍和资源浪费。
因此，产生对不仅为流量控制进行调节、而且会为网线上的拥塞适应各种变化的解决方案。如可认识到的，该问题涉及在从发起者到接受者的路径上使用多个节点(例如，路由器)的情形。同样，该解决方案不应考虑路由器的数量，因为该数量对发起者是未知的，并且实际上可能随时间改变。此外，该解决方案还应能够适应于网络带宽、性能和拓扑结构的改变。
发明内容
根据本发明的实施例，当前Web服务可靠消息通信协议的上述缺陷和缺点被克服。例如，本发明通过基于接受者可用的缓冲区大小动态地确定用于发送消息的消息窗口大小，根据WS的可靠消息通信协议(RM-WS)，解决在端点之间高效传输消息的问题。此外，本发明根据RM-WS协议，通过调整用于将消息发送到端点的传输窗口以适应于诸如网络带宽、性能和拓扑结构的变化等因素，解决控制网络拥塞的问题。
例如，一个针对流量控制的实施例根据RM-WS协议解决在应用层建立发起者和接受者之间序列会话的问题。包括所期望缓冲区大小的信息的消息通过序列会话被接收——接受者指示用于缓冲等待应用程序处理的消息的可用存储器的量的接受者缓冲区大小信息。此外，若干传输中(in-flight)消息被标识，根据RM-WS协议，它们是已被发送到接受者而没有接收到对应确认的消息。基于接受者缓冲区大小的信息和传输中消息的个数，计算出表示为避免由于缓冲区过速而重新发送消息，可向接受者发送的消息个数的上限的消息窗口大小。
在另一个用于拥塞控制的示例性实施例中，本发明根据RM-WS协议，解决通过已建立的序列会话向接受者发送对应于消息窗口大小的若干消息的问题。该消息窗口大小表示在一根网线上向接受者发送的传输中消息的个数的上限。基于该消息窗口大小，标识出期望的消息传输时间，它定义在发送若干消息和接收对应的确认消息之间期望的时间限制。此后，提供关于在期望消息传输时间到期之前是否接收到对应的确认消息的指示，其中该指示为避免由于网络拥塞而重新发送消息，被用于调整消息窗口大小和/或重试时间周期。
本发明的其它特征和优点将在以下描述中阐述，且部分地可从该描述中变得显而易见，或可通过对本发明的实施中习得。本发明的特征和优点能以在所附权利要求书中特别指出的手段及其组合的方式来实现和获得。本发明的这些及其它特征将从以下描述和所附权利要求书中变得更加清楚，或可通过如下所述地实施本发明来习得。
附图说明
为了描述可获得本发明上述及其它优点和特征的方式，将参考附图中所示出的本发明的具体实施例来提供对以上所简述的发明更具体的描述。理解这些附图仅示出本发明的若干典型实施例，且因此不应被视为限制本发明的范围，因此将通过使用附图，来更加具体和详细地描述和解释本发明，附图中：
图1A根据本发明的示例性实施例，示出一种配置成为两个端点之间的流量控制变化进行调整的计算系统；
图1B根据本发明的示例性实施例，示出一种配置成适应于网线上的拥塞变化的计算系统；
图2根据本发明的示例性实施例，示出一种在端点之间高效传输消息的方法的流程图；
图3根据本发明的示例性实施例，示出一种控制网络拥塞的方法的流程图；及
图4示出一种为本发明提供合适的操作环境的示例性系统。
具体实施方式
本发明涉及用于在Web服务可靠消息通信协议的环境中进行流量和拥塞控制的方法、系统和计算机程序产品。本发明的实施例可包括专用或通用计算机，它包括各种计算机硬件，如以下将更详细讨论。
本发明涉及Web服务可靠消息通信协议(以下称为“RM-WS”协议)的扩展，它描述在存在软件组件、系统或网络失败的情况下，允许消息在分布式应用程序之间被可靠传递的协议。Web服务可靠消息通信协议便于消息从源(以下称为“发起者”)到例如服务等目的地(以下称为“接受者”)的成功传输，并确保出错情况是可检测的。这些协议是传输不可知的，从而允许使用不同的网络传输技术来实现它们。此外，可靠消息通信协议的各种实现对应用程序隐藏间歇性的通信失败，并可在系统失败的情形中提供可恢复性。
若干示例性实施例通过基于接受者的可用缓冲区大小动态确定用于发送消息的消息窗口大小，使用RM-WS协议来提供消息的高效传输。更特别地，本发明提供一种流量控制机制，其中接受者让发起者知道接受者的缓冲区中有多少空间。接受者缓冲区大小的信息被包括在响应消息中(例如，基础结构确认响应消息)，发起者随即使用该信息来计算消息窗口大小。此计算所得的窗口大小从而定义为避免由于缓冲区过速而重新发送消息，可向接受者发送的消息数量的上限。
图1A示出上述示例性流量控制实施例。图1A示出分布式网络100，它包括发起者105和接受者120。在发起者105和接受者120之间建立有连接，用于根据RM-WS协议交换消息。一旦建立连接，接受者120即可周期性地在消息内(例如，基础结构消息115)向发起者105发送关于其缓冲区大小的信息。接受者缓冲区大小的信息指示等待应用程序135处理的已缓冲消息185的可用存储器130的量。
注意，尽管基础结构消息115通常被用来向发起者105发送接受者缓冲区大小的信息，但是应用层消息(例如，作为接受者的输出被发送的消息)也可包括用于为接受者120标识存储器可用大小的扩展。此外，根据RM-WS协议，基础结构消息115通常是确认响应消息；但是本发明不限于任何特定类型的基础结构消息115。因此，在传递接受者缓冲区大小的信息中使用基础结构消息115——以及所提及的任何特定类型的基础结构消息——仅是为说明性目的而使用的，而不意味着限制或者缩小本发明的范围，除非在所附权利要求书中明确声明。
无论是什么类型的消息，一接收到基础结构消息115内对接受者缓冲区大小的指示，发起者105即可发送多达该缓冲区大小信息所指示的个数的消息。换言之，接受者的存储器130已经有在等待应用程序135处理的若干已缓冲消息185。因此，在丢弃消息之前发起者105可向接受者120发送的最大消息个数是由存储器130内的可用缓冲区大小确定的。
注意，基础结构消息115内的接受者缓冲区大小的信息是发起者105将向接受者120发送的消息个数的上限。但是，可基于诸如传输中消息的个数、之前接收到的确认的个数、当前正被确认的消息的个数等因素来修改此上限。例如，发起者105可标识若干传输中消息125，根据RM-WS协议，它们是已被发送到接受者，但没有接收到对应确认的消息。这些传输中消息125可以是被接受者120丢弃或在线上丢失的消息。传输中消息125还可以是接受者120已接收到，但其确认或被丢失或在下述计算之前，正在向发起者105运送中的消息。另一种可能性是传输中消息125可能在网络中的中间方(例如，路由器或SOAP中间方)被延迟。
无论如何，一知道传输中消息125的个数，发起者105即可利用窗口大小计算模块110，在计算消息窗口大小155时，从可用接受者缓冲区大小减去传输中消息125的个数。如前所述，消息窗口大小155表示为避免由于缓冲区过速而重新发送消息，可向接受者120发送的消息个数的上限。
注意，基础结构消息115内的缓冲区大小信息通常是以消息而不是字节为单位。类似地，消息窗口大小155还可用若干消息为单位，而不是特定字节大小。此外，因为发起者105跟踪其所发送的消息(例如，传输中消息125)个数以及接受者120的存储器130中可用空间的数量，所以发起者总是知道在接受者120方有多少空间可用。因此，发起者105并不试图估算处理应用程序135的消息处理速率，而是依靠接受者120告诉它接受者可缓冲多少消息。这使窗口大小计算模块110在任何处理速率(诸如恒定速率处理或随机突发处理)下都可工作。
其它示例性实施例解决因基础结构消息115(例如，确认响应消息)不可靠(即，可能在从接受者向发起者运送途中丢失)而产生的问题。在这些实施例中，以及将在以下更详细描述的是，根据特定RM-WS协议，当消息窗口大小155等于0时，发起者105可通过发送例如确认请求消息，来周期性地试探可用空间。响应于确认请求消息，对应的确认响应通常会包括当前接受者缓冲区大小的信息。
注意，在消息窗口大小155的计算中，窗口大小计算模块110可利用除了缓冲区大小信息和传输中消息125个数以外的其它信息。例如，当基础结构消息115是确认响应消息时，还可使用当前正被确认的消息个数来减小消息窗口大小155。此外，在批确认的情形中，可能还需要使用先前接收到的确认响应的个数、
根据示例性实施例，以下是可用来计算消息窗口大小155的一种算法的示例。在发起者105和接受者120之间的通信开始时，假设接收的窗口大小等于1，且传输中消息的个数等于0。此外，先前接收到的确认也被设为0。在发起者105一方，该算法如下。如果消息窗口大小155大于0，则发起者105可发送一个消息；传输中消息计数递增1；以及消息窗口大小155递减1。
另一方面，如果接收的窗口大小等于0，示例性实施例阻塞消息发送，直至重新计算的窗口大小大于0。当窗口大小大于0时，前述过程被重复。
一接收到确认响应或基础结构消息115，该示例性算法即执行以下步骤。首先，它将从消息115中提取接受者缓冲区大小信息。此外，窗口大小计算模块110计算当前正被确认的消息的个数。同时计算模块110需要确定新确认的个数，它等于当前正被确认的消息减去先前接收到的确认。注意，对于RM-WS协议批处理确认响应的实例而言，此最后一个计算可能是需要的；但是，本发明不限于此类批处理过程。因此，只是为说明性目的而取先前接收到的确认个数和当前正被确认的消息之差来计算新确认的个数，且不意味着限制或者缩小本发明的范围，除非所附权利要求书中明确声明。
但是，如果使用新确认的个数，则传输中消息125包括先前被发送的消息个数减去新确认的个数。此外，先前接收到的确认的个数变为等于当前正被确认的消息(又是在批确认的情形中)。最后，消息窗口大小155变为等于接受者缓冲区大小信息减去使用窗口大小计算模块110计算所得的传输中消息125的个数。
以下实例示出上述消息窗口大小跟踪过程。在此例中，发起者105向接受者120发送10个消息，并刚刚接收到对该10个消息的1个确认115，该确认包括指示接受者120能缓冲5个消息的接受者缓冲区大小信息。发起者105发送消息11到15，并停止发送更多的消息。接下来，发起者105接收到对消息1到13的确认，以及接受者120的接收存储器130中有5个空间可用的接受者缓冲区大小信息。知道对于接受者120而言有两个消息是传输中消息125，发起者105将仅向接受者再发送3个消息，然后等待更多空间变为可用。
另一个示例性实施例在每连接的基础上，有利地提供可动态配置的存储器130缓冲区大小。此特征解决系统资源平衡的问题，从而可通过为具有很高(或很低)缓冲区需求的发起者105适当地分配存储器130，来为每个连接最优地实现流量。和为在接收方缓冲消息而进行硬编码存储器分配的TCP不同，示例性实施例允许可基于诸如发起者105的处理速度、请求的复杂程度等因素来配置接受者120的存储器130容量(即，为连接分配的总缓冲区大小)。
例如，已建立的到仅周期性地发送一个消息的发起者105的连接不会需要大量存储器130用于缓冲消息185。因此，发起者105和接受者120之间可发生协商，以确定发起者105的特定需求，以及相应的存储器130的分配。此外，可为每个已建立的连接发生此协商过程，以在各个分布式设备之间恰当地平衡存储器130资源。
其它示例性实施例还通过调整用于向一端点发送消息的传输窗口和/或重试时间周期来提供拥塞控制，以适应于诸如网络带宽、性能和拓扑结构中的变化等因素。该机制涉及测量从消息被发送的时间点到对应确认被接收到的时间所过去的往返时间。以下是拥塞控制过程如何工作的示例的简述。
首先，示例性实施例主动寻求接近期望或最优速率的近似速率。本发明通过例如指数增长传输中消息个数直至找到失败点来完成此项工作。失败点下最后一个成功的速率是最接近最优点的已知点。示例性实施例随即重置并重试(例如，使用指数速率增长)将速率提高回最后的已知好点，并使用逼近最优速率的算法来从该处起进行微调。
图1B示出用于实现上述实施例中的一些实施例的网络100。如图所示，发起者105可向接受者120发送第一若干消息175。当接受者120接收到第一若干消息175，第一确认响应165被发送到发起者105。一接收到该第一确认响应165，即可利用消息传输时间比较模块140来确定应如何调整消息窗口大小155和/或是否应当调整重试时间周期(更快或更慢)。
例如，消息传输时间比较模块140确定期望消息传输时间，它定义在发送定义若干消息175和在发起者105处接收对应的第一确认响应165之间的期望时间限制。换言之，由从发送消息175到接受者120到在发起者105处接收对应确认165的期望往返时间定义期望消息传输时间。如以下将会详细讨论，通常期望消息传输时间是基于消息窗口大小155，后者表示在一根网线上向接受者发送的传输中消息的个数的上限。
消息传输时间比较模块140一确定期望消息传输时间，它即将期望消息传输时间与将第一若干消息175发送到接受者120和接收回第一确认响应165所用的实际时间相比较。如果第一确认响应在期望消息传输时间到期之前被接收到，则消息传输时间比较模块140将给消息窗口大小调整模块145成功指示。由此，消息窗口大小调整模块145将增加消息窗口大小155，并将该次成功作为最后的已知好值180记录在存储器150中。换言之，前一消息窗口大小155作为最后的已知好值180被记录，且按某个因子增加前一消息窗口大小155(通常是指数增长)。然后对应于已增加的消息窗口大小155的第二若干消息170被发送到接受者120，并接收到对第二若干消息170的(一个或多个)第二确认响应160，该过程继续进行直至失败发生。
另一方面，如果在接收第一确认响应165(或在170的情形中应为第二确认响应)之前期望消息传输时间到期，则消息传输时间比较模块140将给消息窗口调整模块145失败指示。注意，在该实例中，失败指示可能示意已经发生了若干次。例如，所发送的消息(第一若干消息175或已增加的第二若干消息170)可能已被丢失。替换地，或者结合地，所发送消息175、170的一个或多个对应的确认消息165、160可能已被丢失或在期望消息传输时间到期之后才被接收到。
无论如何，消息窗口大小调整模块145将减少消息窗口大小155，通常减到存储在存储器150中的最后已知好值180以下的某个值，和/或加长重试时间周期(即，使等待重试消息的时间更长)。注意，尽管示例性实施例将消息窗口大小155减至最后已知好值180以下的某个值，但是本发明不限于此特定实施例。例如，消息窗口大小调整模块145可增量地减少消息窗口大小155，直至达到成功，而该成功值可能是也可能不是最后已知好值180。类似地，上述在接收到成功指示时增加消息窗口大小155不必是指数增长，而也可以是其少量递增。实际上，如以下将会更详细描述的，可使用不同的调整消息窗口大小155的算法来进行微调或实现其它目的。由此，基于成功或失败指示的对窗口大小155的任何增加或减少都仅是为说明性目的而使用的，且不意味着限制或缩小本发明的范围，除非所附权利要求书中明确声明。
但是，当在消息窗口大小调整模块145处接收到失败通知时，若干示例性实施例规定消息窗口大小155将缩小到大小为1。此后，传输消息175、170的成功尝试将把消息窗口大小155指数增长到最后已知好值180。注意，消息窗口大小155的急剧减少引起传输速率降低，从而有效地将指数增长过程重置到其初始状态。但是发起者105用来发送消息的实际缓冲区大小不缩小，且已被缓冲用于发送的消息可不从缓冲区中被移除，但基础结构可能不接收任何新消息(即，发送操作被阻塞)，从而有效地令发起者105降速。缓冲区中的消息数量一降至有效消息窗口大小155以下，新消息即可被基础结构接受。
在上述重置之后，进行重新发送发起者105中最老的消息的尝试，并设置新的期望消息传输时间。如果在接收到对所重新发送的消息的对应确认之前，新的期望消息传输时间到期，则示例性实施例提供期望消息传输时间的加倍以及重试。此过程可重复发生，直至到达成功状态，或已进行了可配置次数的尝试，在后一种情形中，可声明该此传输不成功，并向发起者105应用程序发出错误。此实施例有效地实现一种消息后退重试机制，该机制解决网络100上的拥塞问题，以使其正常化或到达稳定状态。
一接受到成功传输，可如上述再次尝试增加消息窗口大小155和消息传输速率。如前文所提及，为应用在上一次尝试期间所习得的信息，若干示例性实施例规定将消息窗口大小155增加至最后已知好值180。在此点处，消息窗口大小调整模块145改变算法来试探和寻找最优点。例如，一些实施例规定逼近算法(以及消息窗口大小155的机会增加)如下。当达到消息窗口大小的最后已知好值180时，为试图猜测最优点，消息窗口大小调整模块145可通过将差值除以某个因子来选择最后失败消息窗口大小155和最后已知好值180之间的一个点。如果该值过高(即，它超过了最优速率并引起消息丢失或过度延迟)，则消息窗口大小调整模块145将该因子重新调整为较小的值。
当然，还有可用于微调或调整消息窗口大小155的其它具体实现或算法。例如，在到达最后已知好值180以后，消息窗口大小调整模块145可简单地递增消息窗口大小155，直至达到最优大小。由此，如前所述，使用任何特定算法来主动逼近最优消息大小155或微调消息窗口大小155都只是为说明性目的，且不意味着限制或者缩小本发明的范围，除非所附权利要求书中明确声明。
一确定了最优消息窗口大小155，其它示例性实施例还规定周期性地尝试增加最优值，来为带宽增加进行调整。其它示例性实施例规定检测何时发生指示网络100上的带宽减少的失败。在该情形中，消息窗口大小155可被重置，上述增长过程可被增加到最后已知好值180，微调过程可再次被执行。注意，在该情形中最后已知好值180失败，若干示例性实施例规定确定前一个最后已知好值180，即恰好在最后已知好值之前的已知好值。然后可用此前一个值来取代最后已知好值180，上述过程可继续进行。
如以上所提及的，为了检测失败，若干示例性实施例测量传输时间，即，从发送消息到接受对该消息的确认所花的时间。在RS-WS协议允许由接受者120聚合确认响应，以使单个确认响应确认多个消息的接收的某些实例中，此问题变得复杂。因此，示例性实施例跟踪传输每个对应于消息窗口大小155的消息所花的时间，直至接收到对应的批确认。然后使用往返时间的聚合分布的均值和/或方差来计算实际的传输时间。
因为往返时间的方差将取决于批中所确认的消息个数，所以期望消息传输时间应基于消息窗口大小155而改变。换言之，期望消息传输时间通常随着消息窗口大小155的增加而增加。但是，注意，在例如实现发送消息和接收对该消息的确认之间的一一对应的情形中，期望消息传输时间不一定需要基于消息窗口大小155。由此，令期望消息传输时间基于消息窗口大小155仅是为说明性目的而使用，且不意味着限制或者缩小本发明的范围，除非所附权利要求书中明确声明。
以下例子示出上述的各个实施例。在此例中，消息窗口大小155可用大小为1的窗口来启动，即，从发起者105到接受者120仅可有一个消息是传输中的。因此，第一号消息可被接受者120接收，对应的第一号确认消息可被发起者105接收。消息传输时间比较模块140随即测量往返时间，并将其与对应该特定消息窗口大小155的期望消息传输时间相比较。假设对该比较给出成功，则消息窗口大小调整模块145将消息窗口大小155增加到2，其中第二和第三号消息被发送，而对这些消息的确认被发起者105接收。再次假设成功的传输时间，则消息窗口大小调整模块145将把消息窗口大小155增加到4，其中第四到第七号消息被发送，而对应的确认被接收。此过程继续进行，直至检测到失败。
如果下一次将消息窗口大小155增加到8引起失败，则该算法被重新启动，并主动地增加到最后已知好值180，在此实例中为4。随后使用逼近算法，令初始值等于最后已知好值180加某个δ、或者最后已知好值180(即，4)与失败点(即，8)之间的差值除以某个因子。例如，如果该因子为2，那么消息窗口大小155变为6(即，4+(8-4)/2＝6)。假设值6失败，那么该过程尝试根据消息大小为5的消息窗口大小155来发送消息，其中如果成功则5是最优选择，如果失败则4是最优选择。
还可用包括功能性步骤和/或非功能性动作的方法的形式来描述本发明。以下是对在实现本发明中可执行的步骤和/或动作的描述。通常，功能性步骤以所实现的结果的形式来描述本发明，而非功能性动作描述用于实现特定结果的更具体的动作。尽管能以特定次序来描述或在所附权利要求书中声明功能性步骤和/或非功能性动作，但是本发明不必限于任何特定次序，或者步骤和/或动作的组合。此外，在所附权利要求书的陈述中，以及在以下对图2和3的流程图的描述中对步骤和/或动作的使用是用来指示所期望的对此类项目的具体使用。
图2和3示出本发明各个示例性实施例的流程图。以下对图2和3的描述偶尔会引用来自图1A和1B的对应元素。尽管可能会引用来自这些附图的特定元素，但是这些元素仅是为说明性目的而使用，并不意味着限制或者缩小本发明的范围，除非所附权利要求书中明确声明。
图2示出方法200的示例性流程图，该方法用于通过基于接受者的可用缓冲区大小动态地确定用于发送消息的消息窗口大小，根据RM-WS协议在端点之间高效传输消息。方法200包括建立205序列会话的动作。例如，如图1A中所示，可根据RM-WS协议(例如，WSReliableMessaging)，在发起者105和接受者120之间建立应用层(例如，SOAP层)处的序列会话。方法200还包括通过序列会话接收210RM-WS消息的动作。例如，发起者105可从接受者120接收包括接受者缓冲区大小信息的消息115，该信息指示用于缓冲等待应用程序135处理的消息185的可用存储器130的量。通常，消息儿5会是基础结构消息，例如，确认响应消息115。
此后，方法200还包括标识215传输中消息的个数的动作。即根据RM-WS协议，发起者105可确定已向接受者发送，但没有接收到对应确认的传输中消息125的个数。基于接受者缓冲区大小信息和传输中消息的个数，方法200还包括计算225消息窗口大小的动作。例如，可使用窗口大小计算模块110，基于基础结构消息115内的接受者缓冲区大小信息和传输中消息125的个数，来计算消息窗口大小155。消息窗口大小155表示为避免由于接受者120上的缓冲区过速而重新发送消息，而能向接受者发送的消息个数的上限。
若干示例性实施例规定如果窗口大小大于0，则可向接受者120发送对应于计算所得的消息窗口大小155的若干个消息。另一方面，如果消息窗口大小155是0，则若干示例性实施例规定阻塞消息禁止其被发送，直至接收到基础结构消息(或其它消息)并使用该消息计算出消息窗口大小155大于0。根据RM-WS协议，在基础结构是确认响应消息115的情况下，其它示例性实施例规定向接受者120周期性地发送确认请求消息。响应于此，可接收到包括用于重新计算消息窗口大小155的接受者缓冲区大小信息的确认响应消息115。由此，当重新计算所得的消息窗口大小155大于0时，对应于重新计算所得的消息窗口大小155的若干消息可被发送。
如前文所提及，缓冲区信息可以是要被发送的消息的个数，而不是存储器中可用字节数的形式。此外，若干示例性实施例规定，接受者为缓冲等待应用程序处理的消息所分配的总存储器在每连接的基础上是可动态配置的。此外，对消息窗口大小155的计算还可基于确认消息中所确认的消息的个数和/或为先前所发送的消息接收到的先前的确认。
图3示出方法300的示例性流程图，该方法根据RM-WS协议，通过调整用于向端点发送消息的传输窗口来控制网络拥塞，以适应诸如网络带宽、性能和拓扑结构中的变化等因素。方法300包括发送305第一若干消息的动作。例如，如图1B中所示，根据RM-WS协议(例如，WSReliableMessaging)，发起者105可通过已建立的序列会话向接受者120发送第一若干消息175。第一若干消息175对应于消息窗口大小155，其中消息窗口大小155表示在一根网线上向接受者120发送的传输中消息的上限。
方法300还包括调整320消息窗口大小的步骤。步骤320包括标识310期望消息传输时间的动作。例如，可使用消息传输时间比较模块140来标识期望消息传输时间，它定义发送若干消息和接收对应确认消息之间的期望时间限制。步骤320还包括提供315关于是否接收到对应确认消息的指示的动作。例如，消息传输时间比较模块140可向消息大小调整模块145提供在期望消息传输时间到期之前是否接收到对应确认消息165的指示。然后消息窗口大小调整模块145可将此指示用于调整消息窗口大小155和/或重试时间周期，以避免由于网络拥塞而重新发送消息。
其它示例性实施例规定对消息窗口大小155的调整是指示在期望消息传输时间到期之前已接收到对应确认消息165的消息窗口大小155的增加。在消息窗口大小155增加以后，其它示例性实施例规定发送对应于已增加的消息窗口大小155的已增加个数的消息。例如，可从发起者105向接受者120发送第二若干消息175，其中基于已增加的消息窗口大小155，消息传输时间比较模块140可标识第二期望消息传输时间。已增加的期望消息传输时间定义发送已增加个数的消息170和接收一个或多个对应的确认消息160之间的期望时间限制。
此后，消息传输时间比较模块140可提供关于是否在第二期望消息传输时间到期之前接收到对应于已增加个数的消息170的一个或多个对应的确认消息160的指示(注意：由于所发送消息的个数的增加，第二期望消息传输时间通常比先前的值有所增加)。在一个实施例中，消息窗口大小调整模块减少已增加消息窗口大小以指示以下各种情况中的至少一种：已增加个数的消息170中的一个或多个被丢失；对应于已增加个数的消息170的对应的确认消息160中的一个或多个被丢失，和/或在第二期望消息传输时间到期之后才被接收到。已增加消息窗口大小可减少到消息窗口大小和已增加消息窗口大小之间的某个大小。
在另一个示例性实施例中，消息窗口大小155被视为最后已知好值180，并被存储在存储器150中，且其中已增加消息窗口大小155的减小量小于消息窗口大小155，这导致减小的消息窗口大小155。又一个示例性实施例规定发送对应于已减小消息窗口大小155的已减少个数的消息。基于已减小消息窗口大小155，标识出第二期望消息传输时间(注意：尽管所发送的消息个数减少，但第二期望消息传输时间可能比先前的期望消息传输时间有所增长以补偿网络拥塞)，它定义发送已减少个数的消息和接收对应的确认消息之间的期望时间限制。此后，可提供在第二期望消息传输时间到期之前接收到对应于已减少个数的消息的一个或多个对应的确认消息的指示。同样，可从存储器150中检索出消息窗口大小155的大小(即，最后已知好值180)，然后将已减小的消息窗口大小155增加到消息窗口大小155。
此后，若干示例性实施例规定通过消息窗口大小155的单调整(即，递增和递减)来微调消息窗口大小155。其它示例性实施例规定将消息窗口大小155视为最后已知好值，且已增加消息窗口大小的减小是消息窗口大小155。
其它示例性实施例规定对应的若干确认消息可被批处理为单个消息。在该实例中，期望消息传输时间是基于发送若干消息和接收单个消息之间的期望消息传输时间的均值和/或方差。
在本发明范围之内的实施例还包括用于携带或其上存储计算机可执行指令或数据结构的计算机可读介质。此类计算机可读介质可以是可由通用或专用计算机访问的任何可用介质。作为示例，而非限制，此类计算机可读机制可包括RAM、ROM、EEPROM、CD-ROM或其它光盘存储，磁盘存储或其它磁存储设备，或可用来携带或存储可由通用或专用计算机访问的计算机可执行指令或数据结构形式的所需程序代码手段的任何其它介质。当通过网络或其它通信连接(有线的、无线的、或有线和无线的组合)向计算机传输或提供信息时，该计算机适当地将该连接视为计算机可读介质。因此，任何此类连接都被适当地称为计算机可读介质。以上的各种组合也应被包括在计算机可读介质的范围之内。计算机可执行指令包括，例如可令通用计算机、专用计算机、或专用处理设备执行某个或某组功能的指令和数据。
图4和以下讨论旨在提供对可在其中实现本发明的合适的计算环境的简要、一般的描述。尽管不是必须，但将在由网络环境中的计算机执行的诸如程序模块等计算机可执行指令的通用上下文中描述本发明。一般而言，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。计算机可执行指令、相关联的数据结构、和程序模块表示用于执行本文中所揭示的方法的步骤的程序代码手段。这些可执行指令或相关联数据结构的特定顺序表示用于实现这些步骤中所描述的功能的对应动作的示例。
本领域技术人员将能理解，本发明可在具有许多类型的计算机系统配置的网络计算环境中实施，这些类型包括个人计算机、手持式设备、微处理器系统、基于微处理器的或可编程的消费者电子设备、网络PC、小型计算机、大型计算机、等等。本发明还可在分布式计算环境中实施，其中任务是由通过通信网络链接(通过有线链接、无线链接、或有线和无线链接的结合)的若干远程处理设备来执行的。在分布式计算环境中，程序模块既可位于本地记忆存储设备中，也可位于远程记忆存储设备中。
参考图4，用于实现本发明的一种示例性系统包括常规计算机420形式的通用计算设备，它包括处理单元421、系统存储器422、和将包括系统存储器422在内的各种系统组件耦合到处理器单元421的系统总线423。系统总线423可以是若干类型总线结构中的任何一种，包括存储器总线或存储器控制器、外围总线、和使用各种总线体系结构中的任何一种的总线。系统存储器包括只读存储器(ROM)424和随机存取存储器(RAM)425。包含诸如在启动时帮助在计算机420内部的各元件之间传输信息的基本例程的基本输入/输出系统(BIOS)426可被存储在ROM 424中。
计算机420还可包括用于读或写硬磁盘439的硬磁盘驱动器427、用于读或写可移动磁盘429的磁盘驱动器428、和用于读或写诸如CD-ROM或其它光介质等可移动光盘的光盘驱动器430。硬磁盘驱动器427、磁盘驱动器428和光盘驱动器430分别通过硬盘驱动器接口432、磁盘驱动器接口433和光盘驱动器接口434链接到系统总线423。各驱动器及其相关联的计算机可读介质为计算机420提供计算机可执行指令、数据结构、程序模块及其它数据的非易失性存储。尽管本文中所描述的示例性环境使用硬磁盘439、可移动磁盘429和可移动光盘431，用于存储数据的其它类型的计算机可读介质也可被使用，包括磁带盒、闪存卡、数字多功能盘、贝努利盒式磁带、RAM、ROM、等等。
包括一个或多个程序模块的程序代码手段可存储在硬盘439、磁盘429、光盘431、ROM 424或RAM 425上，包括操作系统435、一个或多个应用程序436、其它程序模块437和程序数据438。用户可通过键盘440、定位设备442或诸如话筒、操纵杆、圆盘式卫星天线、扫描仪等其它输入设备(未示出)将命令和信息输入到计算机420中。这些及其它输入设备常常通过耦合到系统总线423的串行端口接口446连接到处理单元421。或者，输入设备可通过诸如并行端口、游戏端口或通用串行总线(USB)等其它接口来连接。监视器447或其它显示设备也经由诸如视频适配器448等接口连接到系统总线423。除了监视器以外，个人计算机通常包括诸如扬声器和打印机等其它外围输出设备(未示出)。
计算机420可使用到诸如远程计算机449a和449b等一个或多个远程计算机的逻辑连接在联网环境中工作。远程计算机449a和449b每一个都可以是另一个人计算机、服务器、路由器、网络PC、对等设备或其它普通网络节点，并通常包括以上相对于计算机420所描述的许多或所有元件，尽管在图4中仅示出记忆存储设备450a和450b及其相关联的应用程序436a和436b。图4中所描绘的逻辑连接包括此处作为示例而非限制所呈现的局域网(LAN)451和广域网(WAN)452。这些网络环境常见于办公室范围或企业范围的计算机网络、内联网和互联网。
当在LAN网络环境中使用时，计算机420通过网络接口或适配器453连接到网络451。当在WAN网络环境中使用时，计算机420可包括调制解调器454、无线链路、或用于通过诸如因特网等广域网452建立通信的其它装置。可以是内置或外置的调制解调器454经由串行端口接口446连接到系统总线423。在联网环境中，相对于计算机420所描述的程序模块或其部分可存储在远程记忆存储设备中。可以理解，所示网络连接是示例性的，且可使用通过广域网452建立通信的其它装置。
本发明能以其它具体形式具体化，而不会偏离本发明的精神和本质特征。在任何意义上，所描述的实施例都仅应被视为示例性的，而非限制性的。因此，本发明的范围是由所附权利要求书指示，而非由前述描述所指示。落入所附权利要求书的等效方案意义和范围之内的所有改变应被包括在所附权利要求书的范围之内。

Claims (42)

1.在Web服务(WS)环境内的计算系统中，一种通过基于接受者的可用缓冲区大小动态地确定用于发送消息的消息窗口大小来根据WS的可靠消息通信(RM-WS)协议在端点之间高效地传输所述消息的方法，所述方法包括以下动作：
根据RM-WS协议，在应用层处建立发起者和接受者之间的序列会话；
通过所述序列会话接收包括接受者缓冲区大小信息的消息，所述信息指示用于缓冲等待应用程序处理的消息的可用存储器的量；
根据所述RM-WS协议标识已向所述接受者发送但没有接收到对应确认的传输中消息的个数；以及
使用所述接受者缓冲区大小信息和所述传输中消息的个数来计算消息窗口大小，所述消息窗口大小表示为避免由于缓冲区过速而重新发送消息而能向所述接受者发送的消息个数的上限。
2.如权利要求1所述的方法，其特征在于，包括接受者缓冲区大小信息的所述消息是RM-WS协议基础结构消息。
3.如权利要求2所述的方法，其特征在于，为缓冲等待应用程序处理的消息所分配的接受者总存储器在每一连接的基础上是可动态配置的。
4.如权利要求2所述的方法，其特征在于，基于所述消息窗口大小大于0，所述方法还包括以下动作：
发送对应于计算所得的消息窗口大小的若干消息。
5.如权利要求2所述的方法，其特征在于，基于所述消息窗口大小等于0，所述方法还包括以下动作：
阻断所述消息的发送，直至一基础结构消息被用来计算所述消息窗口大小大于0。
6.如权利要求5所述的方法，其特征在于，所述基础结构消息是根据所述RM-WS协议的确认响应消息，所述方法还包括以下动作：
向所述接受者周期性地发送确认请求消息；以及
接收包括用于重新计算所述消息窗口大小的接受者缓冲区大小信息的一个或多个确认响应消息；以及
当重新计算所得的消息窗口大小大于0时，发送对应于所述重新计算所得的消息窗口大小的若干消息。
7.如权利要求2所述的方法，其特征在于，所述缓冲区信息是能被发送的消息个数的形式，而不是存储器中可用字节数的形式。
8.如权利要求2所述的方法，其特征在于，所述RM-WS协议是WSReliableMessaging。
9.如权利要求2所述的方法，其特征在于，所述基础结构消息是确认消息，所述确认消息确认对先前所发送的一个或多个消息的接收。
10.如权利要求9所述的方法，其特征在于，所述对消息窗口大小的计算还基于在所述确认消息中确认的消息的个数。
11.如权利要求10所述的方法，其特征在于，所述对消息窗口大小的计算还基于对一个或多个先前所发送的消息的先前所接收到的确认的个数。
12.在Web服务(WS)环境中的计算系统中，一种根据WS的可靠消息通信(RM-WS)协议通过调整用于向端点发送消息的传输窗口来控制网络拥塞，以适应诸如网络带宽、性能和拓扑结构中的变化等因素的方法，所述方法包括以下动作：
根据RM-WS协议，通过已建立的序列会话向接受者发送对应于消息窗口大小的若干消息，其中，所述消息窗口大小表示在网线上向所述接受者发送的传输中消息个数的上限；
基于所述消息窗口大小，标识期望消息传输时间，所述期望消息传输时间定义在发送所述若干消息和接收一个或多个对应的确认消息之间的期望时间限制；
提供关于在所述期望消息传输时间到期之前是否接收到所述一个或多个对应的确认消息的指示，所述指示用于调整所述消息窗口大小或消息重试时间周期中的至少一个，以避免由于网络拥塞而重新发送消息。
13.如权利要求12所述的方法，其特征在于，所述调整是所述消息窗口大小的增加，以指示在所述期望消息传输时间到期之前已接收到所述一个或多个对应的确认消息。
14.如权利要求13所述的方法，其特征在于，在所述消息窗口大小增加以后，所述方法还包括以下动作：
发送对应于所述已增加的消息窗口大小的已增加个数的消息；
基于所述已增加的消息窗口大小，标识第二期望消息传输时间，所述第二期望消息传输时间定义在发送所述已增加个数的消息和接收一个或多个对应的确认消息之间的期望时间限制；
提供关于在所述第二期望消息传输时间到期之前是否接收到对应于所述已增加个数的消息的所述一个或多个对应的确认消息的指示；以及
减少所述已增加的消息窗口大小，以指示以下各种情况中的至少一种，所述已增加个数的消息中的一个或多个被丢失，或者对所述已增加个数的消息的所述一个或多个对应的确认消息中的一个或多个被丢失或在所述第二期望消息传输时间到期之后才被接收到。
15.如权利要求14所述的方法，其特征在于，所述消息窗口大小被视为最后一个已知好值并被存储在存储器中，且其中，所述已增加的消息窗口大小的减小量低于所述消息窗口大小，从而得到已减小的消息窗口大小。
16.如权利要求15所述的方法，其特征在于，还包括以下动作：
发送对应于所述已减小的消息窗口大小的已减少个数的消息；
基于所述已减小的消息窗口大小，标识第二期望消息传输时间，所述第二期望消息传输时间定义在发送所述已减少个数的消息和接收一个或多个对应的确认消息之间的期望时间限制；
提供关于在所述第二期望消息传输时间到期之前已接收到对所述已减少个数的消息的所述一个或多个对应的确认消息的指示；
从存储器中检索所述消息窗口大小；以及
将所述已减小的消息窗口大小增加到所述消息窗口大小。
17.如权利要求16所述的方法，其特征在于，所述消息窗口大小是通过消息窗口大小调整的单增和单减来微调的。
18.如权利要求14所述的方法，其特征在于，所述消息窗口大小被视为所述最后一个已知好值，且其中，所述已增加消息窗口大小的减小量是所述消息窗口大小。
19.如权利要求14所述的方法，其特征在于，所述已增加消息窗口大小的减小量是所述消息窗口大小和所述已增加消息窗口大小之间的一个大小。
20.如权利要求12所述的方法，其特征在于，所述一个或多个对应的确认消息被批处理成单个消息。
21.如权利要求20所述的方法，其特征在于，所述期望消息传输时间是基于在发送所述若干消息和接收所述单个消息之间的期望时间限制的均值或方差时间。
22.在Web服务(WS)环境中的计算系统中，一种根据WS的可靠消息通信(RM-WS)协议通过调整用于向端点发送消息的传输窗口来控制网络网络拥塞，以适应诸如网络带宽、性能和拓扑结构中的变化等因素的方法，所述方法包括：
根据RM-WS协议，通过已建立的序列会话向接受者发送对应于第一消息窗口大小的第一若干消息的动作，其中，消息窗口大小表示在网线上向所述接受者发送的传输中消息的个数的上限；
用于将所述第一消息窗口大小调整到第二消息窗口大小，以避免由于网络拥塞而重新发送消息的步骤，所述调整是基于是否在第一期望消息传输时间到期之前接收到对所述第一若干消息的一个或多个确认消息，所述第一期望消息传输时间定义在发送所述第一若干消息和接收一个或多个对应的第一确认消息之间的期望时间限制。
23.如权利要求22所述的方法，其特征在于，所述期望消息传输时间是基于所述消息窗口大小。
24.如权利要求12所述的方法，其特征在于，对所述消息窗口大小的调整是所述消息窗口大小的增加，以指示在所述期望消息传输时间到期之前已接收到所述一个或多个对应的确认消息。
25.在Web服务(WS)环境中的计算系统中，一种用于实现一种方法的计算机程序产品，所述方法通过基于接受者的可用缓冲器大小动态地确定用于发送消息的消息窗口大小，根据WS的可靠消息通信(RM-WS)协议在端点之间高效地传输消息，所述计算机程序产品包括其上存储计算机可执行指令的一个或多个计算机可读介质，当所述可执行指令由处理器执行时，能令所述消息通信系统执行以下动作：
根据RM-WS协议，在应用层处建立发起者和接受者之间的序列会话；
通过所述序列会话接收包括接受者缓冲区大小信息的消息，所述信息指示用于缓冲等待应用程序处理的消息的可用存储器的量；
根据所述RM-WS协议，标识已向所述接受者发送但没有接收到对应确认的传输中消息的个数；以及
使用所述接受者缓冲区大小信息和所述传输中消息的个数来计算消息窗口大小，所述消息窗口大小表示为避免由于缓冲区过速而重新发送消息而能向所述接受者发送的消息个数的上限。
26.如权利要求25所述的计算机程序产品，其特征在于，包括所述接受者缓冲区大小信息的所述消息是RM-WS协议基础结构消息。
27.如权利要求26所述的计算机程序产品，其特征在于，所述为缓冲等待应用程序处理的消息所分配的接受者总存储器在每一连接的基础上是可动态配置的。
28.如权利要求26所述的计算机程序产品，其特征在于，基于所述消息窗口大小大于0，所述计算机程序产品还包括可令所述消息通信系统执行以下动作的计算机可执行指令：
发送对应于计算所得的消息窗口大小的若干消息。
29.如权利要求26所述的计算机程序产品，其特征在于，基于所述消息窗口大小等于0，所述计算机程序产品还包括可令所述消息通信系统执行以下动作的计算机可执行指令：
阻断所述消息的发送，直至一基础结构消息被用来计算所述消息窗口大小大于0。
30.如权利要求29所述的计算机程序产品，其特征在于，所述基础结构消息是根据RM-WS协议的确认响应消息，所述计算机程序产品还包括可令所述消息通信系统执行以下动作的计算机可执行指令：
向所述接受者周期性地发送确认请求消息；以及
接收包括用于重新计算所述消息窗口大小的接受者缓冲区大小信息的一个或多个确认响应消息；以及
当重新计算所得的消息窗口大小大于0时，发送对应于所述重新计算所得的消息窗口大小的若干消息。
31.如权利要求26所述的计算机程序产品，其特征在于，所述缓冲区信息是能被发送的消息个数的形式，而不是存储器中可用字节数的形式。
32.如权利要求26所述的计算机程序产品，其特征在于，所述RM-WS协议是WSReliableMessaging。
33.如权利要求26所述的计算机程序产品，其特征在于，所述基础结构消息是确认消息，所述确认消息确认对先前所发送的一个或多个消息的接收。
34.如权利要求33所述的计算机程序产品，其特征在于，所述对消息窗口大小的计算还基于在所述确认消息中被确认的消息的个数。
35.如权利要求34所述的计算机程序产品，其特征在于，所述对消息窗口大小的计算还基于对一个或多个先前所发送的消息的先前所接收到的确认的个数。
36.在Web服务(WS)环境中的计算系统中，一种用于实现一种方法的计算机程序产品，所述方法根据WS的可靠消息通信(RM-WS)协议通过调整用于向端点发送消息的传输窗口来控制网络拥塞，以适应诸如网络带宽、性能和拓扑结构中的变化等因素，所述计算机程序产品包括其上存储计算机可执行指令的一个或多个计算机可读介质，当所述可执行指令由处理器执行时，能令所述消息通信系统执行以下动作：
根据RM-WS协议，通过已建立的序列会话向接受者发送对应于消息窗口大小的若干消息，其中，所述消息窗口大小表示在网线上向所述接受者发送的传输中消息个数的上限；
基于所述消息窗口大小，标识期望消息传输时间，所述期望消息传输时间定义发送在所述若干消息和接收一个或多个对应的确认消息之间的期望时间限制；
提供关于在所述期望消息传输时间到期之前是否接收到所述一个或多个对应的确认消息的指示，所述指示用于调整所述消息窗口大小或消息重试时间周期中的至少一个，以避免由于网络拥塞而重新发送消息。
37.如权利要求36所述的计算机程序产品，其特征在于，所述调整是所述消息窗口大小的增加，以指示在所述期望消息传输时间到期之前已接收到所述一个或多个对应的确认消息。
38.如权利要求37所述的计算机程序产品，其特征在于，在所述消息窗口大小增加以后，所述计算机程序产品还包括可令所述消息通信系统执行以下动作的计算机可执行指令：
发送对应于所述已增加的消息窗口大小的已增加个数的消息；
基于所述已增加的消息窗口大小，标识第二期望消息传输时间，所述第二期望消息传输时间定义在发送所述已增加个数的消息和接收一个或多个对应的确认消息之间的期望时间限制；
提供关于在所述第二期望消息传输时间到期之前是否接收到对所述已增加个数的消息的所述一个或多个对应的确认消息的指示；以及
减少所述已增加的消息窗口大小，以指示以下各种情况中的至少一种，所述已增加个数的消息中的一个或多个被丢失，或者对所述已增加个数的消息的所述一个或多个对应的确认消息中的一个或多个被丢失或在所述第二期望消息传输时间到期之后才被接收到。
39.如权利要求38所述的计算机程序产品，其特征在于，所述消息窗口大小被视为最后一个已知好值并被存储在存储器中，且其中，对所述已增加的消息窗口大小的减小量低于所述消息窗口大小，从而得到已减小的消息窗口大小。
40.如权利要求39所述的计算机程序产品，其特征在于，还包括可令所述消息通信系统执行以下动作的计算机可执行指令：
发送对应于已减小的消息窗口大小的已减少个数的消息；
基于所述已减小的消息窗口大小，标识第二期望消息传输时间，所述第二期望消息传输时间定义在发送所述已减少个数的消息和接收一个或多个对应的确认消息之间的期望时间限制；
提供关于在所述第二期望消息传输时间到期之前已接收到对所述已减少个数的消息的所述一个或多个对应的确认消息的指示；
从存储器中检索所述消息窗口大小；以及
将所述已减小的消息窗口大小增加到所述消息窗口大小。
41.如权利要求40所述的计算机程序产品，其特征在于，所述消息窗口大小是通过消息窗口大小调整的单增和单减来微调的。
42.如权利要求38所述的计算机程序产品，其特征在于，所述消息窗口大小被视为所述最后一个已知好值，且所述已增加消息窗口大小的减小量是所述消息窗口大小。
CN2005101188767A 2004-12-03 2005-11-03 使用web服务可靠消息通信协议的高效消息传输 Expired - Fee Related CN1783852B (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US11/003,848 2004-12-03
US11/003,848 US7730196B2 (en) 2004-12-03 2004-12-03 Efficient transfer of messages using reliable messaging protocols for web services

Publications (2)

Publication Number Publication Date
CN1783852A true CN1783852A (zh) 2006-06-07
CN1783852B CN1783852B (zh) 2012-05-16

Family

ID=36061546

Family Applications (1)

Application Number Title Priority Date Filing Date
CN2005101188767A Expired - Fee Related CN1783852B (zh) 2004-12-03 2005-11-03 使用web服务可靠消息通信协议的高效消息传输

Country Status (7)

Country Link
US (1) US7730196B2 (zh)
EP (1) EP1667017B1 (zh)
JP (1) JP4714572B2 (zh)
KR (1) KR101143172B1 (zh)
CN (1) CN1783852B (zh)
AT (1) ATE428972T1 (zh)
DE (1) DE602005013894D1 (zh)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102057686A (zh) * 2008-04-07 2011-05-11 高通股份有限公司 用于传递并缓存多个内容块的方法和装置
CN103888214A (zh) * 2012-12-21 2014-06-25 鸿富锦精密工业（深圳）有限公司 渐进式数据编码传输系统及方法
CN104348711A (zh) * 2013-08-07 2015-02-11 三星Sds株式会社 消息接收装置及方法

Families Citing this family (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7657609B2 (en) * 2005-07-05 2010-02-02 Sap Ag Data transfer in a multi-environment document management system access
US7693138B2 (en) * 2005-07-18 2010-04-06 Broadcom Corporation Method and system for transparent TCP offload with best effort direct placement of incoming traffic
CN100446586C (zh) * 2006-09-30 2008-12-24 江苏天泽信息产业有限公司 短信费用超限预警管理方法
US7773616B2 (en) * 2006-11-08 2010-08-10 Sicortex, Inc. System and method for communicating on a richly connected multi-processor computer system using a pool of buffers for dynamic association with a virtual channel
US7971209B2 (en) 2007-05-18 2011-06-28 Sap Ag Shortcut in reliable communication
US7644129B2 (en) * 2007-06-01 2010-01-05 Sap Ag Persistence of common reliable messaging data
WO2009036361A2 (en) * 2007-09-14 2009-03-19 Softkvm, Llc Software method and system for controlling and observing computer networking devices
JP4516594B2 (ja) * 2007-12-27 2010-08-04 株式会社日立製作所 メッセージ送信制御方法、メッセージ送信制御装置、及びメッセージ送信制御プログラム
US7912975B2 (en) 2008-03-03 2011-03-22 Alcatel Lucent System and method for application layer resource traffic control
JP5285705B2 (ja) * 2008-08-28 2013-09-11 パナソニック株式会社 無線伝送装置、無線伝送方法、プログラム、及び集積回路
US20120147840A1 (en) * 2008-12-31 2012-06-14 Mediatek Inc. Method for boosting downlink transmission to mobile station and system utilizing the same
US8325601B2 (en) * 2009-05-08 2012-12-04 Canon Kabushiki Kaisha Reliable network streaming of a single data stream over multiple physical interfaces
US20110113134A1 (en) 2009-11-09 2011-05-12 International Business Machines Corporation Server Access Processing System
US9071465B1 (en) * 2010-05-18 2015-06-30 Cellco Partnership Method and system for SMS services and bind scaling
WO2012005609A1 (en) * 2010-07-08 2012-01-12 Blade Limited File transfer system
US8452888B2 (en) * 2010-07-22 2013-05-28 International Business Machines Corporation Flow control for reliable message passing
US9590885B1 (en) * 2013-03-13 2017-03-07 Sprint Communications Company L.P. System and method of calculating and reporting of messages expiring from a queue
US9432445B1 (en) 2013-05-17 2016-08-30 Sprint Communications Company L.P. System and method of maintaining an enqueue rate of data messages into a set of queues
JP6039522B2 (ja) * 2013-09-06 2016-12-07 株式会社東芝 外部入出力装置および調停設定結果格納方法
US9749280B2 (en) * 2013-09-20 2017-08-29 Oracle International Corporation Techniques for reliable messaging for an intermediary in a network communication environment
CA2929648A1 (en) * 2013-11-06 2015-05-14 Calgary Scientific, Inc. Apparatus and method for client-side flow control in a remote access environment
EP3320658B1 (en) * 2015-07-10 2018-12-26 Telefonaktiebolaget LM Ericsson (publ) Technique for processing messages in a message-based communication scenario
US11416852B1 (en) * 2017-12-15 2022-08-16 Worldpay, Llc Systems and methods for generating and transmitting electronic transaction account information messages
CN110830182B (zh) * 2018-08-09 2023-08-01 北京三星通信技术研究有限公司 数据重传的方法和装置
US11936638B2 (en) * 2019-06-28 2024-03-19 Salesforce Inc. Link protocol agents for inter-application communications
CN111600927B (zh) * 2020-04-03 2022-12-20 浙江工业大学 一种复杂网络环境下服务自适应调用的方法

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH09214547A (ja) * 1996-01-30 1997-08-15 Nec Eng Ltd パケット通信方式及びそのウィンドウサイズ変更方式
JP2000156706A (ja) * 1998-11-19 2000-06-06 Nippon Telegr & Teleph Corp <Ntt> データ送受信方法並びにデータ送信プログラムを記憶した媒体及びデータ受信プログラムを記憶した媒体
US6438603B1 (en) * 1999-04-30 2002-08-20 Microsoft Corporation Methods and protocol for simultaneous tuning of reliable and non-reliable channels of a single network communication link
EP1428357A1 (en) * 2001-09-21 2004-06-16 British Telecommunications Public Limited Company Data communications method and system using receiving buffer size to calculate transmission rate for congestion control
KR100411447B1 (ko) * 2001-12-26 2003-12-18 엘지전자 주식회사 티씨피 혼잡 제어 방법
US7181531B2 (en) * 2002-04-30 2007-02-20 Microsoft Corporation Method to synchronize and upload an offloaded network stack connection with a network stack
KR100474302B1 (ko) * 2002-09-07 2005-03-10 엘지전자 주식회사 무선 링크 콘트롤(ｒｌｃ) 계층의 버퍼제어 방법
US7676580B2 (en) 2003-03-27 2010-03-09 Microsoft Corporation Message delivery with configurable assurances and features between two endpoints
US7693952B2 (en) 2003-03-27 2010-04-06 Microsoft Corporation Availability and scalability in a messaging system in a manner transparent to the application
ATE491291T1 (de) * 2004-01-30 2010-12-15 Ericsson Telefon Ab L M Paketablaufsteuerung zur datenstromübertragung
CN101069378B (zh) * 2004-08-31 2014-07-23 艾利森电话股份有限公司 数据单元发送器和数据单元中继装置
JP4305364B2 (ja) * 2004-10-25 2009-07-29 日本電気株式会社 Ｗｅｂサービス要求中継システム、Ｗｅｂサービス要求中継方法、中継サーバ、及びそのプログラム

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102057686A (zh) * 2008-04-07 2011-05-11 高通股份有限公司 用于传递并缓存多个内容块的方法和装置
US8499119B2 (en) 2008-04-07 2013-07-30 Qualcomm Incorporated Method and apparatus for delivering and caching multiple pieces of content
CN102057686B (zh) * 2008-04-07 2013-11-06 高通股份有限公司 用于传递并缓存多个内容块的方法和装置
CN103888214A (zh) * 2012-12-21 2014-06-25 鸿富锦精密工业（深圳）有限公司 渐进式数据编码传输系统及方法
CN107181573A (zh) * 2012-12-21 2017-09-19 唐华艺 渐进式数据编码传输系统
CN107395328A (zh) * 2012-12-21 2017-11-24 唐华艺 渐进式数据编码传输方法
CN103888214B (zh) * 2012-12-21 2017-12-15 广东福能大数据产业园建设有限公司 渐进式数据编码传输方法
CN107395328B (zh) * 2012-12-21 2019-12-13 广州众为工程咨询有限公司 渐进式数据编码传输方法
CN104348711A (zh) * 2013-08-07 2015-02-11 三星Sds株式会社 消息接收装置及方法
CN104348711B (zh) * 2013-08-07 2018-07-13 三星Sds株式会社 消息接收装置及方法

Also Published As

Publication number Publication date
JP2006166439A (ja) 2006-06-22
JP4714572B2 (ja) 2011-06-29
EP1667017A1 (en) 2006-06-07
US20060133278A1 (en) 2006-06-22
KR101143172B1 (ko) 2012-05-11
EP1667017B1 (en) 2009-04-15
KR20060063652A (ko) 2006-06-12
US7730196B2 (en) 2010-06-01
DE602005013894D1 (de) 2009-05-28
CN1783852B (zh) 2012-05-16
ATE428972T1 (de) 2009-05-15

Similar Documents

Publication Publication Date Title
CN1783852B (zh) 使用web服务可靠消息通信协议的高效消息传输
EP1670213B1 (en) Verifying and maintaining connection liveliness in a reliable messaging for web services environment
KR100442610B1 (ko) 라디우스 프로토콜의 플로우 제어방법
CN102201977B (zh) 批量数据传输
JP3321043B2 (ja) Ｔｃｐネットワーク内のデータ端末
KR100839267B1 (ko) 확률적 피드백을 이용하여 멀티캐스트 컨텐트의 전달을최적화하기 위한 방법 및 장치
KR101242338B1 (ko) 멀티 스트림 승인 스케쥴링
CN1812405A (zh) 在请求－响应传输协议上的可靠的单向消息传递
WO2000072169A1 (en) Congestion management in distributed computer system
CN116233243A (zh) 一种弱网环境下的通信系统及方法
EP1744495B1 (en) Round trip time estimation
US20070280685A1 (en) Method of Optimising Connection Set-Up Times Between Nodes in a Centrally Controlled Network
CN118555249A (zh) 基于dpu网卡的报文传输方法、dpu网卡、网络设备以及计算机存储介质
Zitterbart et al. Transport service and protocols for high-speed networks

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
C14 Grant of patent or utility model
GR01 Patent grant
CF01 Termination of patent right due to non-payment of annual fee

Granted publication date: 20120516

Termination date: 20141103

EXPY Termination of patent right or utility model