KR101143172B1

KR101143172B1 - 웹 서비스를 위한 신뢰성 있는 메시징 프로토콜을 이용한메시지의 효율적인 전송

Info

Publication number: KR101143172B1
Application number: KR1020050101673A
Authority: KR
Inventors: 리차드 디. 힐; 스테판 알. 배트레스
Original assignee: 마이크로소프트 코포레이션
Priority date: 2004-12-03
Filing date: 2005-10-27
Publication date: 2012-05-11
Also published as: DE602005013894D1; CN1783852B; ATE428972T1; KR20060063652A; US20060133278A1; CN1783852A; EP1667017B1; EP1667017A1; JP4714572B2; JP2006166439A; US7730196B2

Abstract

본 발명은 RM-WS(Reliable Message protocol for Web Services)에 따른 흐름 및 혼잡 제어 메커니즘을 제공한다. 흐름 제어를 위해, 하나의 종단점은 응답 메시지에 버퍼 크기 정보를 포함시켜 그 이용가능한 버퍼 크기를 다른 종단점에 통지한다. 그 후, 통상, RM-WS 기반구조 메시지인, 응답 메시지는, 버퍼 오버런(buffer overrun)으로 인한 메시지 재송신을 방지하기 위해 억셉터에 송신될 수 있는 메시지 수의 상한을 결정하는데 이용된다. 혼잡 제어의 경우, 실시예는, 실패 지점이 발견될 때까지 인 플라이트(in-flight) 메시지 수를 증가시키는 것을 제공한다. 실패 지점 아래의 최종 성공 속도는 최적 지점에 가장 가까운 알려진 지점이다. 그 후, 예시적인 실시예는, 리셋하고, 최종의 알려진 좋은 지점으로 다시 속도를 올리고 최적 속도에 점근하는 알고리듬을 이용하여 그 지점에서부터 미세 조정을 재시도한다.

흐름 제어, 혼잡 제어, 웹 서비스, 버퍼 크기, 윈도 크기

Description

웹 서비스를 위한 신뢰성 있는 메시징 프로토콜을 이용한 메시지의 효율적인 전송{EFFICIENT TRANSFER OF MESSAGES USING RELIABLE MESSAGING PROTOCOLS FOR WEB SERVICES}

도 1A는 본 발명의 예시적인 실시예에 따른 2개의 종단점 간의 흐름 제어 변화를 조정하도록 구성된 컴퓨팅 시스템을 나타낸 도면.

도 1B는 본 발명의 예시적인 실시예에 따른 네트워크 와이어(network wire) 상의 혼잡 변화에 적응하도록 구성된 컴퓨팅 시스템을 나타낸 도면.

도 2는 본 발명의 예시적인 실시예에 따른 종단점 간에서 메시지를 효율적으로 전송하는 방법의 흐름도를 나타낸 도면.

도 3은 본 발명의 예시적인 실시예에 따른 네트워크 혼잡을 제어하는 방법의 흐름도를 나타낸 도면.

도 4는 본 발명에 적합한 동작 환경을 제공하는 예시적인 시스템을 나타낸 도면.

※도면의 주요부분에 대한 부호의 설명※

100 : 분산 네트워크

105 : 이니시에이터

110 : 윈도 크기 계산 모듈

115 : 억셉터 버퍼 크기 정보

120 : 억셉터

125 : 인 플라이트 메시지

130 : 메모리

135 : 애플리케이션

155 : 메시지 윈도 크기

185 : 버퍼링된 메모리

일반적으로, 본 발명은 웹 서비스의 신뢰성 있는 메시징에 관한 것이다. 더욱 상세하게는, 본 발명은, 2개의 종단점 간의 흐름 제어 및 네트워크 와이어 상의 혼잡 제어를 위해 웹 서비스를 위한 신뢰성 있는 메시징 프로토콜에 따른 메시지의 효율적인 전송을 제공한다.

컴퓨터 네트워크는, (이하, "컴퓨팅 장치" 또는 "컴퓨팅 시스템"으로 지칭되는)하나의 컴퓨터 또는 장치가 전자식 메시지를 이용하여 다른 컴퓨팅 시스템과 네트워크 상에서 통신하는 것을 허용함으로써, 정보를 통신하고 접근할 수 있는 우리의 능력을 향상시켰다. 컴퓨팅 시스템 간에서 전자식 메시지를 전송하는 경우, 전자식 메시지는 (예를 들어, 파싱, 라우팅, 흐름 제어 등의)전자식 메시지 내의 데이터 상에서 연산을 수행하는 프로토콜 스택을 종종 통과하게 된다. OSI(Open System Interconnect) 모델은 프로토콜 스택을 구현하는 네트워크 프레임워크의 일 예이다.

OSI 모델은 전자식 메시지를 전송하는 동작을 7개의 다른 계층으로 분류하고, 각각은 데이터 전송 처리에서 특정 동작을 수행하도록 지정된다. 프로토콜 스택이 각각의 계층을 잠재적으로 구현할 수 있으나, 다수의 프로토콜 스택은 네트워크 상에서 데이터를 전송하는데 이용되는 선택적인 계층만을 구현한다. 데이터가 컴퓨팅 시스템으로부터 전송되면, 이 데이터는 애플리케이션 계층에서 발생하여 중간 하위 계층으로 아래로 전달된 후 네트워크 상에 전달된다. 데이터가 네트워크로부터 수신되면, 이 데이터는 물리적 계층에 입력되고 상위 중간 계층으로 위로 전달된 후 결국 그 애플리케이션 계층에서 수신된다. 최상위 계층인 애플리케이션 계층은, 애플리케이션 및 최종 사용자 처리를 지원하는 책임을 진다. 또한, 애플리케이션 계층 내에는 (예를 들어, SOAP(Simple Open Access Protocol) 등의)몇몇의 다른 계층이 상주할 수도 있다. 대부분의 프로토콜 스택에 의해 병합되는 다른 계층은 전송 계층이다. 전송 계층의 일 예는 TCP(Transmission Control Protocol)이다.

WS(Web Services)는, 컴퓨팅 시스템 간의 통신을 진보시킴에 있어서 원동력이 되고 있고, 소프트웨어를 구축하고 이용하는 방법을 완전히 변화시키고 있다. 웹 서비스로 인해, 애플리케이션은, 데이터를 공유할 수 있고, 더욱 강력하게는, 이들 애플리케이션이 어디에서 어떻게 구축되었고, 이들이 어떤 운영 체계나 플랫폼 상에서 실행되며, 이들에 접근하는데 이용되는 장치가 무엇인지에 관계없이 다 른 애플리케이션으로부터 능력을 호출할 수 있게 된다. 웹 서비스는 SOAP, XML(eXtensible Markup Language), UDDI(Universal, Description, Discovery and Integration), WSDL(Web Service Description Language) 등을 포함하는 산업 표준 프로토콜에 의해 인터넷 상에서 호출된다. 웹 서비스가 서로 독립한 상태를 유지하는 경우에도, 이들은 특정 작업을 수행하는 협력 그룹으로서 유연하게 연결될 수 있다.

현재 WS 기술은 (예를 들어, 클라이언트 등의)이니시에이터(initiator)와 (예를 들어, 서비스 등의)억셉터(acceptor) 간의 직접적인 SOAP 메시지 통신을 제공한다. 통상의 양방향 메시징 경우, SOAP 요구 메시지는 이니시에이터로부터 억셉터로 송신되고, 이에 응답하여 SOAP 응답 메시지가 송신된다. 종단점 간의 다른 통신 변형은 단방향 메시지이고, 이니시에이터는 아무런 응답이 없는 억셉터에 메시지를 송신한다.

최근 WS 구조의 중요한 이점은 통합되어 상호 운용가능한 솔루션을 제공할 수 있는 능력이다. 그러나, 웹 서비스가 인터넷 등의 신뢰성 없는 통신 채널을 경유하여 서로 다른 사업, 발생, 및 다른 서비스 제공자로부터 여러 서비스를 제공하기 때문에, WS의 신뢰도가 점점 중요한 요소가 되고 있다. WS의 신뢰도는, 웹 서비스 종단점의 신뢰도, 웹 서비스가 접근되는 통신 채널의 신뢰도 특성, 성능과 장애 허용 특성, 및 웹 서비스가 동시에 발생한 클라이언트 접근을 처리할 수 있는 범위를 포함하는 여러 요인들에 의해 영향을 받으나, 이에 한정되지는 않는다.

(예를 들어, SOAP 메시지 등의)메시지가 종단점 간에서 교환되는 신뢰성 있 는 전송 프로토콜을 선택하여 웹 서비스의 신뢰성 있는 메시징을 달성하려는 시도가 있었다. 예를 들어, 메시지 대기열(queues) 등의 신뢰성 있는 메시징 전송을 이용하여 이니시에이터와 억셉터 간에서 신뢰성 있게 메시지를 전달할 수 있다. 메시징 대기(queuing) 통신 기술로 인해, 서로 다른 시스템 상의 애플리케이션은, 메시지를 대기열로 송신하고 신뢰도에 대한 부족이 지속된 대기열로부터 메시지를 판독함으로써, 서로 통신할 수 있게 된다.

SOAP 메시지를 신뢰성 있게 전송하는데 이용될 수 있는 전송 수단을 대기 시스템이 제공하지만, 이와 같은 시스템에는 몇몇의 결점이 있다. 예를 들어, 이들 시스템은, 요구(또는 그들의 응답)가 분리되어 전송되고 처리되는 비동기식 동작에 대한 솔루션을 제공한다. 따라서, 통상, 이들 시스템은, 자원의 관점에서 무겁고, 내구성의 처리 메시지 기억장치를 가지며 배치, 프로그래밍 모델 및 관리에 있어서 상당히 더 복잡한 다수의 매개체를 필요로 한다. 이들 모두는 신뢰성 있는 직접 통신에 불필요하고, 지연 시간을 최소화하려는 목적을 손상하게 된다. 또한, 프로그램 모델은 요구-응답 양식 프로그래밍 또는 세션을 직접 지원하지 않는다. 따라서, 대기 통신 모델은 현재의 "대화형" 웹 서비스 모델과 다르며, 중요한 "접속된" 시나리오 및 "대화형" 애플리케이션에 관한 것도 아니다. 예를 들어, 이 대기 통신 모델은, 응답이 적절한 방법으로 예상되는 경우, 또는 분산-트랜잭션-콘텍스트가 이니시에이터와 억셉터 간에 공유될 필요가 있는 경우에는 잘 어울리지 않는다.

또한, 예를 들어, 신뢰성 있는 HTTP 또는 HTTPR 등의, 기본적으로는 신뢰성 없는 전송 프로토콜 상에서 신뢰성 있는 전송 계층을 규정하려는 시도도 있었다. 그러나, 대기 솔루션 뿐만 아니라 이 솔루션을 괴롭히는 공통적인 문제는, 신뢰성 있는 특정 전송 프로토콜이 이니시에이터와 억셉터 간의 통신에 이용되는 경우에만 신뢰성 있는 메시징을 달성할 수 있다는 것이다. 웹 서비스의 기본 구조는 특정 제조자 플랫폼, 구현 언어 및 특정 전송 프로토콜로부터의 독립을 필요로 한다. 일반적인 경우에는, 이니시에이터가 특정 프로토콜을 이용하여 억셉터에 직접 메시지를 전송할 수 없거나(예를 들어, 억셉터가 프로토콜을 지원하지 않는 등), 메시지가 송신 노드를 떠난 후 그 수신 노드에 도착하기 전 다수의 홉(hop)을 통과할 필요가 있다. 특정 홉에 관련된 2개의 노드 간의 접속성에 따라, 신뢰성 있는 메시징 특성을 제공하지 않는 적당한 전송 프로토콜이 선택될 수도 있다.

또한, 매개체는 프로토콜 스택에서 서로 다른 레벨로 존재할 수도 있으므로, 완전한 종단 대 종단(end-to-end) 신뢰도를 제공하지 않게 된다. 예를 들어, 전송 프로토콜은 (예를 들어, IP 레벨 매개체 내지 IP 라우터 등의)하위 레벨 매개체 상에서 신뢰도를 제공할 수도 있다. 그러나, 전송 프로토콜은 SOAP 매개체 또는 애플리케이션 계층에서 종료할 수도 있다. 따라서, 전송 프로토콜은 그 매개체 상에서 신뢰도를 제공할 수 없게 되고, 즉, 애플리케이션 계층 상에서 아무런 종단 대 종단 신뢰도를 제공할 수 없게 된다.

더 최근에는, 예를 들어, WSReliableMessaging 등의, 여러 웹 서비스를 위한 신뢰성 있는 메시징 프로토콜(이하, "RM-WS 프로토콜"로 지칭됨)이 현재 신뢰성 있는 메시징 시스템의 상기와 같은 결함에 대한 솔루션을 제공한다. 이들 프로토콜은, 소프트웨어 구성요소, 시스템 또는 네트워크 장애의 존재하에 종단점 애플리케 이션 간에서 메시지가 신뢰성 있게 전달될 수 있도록 하는 전송 불가지론(agnostic) 접속된 프로토콜이다. 따라서, RM-WS 프로토콜은, 이니시에이터와 억셉터 간의 신뢰성 있는, 종단 대 종단의, 세션-지향 통신을 위한 솔루션을 제공한다.

이들 RM-WS 프로토콜은, TCP가 IP(Internet Protocol) 라우터와 다수의 네트워크 상에서 TCP 송신기로부터 TCP 수신기로 바이트 스트림의 신뢰성 있는, 정확히 한 번의, 순서에 따른 전달을 제공한다는 점에서, TCP와 유사하다. WS를 위한 신뢰성 있는 메시징 프로토콜은 다수의 매개체(SOAP 레벨 매개체를 포함), 전송 수단 및 접속 수단 상에서 메시지에 대해 그와 동일하거나 그 이상을 제공한다(주: 전송 단위는 바이트가 아니라 메시지이다). TCP와 RM-WS 프로토콜이 모두 "신뢰성 있는" 프로토콜이지만, RM-WS가 OSI 모델 내의 애플리케이션 또는 SOAP 계층에 상주하므로, RM-WS 프로토콜이 데이터를 전송하는데 이용되는 전송 프로토콜에 관계없이 신뢰성 있는 메시징을 제공하게 된다. 따라서, RM-WS 프로토콜은 종단점 간에서 메시지를 전송하는데 이용되는 특정 전송 또는 다른 프로토콜에 결합되지 않는다.

소수의 RM-WS 프로토콜이 주위에 얼마 동안 존재하였지만, 이들 프로토콜 규격에도 여전히 몇몇의 결점과 결함이 있다. 예를 들어, 현재, 종단점 간의 메시지의 흐름 제어를 위해 이들 프로토콜에 의해 규정된 솔루션이 없다. 통상, 신뢰성 있는 메시지 교환에 있어서 억셉터는, 처리 애플리케이션에 전달되기 위해 수신된 메시지가 기억되는 버퍼를 갖는다. 이로 인해, 메시지가 수신된 즉시 이 메시지를 처리하기 위해 처리 애플리케이션이 이용가능하게 될 필요가 없으므로, 시스템의 유연성을 허용하게 된다. 그러나, 어떤 시스템도 (하드웨어 및/또는 소프트웨어에 의해 제한되는)그 시스템에 이용가능한 유한한 자원을 가지므로, 버퍼는 용량이 제한된다. 이와 같이, 수신 애플리케이션이 메시지가 송신 및/또는 수신되는 속도보다 더 느린 속도로 그 메시지를 처리하는 경우 문제가 발생할 수도 있다. 이와 같은 경우, 억셉터 버퍼가 가득 채워져 수신된 메시지가 전송 수단으로부터 판독되지 않거나 (전송 수단으로부터 메시지를 판독했으나 공간 부족으로 이 메시지를 버퍼 내에 캡처링하지 않는 행동인)드롭핑될 수도 있으므로, 그 메시지에 대한 수신 확인(acknowledgement)을 송신하지 않게 된다.

메시지 드롭핑은 통상의 RM-WS 프로토콜에 의해 허용되며 치명적인 장애로 생각되지 않으므로, 억셉터로부터 수신 확인이 없는 경우 이니시에이터는 전송을 재시도하게 된다. 그러나, 재시도로 인해, 네트워크와 시스템 자원이 낭비되므로, 이니시에이터가 메시지를 드롭핑하지 않고 얼마나 많은 메시지를 억셉터에 송신할 수 있는지를 이니시에이터가 알도록 하는 효율적인 메커니즘에 대한 필요가 발생하게 된다.

또한, 상술한 흐름 제어 문제와 유사하게, 네트워크 와이어 상에서의 혼잡 제어도 중요하다. 통상, 네트워크 상에서 송신된 메시지는 예를 들어 라우터 등의 여러 노드에 의해 브리지된 몇몇의 전송 접속 수단 상에서 전송된다. 서로 다른 전송 접속 수단은, (예를 들어, 이니시에이터에서 노드까지 100 mbps의 이더넷 접속 수단과 노드에서 억셉터까지 56 kbps의 다이얼-업 접속 수단 등의)서로 다른 속도일 수도 있다. 전송 접속 수단의 속도 차이로 인해, 노드에서 억셉터까지의 접속 수단이 백업(back-up)될 수 있으며, 이는, 일부 콘텐츠를 우선 삭제할 필요가 있으므로 네트워크가 어떤 새 콘텐츠도 취할 수 없게 되는 것을 의미한다. 이는, 노드가 그 릴레이 전송 속도를 줄여야 하므로, 이 노드가 수신 메시지를 그 목적지로 송신할 수 있기 전에 그 메시지를 버퍼링하게 되는 것을 의미한다. 다른 컴퓨팅 자원과 유사하게, 노드가 새 수신 메시지 드롭핑을 시작할 필요가 있기 전에, 이 노드는 매우 많은 메시지를 버퍼링할 수 있을 뿐이다. 버퍼링이 일시적인 트래픽 스파이크를 처리하는 좋은 기술이지만, 지연 시간을 최소화하기 위해, 시스템은 매개체에서 발생하는 버퍼링의 양을 최소화하도록 노력해야 한다. 또한, 메시지 드롭핑에 대한 다른 이유는 동일 송신 링크를 위해 경쟁하는 노드 모두에 대한 수신 링크 수 때문이며, 수신기는 그 노드에서 활동의 폭주(burst) 또는 요구를 처리하는 속도가 느려진다.

네트워크의 메시지 드롭핑에 대한 이유에 관계없이, 상술한 바와 같이, 신뢰성 있는 메시징 시스템의 경우, 드롭핑된 메시지는 전달을 보장하기 위해 재시도될 필요가 있다. 순서에 따른 전달이 요구되면, 그 시퀀스 번호가 드롭핑된 메시지보다 높은 메시지 처리는, 드롭핑된 메시지가 수신될 때까지 지연되므로, 억셉터 측에서 비효율적으로 처리하게 된다. 또한, 드롭핑된 메시지의 재시도는 이니시에이터에서 노드까지의 링크 상에 훨씬 더 많은 메시지를 발생시키고, 결국, 훨씬 더 많은 메시지가 드롭핑된다(즉, 혼잡, 성능 장애 및 자원 낭비).

따라서, 흐름 제어를 조정하는 것뿐만 아니라 네트워크 와이어 상의 혼잡 변화에도 적응하도록 하는 솔루션에 대한 필요성이 발생하게 된다. 알 수 있는 바와 같이, 상기 문제는, 예를 들어 라우터 등의 다수의 노드가 이니시에이터에서 억셉터까지의 경로 상에 채택되는 시나리오까지 확장된다. 이와 같이, 솔루션은 라우터 수를 고려해야 하는데, 그 이유는, 그 수가 이니시에이터에게 알려지지 않고 사실상 시간에 따라 변할 수도 있기 때문이다. 또한, 솔루션은 네트워크 대역폭, 성능 및 토폴로지에서의 변화에도 적응할 수 있어야 한다.

현재 웹 서비스를 위한 신뢰성 있는 메시징 프로토콜의 상술한 결함과 결점은 본 발명의 예시적인 실시예에 따라 해결된다. 예를 들어, 본 발명은, 억셉터의 이용가능한 버퍼 크기에 기초하여 메시지를 송신하는 메시지 윈도 크기를 동적으로 결정함으로써, RM-WS(Reliable Messaging protocol for WS)에 따라 종단점 간의 효율적인 메시지 전송을 제공한다. 또한, 본 발명은, 네트워크 대역폭, 성능 및 토폴로지에서의 변화 등에 적응하기 위해 RM-WS 프로토콜에 따라 종단점에 메시지를 송신하는 전송 윈도를 조정함으로써, 네트워크 혼잡 제어를 제공한다.

예를 들어, 일 실시예는, RM-WS 프로토콜에 따라 이니시에이터와 억셉터 간의 시퀀스 세션을 애플리케이션 계층에서 확립하는 것을 제공한다. 예상 버퍼 크기 정보를 포함하는 메시지는 시퀀스 세션 상에서 수신되고, 억셉터 버퍼 크기 정보는, 애플리케이션에 의해 처리되기 위해 대기중인 메시지를 버퍼링하기 위한 이용가능한 메모리 양을 표시한다. 또한, 인 플라이트 메시지 수가 식별되며, 이 인 플라이트 메시지는 RM-WS 프로토콜에 따라 대응하는 확인을 수신하지 않고 억셉터에 송신된 메시지이다. 억셉터 버퍼 크기 정보와 인 플라이트 메시지 수에 기초하여, 버퍼 오버런으로 인한 메시지 재송신을 방지하기 위해, 억셉터에 송신될 수 있는 메시지 수의 상한을 표시하는 메시지 윈도 크기가 계산된다.

혼잡 제어를 위한 다른 예시적인 실시예에서, 본 발명은, RM-WS 프로토콜에 따라 확립된 시퀀스 세션 상에서 억셉터에, 메시지 윈도 크기에 대응하는 메시지 수를 송신하는 것을 제공한다. 메시지 윈도 크기는 네트워크 와이어 상에서 억셉터에 송신되는 인 플라이트 메시지 수의 상한을 표시한다. 메시지 윈도 크기에 기초하여, 예상 메시지 전송 시간이 식별되고, 이 예상 메시지 전송 시간은 메시지 수의 송신과 대응하는 확인 메시지의 수신 간의 예상 시한(time limit)을 규정한다. 그 후, 예상 메시지 전송 시간이 경과하기 전에 대응하는 확인 메시지가 수신되었는지 여부에 관한 표시가 제공되며, 이 표시는, 네트워크 혼잡으로 인한 메시지 재송신을 방지하기 위해 메시지 윈도 크기 및/또는 재시도 시간 주기를 조정하는데 이용된다.

본 발명의 부가적인 특징과 이점은 다음의 상세한 설명에서 개시되고, 일부는 상세한 설명으로부터 명확하게 되거나, 본 발명의 실시에 의해 알 수도 있다. 본 발명의 특징과 이점은 첨부된 청구항에서 특별히 나타낸 수단과 조합에 의해 실현되고 얻어질 수도 있다. 본 발명의 이들 및 다른 특징은, 다음의 상세한 설명과 첨부된 청구항으로부터 더 완전히 명확하게 되거나, 이하 개시되는 본 발명의 실시에 의해 알 수도 있다.

본 발명의 상술한 및 다른 이점과 특징이 얻어질 수 있는 방법을 설명하기 위해, 첨부된 도면에서 나타낸 본 발명의 특정 실시예를 참조하여 위에서 간단히 설명된 본 발명의 설명이 더 상세하게 제공된다. 이들 도면은 본 발명의 전형적인 실시예만을 나타내는 것이므로 본 발명의 범위를 한정하려는 것은 아님을 알 수 있고, 본 발명은, 첨부된 도면을 이용하여 부가적인 특이성과 상세함으로 나타내고 설명된다.

본 발명은, 웹 서비스를 위한 신뢰성 있는 메시징 프로토콜 환경에 있어서 흐름 및 혼잡 제어를 위한 방법, 시스템 및 컴퓨터 프로그램 제품으로 확장된다. 아래에서 더 상세하게 설명되는 바와 같이, 본 발명의 실시예는 여러 컴퓨터 하드웨어를 포함하는 전용 또는 범용 컴퓨터를 구비할 수도 있다.

본 발명은, (이하, "RM-WS" 프로토콜로 지칭되는)웹 서비스를 위한 신뢰성 있는 메시징 프로토콜의 확장에 관한 것으로, 이 RM-WS 프로토콜은 소프트웨어 구성요소, 시스템 또는 네트워크 장애의 존재하에 분산 애플리케이션 간의 신뢰성 있는 메시지 전달을 허용하는 프로토콜을 나타낸다. 웹 서비스를 위한 신뢰성 있는 메시징 프로토콜은, 소스(이하, "이니시에이터")에서, 예를 들어, 서비스 등의 수신지(이하, "억셉터")까지 메시지의 성공적인 전송을 용이하게 하고, 에러 조건이 검출될 수 있는 것을 보장한다. 이들 프로토콜은 전송 불가지론으로서, 서로 다른 네트워크 전송 기술을 이용하여 이들 프로토콜이 구현되는 것을 허용한다. 또한, 신뢰성 있는 메시징 프로토콜의 여러 구현예는 간헐적인 통신 장애를 애플리케이션으로부터 숨기며, 시스템 장애의 경우 복구를 제공할 수도 있다.

예시적인 실시예는, 억셉터의 이용가능한 버퍼 크기에 기초하여 메시지를 송신하는 메시지 윈도 크기를 동적으로 결정함으로써 RM-WS 프로토콜을 이용한 메시지의 효율적인 전송을 제공한다. 더욱 상세하게는, 본 발명은, 억셉터가 이니시에이터에게 억셉터의 버퍼 내에 얼마나 많은 공간이 존재하는지를 알려주는 흐름 제어 메커니즘을 제공한다. 억셉터 버퍼 크기 정보는, 예를 들어, 기반구조 확인 응답 메시지 등의 응답 메시지에 포함되며, 이니시에이터가 메시지 윈도 크기를 계산하는데 이용된다. 그 후, 이 계산된 윈도 크기는, 버퍼 오버런으로 인한 메시지 재송신을 방지하기 위해 억셉터에 송신될 수 있는 메시지 수의 상한을 규정한다.

도 1A는 상술한 예시적인 흐름 제어 실시예를 나타낸다. 도 1A는 이니시에이터(105) 및 억셉터(120)를 포함하는 분산 네트워크(100)를 도시한다. RM-WS 프로토콜에 따라 메시지를 교환하기 위해 이니시에이터(105)와 억셉터(120) 간에 접속이 확립된다. 일단 확립되면, 억셉터(120)는 (예를 들어, 기반구조 메시지(115) 등의)메시지 내의 그 버퍼 크기에 관한 정보를 이니시에이터(105)에 주기적으로 송신할 수 있다. 억셉터 버퍼 크기 정보는 애플리케이션(135)에 의해 처리되기 위해 대기중인 버퍼링된 메시지(185)를 위한 이용가능한 메모리(130) 양을 표시하게 된다.

통상 기반구조 메시지(115)가 억셉터 버퍼 크기 정보를 이니시에이터(105)에 송신하는데 이용되지만, (예를 들어, 억셉터로부터 출력되어 송신된 메시지 등의)애플리케이션 계층 메시지도 억셉터(120)의 이용가능한 메모리 크기를 식별하는 확 장을 포함할 수도 있음을 주목하자. 또한, 통상, 기반구조 메시지(115)는 RM-WS 프로토콜에 따른 확인 응답 메시지이지만, 본 발명은 임의의 특정 타입의 기반구조 메시지(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)는, 메시지 윈도 크기(155) 계산시, 이용가능한 억셉터 버퍼 크기에서 인 플라이트 메시지(125) 수를 빼는데 윈도 크기 계산 모듈(110)을 이용할 수 있다. 상술한 바와 같이, 메시지 윈도 크기(155)는 버퍼 오버런으로 인한 메시지 재송신을 방지하기 위해 억셉터(120)에 송신될 수 있는 메시지 수의 상한을 표시한다.

통상, 기반구조 메시지(115) 내의 버퍼 크기 정보는 바이트보다는 메시지 단위로 됨을 주목하자. 또한, 이와 유사하게, 메시지 윈도 크기(155)도 특정 바이트 크기보다는 메시지 수의 단위로 될 수도 있다. 또한, 예를 들어, 인 플라이트 메시지(125) 등의 이니시에이터(105)가 송신한 메시지 수와, 억셉터(120)의 메모리(130)에서 이용가능한 공간 수를 이니시에이터(105)가 기억하므로, 이니시에이터는 얼마나 많은 공간이 억셉터(120) 측에서 이용가능한지를 항상 알게 된다. 따라서, 이니시에이터(105)는 처리 애플리케이션(135)의 메시지 처리 속도를 산정하려는 노력을 하지 않고, 오히려 얼마나 많은 메시지를 억셉터(120)가 버퍼링할 수 있는지를 이니시에이터(105)에게 알려주는 억셉터(120)에 의존하게 된다. 이로 인해, 윈도 크기 계산 모듈(110)은 일정 속도 처리 또는 무작위 폭주(burst) 처리 등의 어떤 처리 속도로도 작업하게 된다.

다른 예시적인 실시예는, 예를 들어, 확인 응답 메시지 등의 기반구조 메시지(115)가 신뢰성 없다(즉, 억셉터로부터 이니시에이터로 전송중 없어질 수도 있다)는 사실로부터 발생하는 문제에 관한 것이다. 아래에 더 상세하게 설명되는 바와 같이, 이와 같은 실시예에서, 메시지 윈도 크기(155)가 0과 동일하면, 이니시에이터(105)는, 예를 들어, 특정 RM-WS 프로토콜에 따라 확인 요구 메시지를 송신함으로써 이용가능한 공간을 주기적으로 검색할 수 있다. 확인 요구 메시지에 응답하여, 대응하는 확인 응답(들)은 현재 억셉터 버퍼 크기 정보를 통상 포함하게 된다.

버퍼 크기 정보와 인 플라이트 메시지(125) 수 이외의 정보도 메시지 윈도 크기(155) 계산시 윈도 크기 계산 모듈(110)에 의해 이용될 수 있음을 주목하자. 예를 들어, 기반구조 메시지(115)가 확인 응답 메시지인 경우, 현재 확인되고 있는 메시지 수도 메시지 윈도 크기(155)를 줄이는데 이용될 수도 있다. 또한, 배치(batch) 확인의 경우, 이전에 수신된 확인 응답 수도 이용될 필요가 있을 수도 있다.

다음은, 예시적인 실시예에 따라 메시지 윈도 크기(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개의 메시지에 대한 확인(115)을 방금 수신하였으며, 이 확인(115)은 억셉터(120)가 5개의 메시지를 버퍼링할 수 있음을 표시하는 억셉터 버퍼 크기 정보를 포함한다. 이니시에이터(105)는 메시지 11 내지 15를 송신하고 그 이상의 메시지 송신을 중지한다. 다음으로, 이니시에이터(105)는, 억셉터(120)의 수신 메모리(130)에서 5개의 공간이 이용가능함을 표시하는 억셉터 버퍼 크기 정보와 메시지 1 내지 13에 대한 확인(115)을 수신한다. 억셉터(120)로 송신된 2개의 메시지가 인 플라이트 상태인 것을 알게 되면, 이니시에이터(105)는 억셉터에 3개의 메시지를 더 송신할 뿐이고, 그 후, 더 많은 공간이 이용가능하게 될 때까지 대기하게 된다.

다른 예시적인 실시예의 이점은, 접속 기반마다(on a per connection basis) 동적으로 구성가능한 메모리(130) 버퍼 크기를 제공하는 것이다. 이 특징으로 인해, 높은(또는 낮은)버퍼링 필요성을 갖는 이니시에이터(105)에 적절히 메모리(130)를 할당함으로써 각각의 접속에 대해 최적의 흐름을 달성할 수 있는, 시스템 자원의 균형을 허용한다. 수신 측의 메시지 버퍼링을 위해 하드-코드(hard-coded)의 메모리 할당을 갖는 TCP와 달리, 예시적인 실시예에서는, 억셉터(120)의 메모리(130) 용량(즉, 접속에 할당하는 전체 버퍼 크기)이, 이니시에이터(105)의 처리 속도와 요구의 복잡도 등에 기초하여 구성될 수 있다.

예를 들어, 하나의 메시지를 주기적으로 송신할 뿐인 이니시에이터(105)에 대해 확립된 접속은 버퍼링된 메시지(185)를 위해 많은 양의 메모리(130)를 필요로 하지 않는다. 따라서, 이니시에이터(105)의 특정한 필요성과 대응하는 메모리 (130)의 할당을 결정하기 위해, 이니시에이터(105)와 억셉터(120) 간의 절충이 발생할 수도 있다. 또한, 이 절충 처리는, 여러 분산 장치 상에서 메모리(130) 자원의 적절한 균형을 맞추기 위해, 각각의 확립된 접속에 대해 발생할 수 있다.

또한, 다른 예시적인 실시예는, 네트워크 대역폭, 성능 및 토폴로지에서의 변화 등에 적응하기 위해 종단점에 메시지를 송신하는 전송 윈도 및/또는 재시도 시간 주기를 조정함으로써 혼잡 제어를 제공한다. 상기 메커니즘은, 메시지가 송신된 시점부터 대응하는 확인이 수신된 시간까지 경과한 왕복 시간의 측정을 필요로 한다. 이하, 혼잡 제어 처리가 수행되는 방법의 일 예를 간단히 설명한다.

우선, 예시적인 실시예는, 소망하거나 최적인 속도에 가까운 근사 속도를 적극적으로 검색한다. 본 발명은, 예를 들어, 실패 지점이 발견될 때까지 인 플라이트 메시지 수를 지수적으로 증가시키는 등에 의해, 속도를 검색하지는 않는다. 실패 지점 아래의 최종 성공 속도는 최적 지점에 가장 가까운 알려진 지점이다. 그 후, 예시적인 실시예는, 리셋하고, 최종의 알려진 좋은 지점으로 다시 속도를 (예를 들어, 지수적 속도 증가를 이용하여)올리고 최적 속도에 점근하는 알고리듬을 이용하여 그 지점에서부터 미세 조정을 재시도한다.

도 1B는 상기와 같은 실시예들 중 일부 실시예를 수행하기 위한 네트워크(100)를 나타낸다. 도시된 바와 같이, 이니시에이터(105)는 제1 메시지 수(175)를 억셉터(120)에 송신할 수 있다. 억셉터(120)가 제1 메시지 수(175)를 수신하면, 제1 확인 응답(165)이 이니시에이터(105)에 송신된다. 제1 확인 응답(165)을 수신하면, 메시지 전송 시간 비교 모듈(140)을 이용하여, 어떻게 메시지 윈도 크기 (155)가 조정되어야 하는지 및/또는 재시도 시간 주기가 (더 빠르게 또는 더 느리게)조정되어야 하는지를 결정할 수 있다.

예를 들어, 메시지 전송 시간 비교 모듈(140)은 예상 메시지 전송 시간을 결정하고, 이 예상 메시지 전송 시간은 제1 메시지 수(175) 송신과 대응하는 제1 확인 응답(165)의 이니시에이터에서의 수신 간의 예상 시한을 규정한다. 즉, 억셉터(120)로의 메시지(175) 송신으로부터 대응하는 확인(165)의 이니시에이터(105)에서의 수신까지의 예상 왕복 시간에 의해 규정되는 예상 메시지 전송 시간이 존재한다. 아래에 더 상세하게 설명되는 바와 같이, 통상, 예상 메시지 전송 시간은 메시지 윈도 크기(155)에 기초하게 되고, 이 메시지 윈도 크기(155)는 네트워크 와이어 상에서 억셉터에 송신되는 인 플라이트 메시지 수의 상한을 표시한다.

일단 메시지 전송 시간 비교 모듈(140)이 예상 메시지 전송 시간을 결정하면, 이 메시지 전송 시간 비교 모듈(140)은, 제1 메시지 수(175)를 억셉터(120)에 송신하고 제1 확인 응답(165)을 다시 수신하는 실제 시간과 예상 메시지 전송 시간을 비교한다. 예상 메시지 전송 시간이 경과하기 전에 제1 확인 응답(165)이 수신되면, 메시지 전송 시간 비교 모듈(140)이 메시지 윈도 크기 조정 모듈(145)에 성공 표시를 주게 된다. 따라서, 메시지 윈도 크기 조정 모듈(145)은 메시지 윈도 크기(155)를 증가시키고, 이 성공을 최종의 알려진 좋은 값(180)으로서 메모리(150)에 기록한다. 즉, 이전 메시지 윈도 크기(155)가 최종의 알려진 좋은 값(180)으로서 기록되고, 이전 메시지 윈도 크기(155)는, 통상적으로 지수적 증가인, 일정 계수만큼 증가된다. 그 후, 증가된 메시지 윈도 크기(155)에 대응하는 제2 메시지 수(170)가 억셉터(120)에 송신되고, 제2 확인 응답(또는 응답; 160)이 제2 메시지 수(170)에 대해 수신되며, 실패가 발생할 때까지 처리가 계속된다.

한편, 제1 확인 응답(165; 또는 경우에 따라 제2 확인 응답이 "170"일 수도 있다)을 수신하기 전에 예상 메시지 전송 시간이 경과하면, 메시지 전송 시간 비교 모듈(140)은 메시지 윈도 크기 조정 모듈(145)에 실패 표시를 주게 된다. 이와 같은 경우, 실패 표시는 몇몇의 사건이 발생했음을 암시할 수도 있음을 주목하자. 예를 들어, 송신된 메시지(제1 메시지 수(175) 또는 증가된 제2 메시지 수(170))가 없어질 수도 있다. 다른 방법으로는, 또는, 네트워크 와이어 상의 혼잡 변화에 적응하도록 구성된 하나 이상의 솔루션과 관련하여, 송신된 메시지(175, 170)가 없어지거나 예상 메시지 전송 시간이 경과한 후 수신될 수도 있다.

어느 경우이든, 메시지 윈도 크기 조정 모듈(145)은, 통상, 메모리(150)에 기억된 최종의 알려진 좋은 값(180) 이하의 일정 값으로 메시지 윈도 크기(155)를 감소시키거나, 및/또는 재시도 시간 주기를 증가시킨다(즉, 메시지 재시도를 위해 대기하는 기간을 더 길게 한다). 예시적인 실시예는 최종의 알려진 좋은 값(180) 이하의 일정 값으로 메시지 윈도 크기(155)를 감소시키지만, 본 발명은 이와 같은 특정 실시예에 한정되지는 않는다. 예를 들어, 메시지 윈도 크기 조정 모듈(145)은, 성공이 달성될 때까지 메시지 윈도 크기(155)를 증분적으로 감소시킬 수도 있고, 이는 최종의 알려진 좋은 값(180)일 수도 있고 아닐 수도 있다. 이와 유사하게, 성공 표시 수신시 상술한 메시지 윈도 크기(155)의 증가는 반드시 지수적 증가일 필요는 없으며, 그 작은 증분일 수도 있다. 사실상, 아래에 더 상세하게 설명 되는 바와 같이, 메시지 윈도 크기(155)를 조정하기 위한 서로 다른 알고리듬은 미세 조정 및 다른 용도를 위해 이용될 수도 있다. 따라서, 성공 또는 실패 표시에 기초한 윈도 크기(155)의 임의의 특정 증가 또는 감소는 단지 설명 목적으로 이용되는 것으로, 명확하게 청구되지 않는 한 본 발명의 범위를 한정하거나 좁히려는 의도는 아니다.

그러나, 메시지 윈도 크기 조정 모듈(145)에서 실패 표시가 수신되는 경우, 예시적인 실시예는, 메시지 윈도 크기(155)가 1의 크기로 줄어드는 것을 제공한다. 그 후, 메시지(175, 170)를 전송하기 위한 연속적인 시도는, 메시지 윈도 크기(155)를 최종의 알려진 좋은 값(180)으로 지수적으로 증가시키게 된다. 메시지 윈도 크기(155)의 과도한 변화가 전송 속도를 늦추고, 지수적인 증가 처리를 그 초기 상태로 사실상 리셋함을 주목하자. 그러나, 이니시에이터(105)에 의해 메시지를 송신하는 실제 버퍼 크기는 줄어들지 않고, 송신을 위해 이미 버퍼링된 메시지가 버퍼에서 삭제되지 않을 수도 있으나, 어떤 새 메시지도 기반구조에 의해 수신되지 않을 수도 있으므로(즉, 송신 동작이 차단된다), 이니시에이터(105)를 사실상 감속하게 된다. 일단, 버퍼 내의 메시지 수가 실제 메시지 윈도 크기(155) 이하로 되면, 새 메시지가 기반구조에 의해 수신될 수도 있다.

상술한 리셋 후, 이니시에이터(105)의 버퍼 내의 가장 오래된 메시지의 재전송을 시도하고, 새 예상 메시지 전송 시간이 설정된다. 재전송된 메시지에 대한 대응하는 확인을 수신하기 전에, 새 예상 메시지 전송 시간이 경과하면, 예시적인 실시예는 예상 메시지 시간을 두 배로 하여 재시도하는 것을 제공한다. 이 처리 는, 성공 상태에 도달할 때까지 또는 구성가능한 횟수의 시도를 할 때까지, 반복하여 발생할 수도 있고, 이 경우 전송은 실패로 선언되고, 에러가 이니시에이터(105) 애플리케이션으로 상승할 수도 있다. 본 실시예는 메시지 백 오프(back-off) 재시도 메커니즘을 효율적으로 구현하고, 이 메커니즘은 네트워크(100) 상의 혼잡이 정상화되거나 정상 상태에 도달하는 것을 허용한다.

성공적인 전송을 수신하면, 메시지 윈도 크기(155)와 메시지 전송 속도의 증가가 상술한 바와 같이 다시 시도될 수 있다. 상술한 바와 같이, 최종 시도에서 배운 것을 적용하기 위해, 예시적인 실시예는, 메시지 윈도 크기(155)를 최종의 알려진 좋은 값(180)으로 적극적으로 증가시키는 것을 제공한다. 이때, 메시지 윈도 크기 조정 모듈(145)은 알고리듬을 변경하여 최적점을 찾는 것을 시도한다. 예를 들어, 실시예는 다음과 같이 점근적인 알고리듬(및 메시지 윈도 크기(155)의 적절한(opportunistic) 증가)를 제공한다. 메시지 윈도 크기의 최종의 알려진 좋은 값(180)에 도달하면, 메시지 윈도 크기 조정 모듈(145)은, 최적점을 추측하기 위한 시도로서, 최종의 실패한 메시지 윈도 크기(155)와 최종의 알려진 좋은 값(180) 간의 차이를 일정 계수로 나누어, 최종의 실패한 메시지 윈도 크기(155)와 최종의 알려진 좋은 값(180) 간의 한 지점을 선택할 수도 있다. 그 값이 너무 높으면(즉, 그 값이 최적 속도 이상이고, 메시지가 없어지거나 과도하게 지연되도록 하면), 메시지 윈도 크기 조정 모듈(145)은 그 계수를 낮은 값으로 재조정한다.

물론, 메시지 윈도 크기(155)를 미세 조정하거나 조정하는데 이용될 수 있는 다른 특정 구현예 또는 알고리듬이 존재한다. 예를 들어, 최종의 알려진 좋은 값 (180)에 도달한 후, 메시지 윈도 크기 조정 모듈(145)은, 최적 크기가 달성될 때까지 메시지 윈도 크기(155)를 단순히 증분적으로 증가시킬 수도 있다. 따라서, 상술한 바와 같이, 최적 메시지 윈도 크기(155)에 적극적으로 근접하거나 메시지 윈도 크기(155)를 미세 조정하기 위한 임의의 특정 알고리듬의 이용은, 단지 설명 목적으로 이용되는 것으로, 명확하게 청구되지 않는 한 본 발명의 범위를 한정하거나 좁히려는 의도는 아니다.

또한, 일단 최적 메시지 윈도 크기(155)가 결정되면, 다른 예시적인 실시예는 대역폭의 증가를 조정하기 위해 주기적으로 최적값을 증가시키는 것을 제공한다. 또한, 예시적인 실시예는, 네트워크(100) 상에서 대역폭의 감소를 표시하는 실패가 발생한 때를 검출하는 것을 제공한다. 이와 같은 경우, 메시지 윈도 크기(155)가 리셋될 수도 있고, 상술한 증가 처리가 최종의 알려진 좋은 값(180)으로 증가될 수도 있으며, 미세 조정 처리가 다시 구현될 수도 있다. 최종의 알려진 좋은 값(180)이 실패한 경우, 예시적인 실시예는 최종의 알려진 좋은 값 이전의 값(즉, 최종의 알려진 좋은 값 바로 전의 값)을 결정하는 것을 제공함을 주목하자. 그 후, 최종의 알려진 좋은 값(180) 대신 상기 이전 값으로 대체될 수 있고, 상술한 처리가 계속될 수도 있다.

상술한 바와 같이, 실패를 검출하기 위해, 예시적인 실시예는 전송 시간을 측정하는데, 여기서 전송 시간은 메시지 송신에서 그 확인 수신까지 걸리는 시간을 말한다. 이 문제는, RM-WS 프로토콜이 억셉터(120)가 확인 응답을 모으는 것을 허용하여, 단일의 확인 응답이 다수의 메시지 수신을 확인하는 일정한 경우에, 복잡 하게 된다. 따라서, 예시적인 실시예는, 대응하는 배치(batch) 확인이 수신될 때까지 메시지 윈도 크기(155)에 대응하는 각각의 메시지를 전송하는데 경과한 시간을 추적한다. 그 후, 전체 왕복 시간의 분포의 평균 및/또는 분산을 이용하여 실제 전송 시간이 계산된다.

왕복 시간의 분산이 배치에서 확인된 메시지 수에 따라 다르므로, 예상 메시지 전송 시간은 메시지 윈도 크기(155)에 기초하여 변하게 된다. 즉, 통상, 예상 메시지 전송 시간은, 메시지 윈도 크기(155)가 증가함에 따라, 증가하게 된다. 그러나, 예를 들어, 메시지 송신과 그 메시지에 대한 확인 수신 간의 일대일 대응관계가 구현되는 경우에는, 예상 메시지 전송 시간이 메시지 윈도 크기(155)에 반드시 기초할 필요는 없음을 주목하자. 따라서, 예상 메시지 전송 시간이 메시지 윈도 크기(155)에 기초하는 것은, 단지 설명 목적으로 이용되는 것으로, 명확하게 청구되지 않는 한 본 발명의 범위를 한정하거나 좁히려는 의도는 아니다.

다음 예는, 상술한 여러 실시예를 설명한다. 본 예에서, 메시지 윈도 크기(155)는 1의 윈도 크기로 개시될 수도 있는데, 즉, 하나의 메시지만이 이니시에이터(105)에서 억셉터(120)로 인 플라이트 상태일 수도 있다. 따라서, 메시지 번호 1이 억셉터(120)에 의해 수신될 수도 있고, 대응하는 확인 메시지 번호 1은 이니시에이터(105)에 의해 수신될 수도 있다. 그 후, 메시지 전송 시간 비교 모듈(140)은 왕복 시간을 측정하고 이 왕복 시간을 그 특정 메시지 윈도 크기(155)에 대한 예상 메시지 전송 시간과 비교한다. 그 비교에 대해 성공이 주어지면, 메시지 윈도 크기 조정 모듈(145)은 메시지 윈도 크기(155)를 2로 증가시키고, 여기서, 메시 지 번호 2와 3이 송신되고 이들 메시지에 대한 확인이 이니시에이터(105)에 의해 수신된다. 다시, 전송 시간이 성공적이면, 메시지 윈도 크기 조정 모듈(145)은 메시지 윈도 크기(155)를 4로 증가시키고, 여기서, 메시지 번호 4 내지 7이 송신되고 대응하는 확인이 수신된다. 이들 처리는 실패가 검출될 때가지 계속된다.

메시지 윈도 크기(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는 억셉터의 이용가능한 버퍼 크기에 기초하여 메시지를 송신하기 위한 메시지 윈도 크기를 동적으로 결정함으로써 RM-WS 프로토콜에 따라 종단점 간에서 효율적으로 메시지를 전송하는 방법(200)의 예시적인 흐름도를 나타낸다. 방법(200)은 시퀀스 세션을 확립하는 행동(205)을 포함한다. 예를 들어, 도 1A에 도시된 바와 같이, (예를 들어, SOAP 계층 등의)애플리케이션 계층에서의 시퀀스 세션은 (예를 들어, WSReliableMessaging 등의)RM-WS 프로토콜에 따라 이니시에이터(105)와 억셉터(120) 간에 확립될 수도 있다. 또한, 방법(200)은 시퀀스 세션 상에서 RM-WS 메시지를 수신하는 행동(210)을 포함한다. 예를 들어, 이니시에이터(105)는 억셉터 버퍼 크기 정보를 포함하는 억셉터(120)로부터의 메시지(115)를 수신할 수도 있고, 이 억셉터 버퍼 크기 정보는 애플리케이션(135)에 의해 처리되기 위해 대기중인 메시지(185)를 버퍼링하기 위한 이용가능한 메모리(130) 양을 표시한다. 통상, 메시지(115)는 예를 들어, 확인 응답 메시지(115) 등의 기반구조 메시지로 된다.

그 후, 방법(200)은 인 플라이트 메시지 수를 식별하는 행동(215)을 더 포함한다. 즉, 이니시에이터(105)는, RM-WS 프로토콜에 따라 대응하는 확인(들)을 수신하지 않고 억셉터에 송신된 인 플라이트 메시지(125) 수를 결정할 수 있다. 억셉터 버퍼 크기 정보와 인 플라이트 메시지 수에 기초하여, 방법(200)은 메시지 윈도 크기를 계산하는 행동(220)을 더 포함한다. 예를 들어, 윈도 크기 계산 모듈(110)은 기반구조 메시지(115) 내의 억셉터 버퍼 크기 정보와 인 플라이트 메시지(125) 수에 기초하여 메시지 윈도 크기(155)를 계산하는데 이용될 수도 있다. 메시지 윈도 크기(155)는 억셉터(120) 상의 버퍼 오버런으로 인한 메시지 재송신을 방지하기 위해 억셉터에 송신될 수 있는 메시지 수의 상한을 표시한다.

예시적인 실시예는, 윈도 크기가 0보다 큰 경우, 계산된 메시지 윈도 크기(155)에 대응하는 메시지 수가 억셉터(120)에 송신될 수도 있음을 제공한다. 한편, 메시지 윈도 크기(155)가 0인 경우, 예시적인 실시예는, 기반구조 메시지(또는 다른 메시지)가 수신되어 메시지 윈도 크기(155)가 0보다 큰 것으로 계산하는데 이용될 때까지, 메시지가 송신되는 것을 차단하는 것을 제공한다. 기반구조 메시지가 RM-WS 프로토콜에 따른 확인 응답 메시지(115)인 경우, 다른 예시적인 실시예는 억셉터(120)에 확인 요구 메시지를 주기적으로 송신하는 것을 제공한다. 이 확인 요구 메시지에 응답하여, 메시지 윈도 크기(155)를 재계산하기 위한 억셉터 버퍼 크기 정보를 포함하는 확인 응답 메시지(115)가 수신될 수도 있다. 따라서, 재계산된 메시지 윈도 크기(155)가 0보다 큰 경우, 재계산된 메시지 윈도 크기(155)에 대응하는 메시지 수가 송신될 수도 있다.

상술한 바와 같이, 버퍼 크기 정보는 메모리에서 이용가능한 바이트 수가 아니라 송신되는 메시지 수의 관점에서 설명될 수도 있다. 또한, 예시적인 실시예는, 애플리케이션에 의해 처리되기 위해 대기중인 메시지를 버퍼링하기 위해 할당된 억셉터의 전체 메모리가 접속 기반마다 동적으로 구성가능함을 제공한다. 또한, 메시지 윈도 크기(155)의 계산은 확인 메시지에서 확인된 메시지 수 및/또는 이전에 송신된 메시지에 대해 이전에 수신된 확인 수에 더 기초할 수도 있다.

도 3은, 네트워크 대역폭, 성능 및 토폴로지에서의 변화 등에 적응하기 위해 RM-WS 프로토콜에 따라 종단점 간에서 메시지를 송신하기 위한 전송 윈도를 조정함으로써 네트워크 혼잡을 제어하는 방법(300)의 예시적인 흐름도를 나타낸다. 방법(300)은 제1 메시지 수를 송신하는 행동(305)을 포함한다. 예를 들어, 도 1B에 도시된 바와 같이, 이니시에이터(105)는 (예를 들어, WSReliableMessaging 등의)RM-WS 프로토콜에 따라 확립된 시퀀스 세션 상에서 억셉터(120)에 제1 메시지 수(175)를 송신할 수도 있다. 제1 메시지 수(175)는 메시지 윈도 크기(155)에 대응하고, 메시지 윈도 크기(155)는 네트워크 와이어 상에서 억셉터(120)에 송신되는 인 플라이트 메시지 수의 상한을 표시한다.

또한, 방법(300)은 메시지 윈도 크기를 조정하는 단계(320)를 포함한다. 단계(320)는 예상 메시지 전송 시간을 식별하는 행동(310)을 포함한다. 예를 들어, 메시지 전송 시간 비교 모듈(140)은 예상 메시지 전송 시간을 식별하는데 이용될 수도 있고, 이 예상 메시지 전송 시간은 메시지 수의 송신과 대응하는 확인 메시지의 수신 간의 예상 시한을 규정한다. 또한, 단계(320)는, 대응하는 확인 메시지가 수신되었는지 여부에 관한 표시를 제공하는 행동(315)을 포함한다. 예를 들어, 메시지 전송 시간 비교 모듈(140)은, 예상 메시지 전송 시간이 경과하기 전에 대응하는 확인 메시지(165)가 수신되었는지 여부에 관한 표시를 메시지 윈도 크기 조정 모듈(145)에 제공할 수 있다. 그 후, 메시지 윈도 크기 조정 모듈(145)은 이 표시를 이용하여 메시지 윈도 크기(155) 및/또는 재시도 시간 주기를 조정함으로써 네트워크 혼잡으로 인한 메시지 재송신을 방지할 수 있게 된다.

다른 예시적인 실시예는, 메시지 윈도 크기(155)의 조정이, 예상 메시지 전송 시간이 경과하기 전에 대응하는 확인 메시지(들)(165)이 수신된 것을 표시하는, 메시지 윈도 크기(155)의 증가임을 제공한다. 메시지 윈도 크기(155)의 증가 후, 다른 예시적인 실시예는 증가된 메시지 윈도 크기(155)에 대응하는 증가된 메시지 수를 송신하는 것을 제공한다. 예를 들어, 제2 메시지 수(175)가 이니시에이터(105)에서 억셉터(120)에 송신될 수도 있고, 여기서, 증가된 메시지 윈도 크기(155)에 기초하여 메시지 전송 시간 비교 모듈(140)은 제2 예상 메시지 전송 시간을 식별할 수 있다. 증가된 예상 메시지 전송 시간은, 증가된 메시지 수(170)의 송신과 하나 이상의 대응하는 확인 메시지(160)의 수신 간의 예상 시한을 규정한다.

그 후, 메시지 전송 시간 비교 모듈(140)은, 제2 예상 메시지 전송 시간이 경과하기 전에, 증가된 메시지 수(170)에 대한 하나 이상의 대응하는 확인 메시지(160)가 수신되었는지 여부에 관한 표시를 제공할 수 있다(주: 통상, 제2 예상 메시지 전송 시간은 송신된 메시지 수의 증가로 인해 이전 값보다 증가하게 된다). 일 실시예에서, 메시지 윈도 크기 조정 모듈은 다음 중 적어도 하나를 표시하는 증가된 메시지 윈도 크기를 감소시킨다: 하나 이상의 증가된 메시지 수(170)가 없어졌다; 증가된 메시지 수(170)에 대한 하나 이상의 대응하는 확인 메시지(160)가 없어지거나 및/또는 제2 예상 메시지 전송 시간이 경과한 후 수신되었다. 증가된 메시지 윈도 크기의 감소는 메시지 윈도 크기와 증가된 메시지 윈도 크기 간의 크기일 수도 있다.

다른 예시적인 실시예에서, 메시지 윈도 크기(155)는 최종의 알려진 좋은 값(180)으로 판단되어 메모리(150)에 기억되고, 여기서, 증가된 메시지 윈도 크기(155)의 감소가 메시지 윈도 크기(155)보다 낮으므로, 메시지 윈도 크기(155)가 감소하게 된다. 또 다른 예시적인 실시예는 감소된 메시지 윈도 크기(155)에 대응하는 감소된 메시지 수를 송신하는 것을 제공한다. 감소된 메시지 윈도 크기(155)에 기초하여, 제2 예상 메시지 전송 시간이 식별되고(주: 송신된, 감소된 메시지 수가 존재하지만, 제2 예상 메시지 전송 시간은 네트워크 혼잡을 보상하기 위해 이전의 예상 메시지 전송 시간보다 증가할 수도 있다), 이 제2 예상 메시지 전송 시간은 감소된 메시지 수의 송신과 대응하는 확인 메시지의 수신 간의 예상 시한을 규정한다. 그 후, 제2 예상 메시지 전송 시간이 경과하기 전에, 감소된 메시지 수에 대한 하나 이상의 대응하는 확인 메시지가 수신된 것을 나타내는 표시가 제공될 수도 있다. 이와 같이, 메시지 윈도 크기(155)의 크기(즉, 최종의 알려진 좋은 값(180))가 메모리(150)에서 검색될 수 있고, 그 후, 감소된 메시지 윈도 크기(155)는 메시지 윈도 크기(155)로 증가된다.

그 후, 예시적인 실시예는, 메시지 윈도 크기(155)의 단일 조정(즉, 증분적인 증가 및 감소)에 의해 메시지 윈도 크기(155)를 미세 조정하는 것을 제공한다. 다른 예시적인 실시예는, 메시지 윈도 크기(155)가 최종의 알려진 좋은 값으로 판단되고, 증가된 메시지 윈도 크기의 감소가 메시지 윈도 크기(155)인 것을 제공한다.

다른 예시적인 실시예는, 대응하는 확인 메시지가 단일 메시지로 배치(batch)될 수도 있음을 제공한다. 이와 같은 경우, 예상 메시지 전송 시간은 메시지 수의 송신과 단일 메시지의 수신 간의 예상 메시지 전송 시한에 대한 평균 및/또는 분산에 기초한다.

또한, 본 발명의 범위 내의 실시예는, 컴퓨터 판독가능 매체 상에 기억된 컴퓨터 실행가능 명령 또는 데이터 구조를 실행하거나 갖는 컴퓨터 판독가능 매체를 포함한다. 이와 같은 컴퓨터 판독가능 매체는 범용 또는 전용 컴퓨터에 의해 접근될 수 있는 임의의 이용가능한 매체일 수 있다. 예로서, 이와 같은 컴퓨터 판독가능 매체는, RAM, ROM, EEPROM, CD-ROM 또는 다른 광 디스크 기억장치, 자기 디스크 기억장치 또는 다른 자기 디스크 기억장치, 또는 컴퓨터 실행가능 명령 또는 데이터 구조의 형태로 소망하는 프로그램 코드 수단을 실행하거나 기억하는데 이용될 수 있고 범용 또는 전용 컴퓨터에 의해 접근될 수 있는 임의의 다른 매체를 구비할 수 있지만 이에 한정되지는 않는다. 네트워크 또는 다른 통신 접속 수단(하드와이어(hardwired), 무선(wireless), 또는 하드와이어 또는 무선의 조합) 상에서 컴퓨터로 정보가 전송되거나 제공되는 경우, 컴퓨터는 그 접속 수단을 당연히 컴퓨터 판독가능 매체로서 본다. 따라서, 이와 같은 임의의 접속은 당연히 컴퓨터 판독가능 매체로 지칭될 수 있다. 또한, 상기 사항의 조합도 컴퓨터 판독가능 매체의 범위 내에 포함된다. 컴퓨터 실행가능 명령은, 예를 들어, 범용 컴퓨터, 전용 컴퓨터, 또는 전용 처리 장치로 하여금 일정 기능 또는 기능들의 그룹을 수행하도록 하는 명령 및 데이터를 포함한다.

도 4 및 다음 설명은, 본 발명이 구현될 수도 있는 적합한 컴퓨팅 환경의 간단하고, 일반적인 설명을 제공하려는 목적으로 제공된다. 필요한건 아니지만, 본 발명은, 네트워크 환경에서 컴퓨터에 의해 실행되는, 프로그램 모듈 등의, 컴퓨터 실행가능 명령의 일반적인 문맥에서 설명된다. 일반적으로, 프로그램 모듈은, 특정 작업을 수행하거나 특정 추상 데이터 타입을 구현하는 루틴, 프로그램, 객체, 구성요소, 데이터 구조 등을 포함한다. 컴퓨터 실행가능 명령, 결합된 데이터 구조, 및 프로그램 모듈은, 여기서 개시된 방법의 단계를 실행하기 위한 프로그램 코드 수단의 예를 나타낸다. 상기 실행가능 명령 또는 결합된 데이터 구조의 특정 시퀀스는 상기 단계에서 설명된 기능을 구현하기 위한 대응하는 행동의 예를 나타낸다.

당해 기술분야의 당업자는, 본 발명이, 개인용 컴퓨터, 핸드헬드 장치, 멀티프로세서 시스템, 마이크로프로세서 기반 또는 프로그램가능한 소비자 전자제품, 네트워크 PCs, 미니컴퓨터, 및 메인프레임 컴퓨터 등을 포함하는, 여러 타입의 컴퓨터 시스템 구성을 갖는 네트워크 컴퓨팅 환경에서 실시될 수도 있음을 알 수 있다. 또한, 본 발명은, 통신 네트워크를 통해 (하드와이어 링크(hardwired links), 무선 링크, 또는 하드와이어 링크 또는 무선 링크의 조합에 의해)링크되는 원거리 처리 장치에 의해 작업이 수행되는 분산 컴퓨팅 환경에서 실시될 수도 있다. 분산 컴퓨팅 환경에서, 프로그램 모듈은 근거리 및 원거리 메모리 기억장치에 위치할 수도 있다.

도 4를 참조하면, 본 발명을 구현하는 예시적인 시스템은, 처리 장치(421), 시스템 메모리(422), 및 시스템 메모리(422)를 포함한 여러 시스템 구성요소를 처리 장치(421)에 연결하는 시스템 버스(423)를 포함하는, 종래 컴퓨터(420)의 형태인 범용 컴퓨팅 장치를 포함한다. 시스템 버스(423)는 메모리 버스 또는 메모리 제어기, 주변 버스, 및 여러 버스 구조 중 어느 하나를 이용하는 버스를 포함하는 몇몇 타입의 버스 구조 중 어느 하나일 수도 있다. 시스템 메모리는 ROM(read only memory; 424) 및 RAM(random access memory; 425)를 포함한다. 예를 들어, 시동 동안, 컴퓨터(420) 내의 요소 간의 정보 전송을 돕는 기본 루틴을 포함하는, 기본 입출력 시스템(BIOS; 426)은 ROM(424) 내에 기억될 수도 있다.

또한, 컴퓨터(420)는, 자기 하드 디스크(439)로부터 판독하거나 이에 기입하는 자기 하드 디스크 드라이브(427), 제거가능 자기 디스크(429)로부터 판독하거나 이에 기입하는 자기 디스크 드라이브(428), 및 CD-ROM 등의 제거가능 광 디스크(431) 또는 다른 광 매체로부터 판독하거나 이에 기입하는 광 디스크 드라이브(430)를 포함할 수도 있다. 자기 하드 디스크 드라이브(427), 자기 디스크 드라이브(428), 및 광 디스크 드라이브(430)는, 각각, 하드 디스크 드라이브 인터페이스(432), 자기 디스크 드라이브 인터페이스(433), 및 광 디스크 드라이브 인터페이스(434)에 의해 시스템 버스(423)에 접속된다. 상기 드라이브 및 이와 결합된 컴퓨터 판독가능 매체는, 컴퓨터(420)를 위한, 컴퓨터 실행가능 명령, 데이터 구조, 프 로그램 모듈 및 다른 데이터의 비휘발성 기억장치를 제공한다. 여기서 설명된 예시적인 환경은 자기 하드 디스크(439), 제거가능 자기 디스크(429) 및 제거가능 광 디스크(431)를 채택하지만, 자기 카세트, 플래시 메모리 카드, DVD(digital versatile disks), 베르누이 카트리지, RAMs, 및 ROMs 등을 포함하는, 데이터를 기억하기 위한 다른 타입의 컴퓨터 판독가능 매체가 이용될 수 있다.

하나 이상의 프로그램 모듈을 포함하는 프로그램 코드 수단은, 하드 디스크(439), 자기 디스크(429), 광 디스크(431), ROM(424) 또는 운영 체계(435), 하나 이상의 애플리케이션 프로그램(436), 다른 프로그램 모듈(437), 및 프로그램 데이터(438)를 포함하는, RAM(425) 상에 기억될 수도 있다. 사용자는, 키보드(440), 포인팅 장치(442), 또는 마이크, 조이 스틱, 게임 패드, 위상 접시형 안테나, 및 스캐너 등의, 다른 입력 장치(도시안함)를 통해 컴퓨터(420)에 명령 및 정보를 입력할 수도 있다. 이들 및 다른 입력 장치는 시스템 버스(423)에 연결된 직렬 포트 인터페이스(446)를 통해 처리 장치(421)에 종종 접속된다. 다른 방법으로는, 입력 장치가, 병렬 포트, 게임 포트 또는 USB(universal serial bus) 등의, 다른 인터페이스에 의해 접속될 수도 있다. 또한, 모니터(447) 또는 다른 표시 장치도 비디오 어댑터(448) 등의, 인터페이스를 경유하여 시스템 버스(423)에 접속된다. 모니터에 추가하여, 통상, 개인용 컴퓨터는 스피커 및 프린터 등의, 다른 주변 출력 장치(도시안함)를 포함한다.

컴퓨터(420)는, 원거리 컴퓨터(449a 및 449b) 등의, 하나 이상의 원거리 컴퓨터와의 논리적 접속을 이용하여 네트워크 환경에서 동작할 수도 있다. 도 4에는 메모리 기억장치(450a 및 450b) 및 그와 결합된 애플리케이션 프로그램(436a 및 436b)만이 도시되어 있지만, 원거리 컴퓨터(449a 및 449b)는, 각각, 다른 개인용 컴퓨터, 서버, 라우터, 네트워크 PC, 피어 장치 또는 다른 공유 네트워크 노드일 수도 있고, 통상, 컴퓨터(420)와 관련하여 상술한 요소 중 다수 또는 모두를 포함할 수도 있다. 도 4에 도시된 논리적 접속은, 여기서 예로서 제시되는 LAN(local area network; 451) 및 WAN(wide area network; 452)을 포함하지만, 이에 한정되지는 않는다. 이와 같은 네트워킹 환경은 전 사무실 또는 전 기업 컴퓨터 네트워크, 인트라넷 및 인터넷에서 일반적이다.

LAN 네트워킹 환경에서 이용되는 경우, 컴퓨터(420)는 네트워크 인터페이스 또는 어댑터(453)를 통해 네트워크(451)에 접속된다. WAN 네트워킹 환경에서 이용되는 경우, 컴퓨터(420)는, 모뎀(454), 무선 링크, 또는 인터넷 등의 WAN(wide area network; 452) 상에서 통신을 확립하기 위한 다른 수단을 포함할 수도 있다. 내장형이거나 외장형일 수도 있는 모뎀(454)은, 직렬 포트 인터페이스(446)를 경유하여 시스템 버스(423)에 접속된다. 네트워크 환경에서, 컴퓨터(420)와 관련하여 설명된 프로그램 모듈, 또는 그 일부는 원거리 메모리 기억장치에 기억될 수도 있다. 도시된 네트워크 접속은 예시적이며 WAN(wide area network; 452) 상에서 통신을 확립하기 위한 다른 수단이 이용될 수도 있음을 알 수 있다.

본 발명은, 그 사상 또는 필수적인 특성으로부터 일탈함이 없이 다른 특정 형태로 구현될 수도 있다. 설명된 실시예는 모든 점에서 단지 설명하기 위한 것으로, 한정하려는 것은 아니다. 따라서, 본 발명의 범위는, 상술한 설명보다는 첨부 된 청구항에 의해 표현된다. 청구항의 등가물의 내용과 범위 내에 있는 모든 변화도 본 발명의 범위 내에 포함된다.

본 발명에 따라, 2개의 종단점 간의 흐름 제어 및 네트워크 와이어 상의 혼잡 제어를 위해 웹 서비스를 위한 신뢰성 있는 메시징 프로토콜에 따른 메시지의 효율적인 전송을 제공할 수 있다.

Claims

웹 서비스(Web Services) 환경 내의 컴퓨팅 시스템에서, 억셉터(acceptor)의 이용가능한 버퍼 크기에 기초하여 메시지들을 송신하기 위한 메시지 윈도 크기를 동적으로(dynamically) 결정함으로써 RM-WS 프로토콜(Reliable Messaging of Web Services protocol)에 따라 종단점들(endpoints) 간에 효율적으로 메시지를 전송하는 방법으로서,

애플리케이션에 의한 처리를 대기중인 메시지를 버퍼링하기 위한 이용가능한 메모리 양을 표시하는 억셉터 버퍼 크기 정보를 포함하는 메시지를, RM-WS 프로토콜에 따라 이니시에이터(initiator)와 억셉터 간에 확립된 시퀀스 세션상에서 상기 이니시에이터에 의해 수신하는 단계;

상기 RM-WS 프로토콜에 따라 대응하는 확인(acknowledgements)을 수신하지 않고 상기 억셉터로 송신된 인 플라이트 메시지들(in flight messages)의 개수를 상기 이니시에이터에 의해 식별하는 단계; 및

버퍼 오버런(buffer overrun)으로 인한 메시지 재송신을 방지하기 위해 상기 억셉터에 송신될 수 있는 메시지들의 개수의 상한을 표시하는 메시지 윈도 크기를 계산하기 위해 상기 억셉터 버퍼 크기 정보와 상기 인 플라이트 메시지들의 개수를 상기 이니시에이터에 의해 이용하는 단계를 포함하는,

메시지 전송 방법.
제1항에 있어서,

상기 억셉터 버퍼 크기 정보를 포함하는 메시지는 RM-WS 프로토콜 기반구조 메시지인,

메시지 전송 방법.
제2항에 있어서,

상기 애플리케이션에 의한 처리를 대기중인 메시지를 버퍼링하기 위해 할당된 상기 억셉터의 전체 메모리는 접속 기반(connection basis)마다 동적으로 구성가능한,

메시지 전송 방법.
제2항에 있어서,

0보다 큰 상기 메시지 윈도 크기에 기초하여, 계산된 상기 메시지 윈도 크기에 대응하는 개수의 메시지들을 상기 이니시에이터에 의해 송신하는 단계를 더 포함하는,

메시지 전송 방법.
제2항에 있어서,

0인 상기 메시지 윈도 크기에 기초하여, 기반구조 메시지를 이용하여 상기 메시지 윈도 크기가 0보다 크다는 것을 계산할 때까지 메시지들이 송신되는 것을 상기 이니시에이터에 의해 차단하는 단계를 더 포함하는,

메시지 전송 방법.
웹 서비스 환경 내의 컴퓨팅 시스템에서, 네트워크 대역폭, 성능 및 토폴로지의 변화에 적응하도록 RM-WS 프로토콜(Reliable Messaging of Web Services protocol)에 따라 이니시에이터로부터 억셉터로 메시지들을 송신하기 위한 전송 윈도(transmission window)를 조정함으로써 네트워크 혼잡(network congestion)을 제어하는 방법으로서,

네트워크 와이어(network wire) 상에서 상기 억셉터로 송신되는 인 플라이트 메시지들의 개수의 상한을 표시하는 메시지 윈도 크기에 대응하는 개수의 메시지들을, RM-WS 프로토콜에 따라 확립된 시퀀스 세션 상에서 상기 이니시에이터에 의해 상기 억셉터로 송신하는 단계;

상기 메시지 윈도 크기에 기초하여, 상기 대응하는 개수의 메시지들의 송신과 하나 이상의 대응하는 확인 메시지들의 수신 간의 예상 시한(expected time limit)을 규정하는 예상 메시지 전송 시간을 상기 이니시에이터에 의해 식별하는 단계; 및

상기 예상 메시지 전송 시간이 경과하기 전에 상기 하나 이상의 대응하는 확인 메시지들이 수신되었는지 여부에 관한 표시 - 상기 표시는 네트워크 혼잡으로 인한 메시지 재송신을 방지하기 위해 상기 메시지 윈도 크기 또는 메시지 재시도 시간 주기(message retry time period) 중 적어도 하나를 조정하는데 이용됨 - 를 상기 이니시에이터에 의해 제공하는 단계를 포함하는,

네트워크 혼잡 제어 방법.
제6항에 있어서,

상기 조정은, 상기 예상 메시지 전송 시간이 경과하기 전에 상기 하나 이상의 대응하는 확인 메시지들이 수신된 것을 표시하는, 상기 메시지 윈도 크기의 증가인

네트워크 혼잡 제어 방법.
제7항에 있어서,

상기 메시지 윈도 크기의 증가 후,

상기 방법은,

상기 증가된 메시지 윈도 크기에 대응하는 증가된 개수의 메시지들을 상기 이니시에이터에 의해 송신하는 단계;

상기 증가된 메시지 윈도 크기에 기초하여, 상기 증가된 개수의 메시지들의 송신과 하나 이상의 대응하는 확인 메시지들의 수신 간의 예상 시한을 규정하는 제2 예상 메시지 전송 시간을 상기 이니시에이터에 의해 식별하는 단계;

상기 제2 예상 메시지 전송 시간이 경과하기 전에 상기 증가된 개수의 메시지들에 대한 상기 하나 이상의 대응하는 확인 메시지들이 수신되었는지 여부에 관한 표시를 상기 이니시에이터에 의해 제공하는 단계; 및

상기 증가된 개수의 메시지들 중 하나 이상이 분실되는 것, 상기 증가된 개수의 메시지들에 대한 상기 하나 이상의 대응하는 확인 메시지들 중 하나 이상이 분실되는 것, 및 상기 제2 예상 메시지 전송 시간이 경과한 후 수신되는 것 중 적어도 하나를 표시하는, 상기 증가된 메시지 윈도 크기를 상기 이니시에이터에 의해 감소시키는 단계를 더 포함하는,

네트워크 혼잡 제어 방법.
웹 서비스 환경 내의 컴퓨팅 시스템에서, 네트워크 대역폭, 성능 및 토폴로지의 변화에 적응하도록 RM-WS 프로토콜(Reliable Messaging of Web Services protocol)에 따라 이니시에이터로부터 억셉터로 메시지들을 전송하는 전송 윈도를 조정함으로써 네트워크 혼잡을 제어하는 방법으로서,

네트워크 와이어 상에서 상기 억셉터로 송신되는 인 플라이트 메시지들의 개수의 상한을 표시하는 제1 메시지 윈도 크기에 대응하는 제1 개수의 메시지들을, RM-WS 프로토콜에 따라 확립된 시퀀스 세션 상에서 상기 이니시에이터에 의해 상기 억셉터로 송신하는 단계; 및

상기 제1 개수의 메시지들의 송신과 하나 이상의 대응하는 제1 확인 메시지들의 수신 간의 예상 시한을 규정하는 제1 예상 메시지 전송 시간의 경과 전에, 상기 제1 개수의 메시지들에 대한 상기 하나 이상의 확인 메시지들이 수신되었는지 여부에 기초하여, 네트워크 혼잡으로 인한 메시지 재송신을 방지하기 위해, 상기 이니시에이터에 의해 상기 제1 메시지 윈도 크기를 제2 메시지 윈도 크기로 조정하는 단계를 포함하는,

네트워크 혼잡 제어 방법.
제9항에 있어서,

상기 예상 메시지 전송 시간은 상기 메시지 윈도 크기에 기초하는,

네트워크 혼잡 제어 방법.
제9항에 있어서,

상기 메시지 윈도 크기의 조정은, 상기 예상 메시지 전송 시간이 경과하기 전에 상기 하나 이상의 대응하는 확인 메시지들이 수신된 것을 표시하는, 상기 메시지 윈도 크기의 증가인,

네트워크 혼잡 제어 방법.
웹 서비스 환경 내의 컴퓨팅 시스템에서, 억셉터의 이용가능한 버퍼 크기에 기초하여 메시지들을 송신하기 위한 메시지 윈도 크기를 동적으로 결정함으로써 RM-WS 프로토콜(Reliable Messaging of Web Services protocol)에 따라 종단점들 간에 효율적으로 메시지들을 전송하는 방법을 구현하기 위한 컴퓨터 실행가능 명령어들을 포함하는 컴퓨터 판독가능 기록매체로서,

상기 컴퓨터 실행가능 명령어들은

프로세서에 의한 실행시, 메시징 시스템으로 하여금,

애플리케이션 계층에서, RM-WS 프로토콜에 따라 이니시에이터와 억셉터 간의 시퀀스 세션을 확립하고;

애플리케이션에 의한 처리를 대기중인 메시지를 버퍼링하기 위한 이용가능한 메모리 양을 표시하는 억셉터 버퍼 크기 정보를 포함하는 메시지를 상기 시퀀스 세션 상에서 수신하고;

상기 RM-WS 프로토콜에 따라 대응하는 확인을 수신하지 않고 상기 억셉터로 송신된 인 플라이트 메시지들의 수를 식별하고;

버퍼 오버런으로 인한 메시지 재송신을 방지하기 위해 상기 억셉터로 송신될 수 있는 메시지들의 개수의 상한을 표시하는 메시지 윈도 크기를 계산하기 위해 상기 억셉터 버퍼 크기 정보와 상기 인 플라이트 메시지들의 개수를 이용하는 것을 수행하도록 하는,

컴퓨터 판독가능 기록매체.
제12항에 있어서,

상기 억셉터 버퍼 크기 정보를 포함하는 메시지는 RM-WS 프로토콜 기반구조 메시지인,

컴퓨터 판독가능 기록매체.
웹 서비스 환경 내의 컴퓨팅 시스템에서, 네트워크 대역폭, 성능 및 토폴로지의 변화에 적응하도록 RM-WS 프로토콜(Reliable Messaging of Web Services protocol)에 따라 종단점에 메시지들을 송신하는 전송 윈도를 조정함으로써 네트워크 혼잡을 제어하는 방법을 구현하기 위한 컴퓨터 실행가능 명령어들을 포함하는 컴퓨터 판독가능 기록매체로서,

상기 컴퓨터 실행가능 명령어들은

프로세서에 의한 실행시, 메시징 시스템으로 하여금,

네트워크 와이어 상에서 억셉터로 송신되는 인 플라이트 메시지들의 개수의 상한을 표시하는 메시지 윈도 크기에 대응하는 개수의 메시지들을, RM-WS 프로토콜에 따라 확립된 시퀀스 세션 상에서 상기 억셉터로 송신하고;

상기 메시지 윈도 크기에 기초하여, 상기 대응하는 개수의 메시지들의 송신과 하나 이상의 대응하는 확인 메시지의 수신 간의 예상 시한을 규정하는 예상 메시지 전송 시간을 식별하고;

상기 예상 메시지 전송 시간이 경과하기 전에 상기 하나 이상의 대응하는 확인 메시지가 수신되었는지에 관한 표시 - 상기 표시는 네트워크 혼잡으로 인한 메시지 재송신을 방지하기 위해 상기 메시지 윈도 크기 또는 재시도 시간 주기 중 적어도 하나를 조정하는데 이용됨 - 를 제공하는 것을 수행하도록 하는,

컴퓨터 판독가능 기록매체.
제14항에 있어서,

상기 조정은, 상기 예상 메시지 전송 시간이 경과하기 전에, 상기 하나 이상의 대응하는 확인 메시지들이 수신된 것을 표시하는, 상기 메시지 윈도 크기의 증가인,

컴퓨터 판독가능 기록매체.
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제