KR20120082430A - 접속 지향 순차 전송 환경에서 접속을 관리하기 위한 방법 및 시스템 - Google Patents

접속 지향 순차 전송 환경에서 접속을 관리하기 위한 방법 및 시스템 Download PDF

Info

Publication number
KR20120082430A
KR20120082430A KR1020127010820A KR20127010820A KR20120082430A KR 20120082430 A KR20120082430 A KR 20120082430A KR 1020127010820 A KR1020127010820 A KR 1020127010820A KR 20127010820 A KR20127010820 A KR 20127010820A KR 20120082430 A KR20120082430 A KR 20120082430A
Authority
KR
South Korea
Prior art keywords
message
server
client
connection
type
Prior art date
Application number
KR1020127010820A
Other languages
English (en)
Inventor
안드레이 라둘레스쿠
데스포 갈라타키
Original Assignee
에스티 에릭슨 에스에이
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
Priority claimed from US12/571,018 external-priority patent/US20110078255A1/en
Application filed by 에스티 에릭슨 에스에이 filed Critical 에스티 에릭슨 에스에이
Publication of KR20120082430A publication Critical patent/KR20120082430A/ko

Links

Images

Classifications

    • 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/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/12—Shortest path evaluation
    • H04L45/125—Shortest path evaluation based on throughput or bandwidth
    • 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/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/163—In-band adaptation of TCP data exchange; In-band control procedures
    • 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/28—Timers or timing mechanisms used in protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/72—Admission control; Resource allocation using reservation actions during connection setup
    • 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/14—Session management

Abstract

본 발명은 순차 전송 환경에서 클라이언트와 서버 사이의 접속을 설정하는 시스템 및 방법을 제공한다. 개시된 시스템 및 방법은 제 1 유형의 메시지를 서버에 송신함으로써 접속을 설정하는 것을 요구하도록 구성된 클라이언트를 포함하고, 서버는 서버가 접속되게 유도하는 제 2 유형의 메시지를 클라이언트에 송신함으로써 접속을 설정하는 능력을 확인하도록 구성된다. 제 1 유형의 메시지는 제 1 클라이언트 타이머를 시동하여 제 1 최대 응답 시간으로서 제 1 사전 정의된 기간을 측정하고, 제 2 유형의 메시지 또는 데이터 메시지의 수신은 제 1 클라이언트 타이머를 정지시킨다. 접속은 제 3 유형의 메시지를 송신함으로써 폐쇄된다.

Description

접속 지향 순차 전송 환경에서 접속을 관리하기 위한 방법 및 시스템{METHOD AND SYSTEM FOR MANAGING A CONNECTION IN A CONNECTION ORIENTED IN-ORDER DELIVERY ENVIRONMENT}
관련 출원의 상호 참조 및 우선권의 주장
본 출원은 발명의 명칭이 "순차 전송 환경에서 배향된 접속에서 접속을 관리하기 위한 방법 및 시스템(METHOD AND SYSTEM FOR MANAGING A CONNECTION IN A CONNECTION ORIENTED IN-ORDER DELIVERY ENVIRONMENT)"인 2009년 9월 30일 출원된 미국 특허 출원 제 12/571,018호의 일부 계속 출원이다. 미국 특허 출원 제 12/571,018호는 본 출원의 양수인에게 양도되어 있고 본 명세서에 완전히 설명되어 있는 것처럼 본 출원에 참조로서 포함되어 있다. 본 출원은 이에 의해 미국 특허 출원 제 12/571,018호의 35 U.S.C. §119(e) 하에서 우선권을 주장한다.
기술 분야
본 발명은 통신 가능한 아이템의 순차 전송을 특징화하는 네트워크에 의해 상호 접속된 다중 부품 시스템 내의 부품 사이의 통신을 위한 방법 및 시스템에 관한 것이다.
현재 개발되고 있는 고집적 시스템에서, 고대역폭 통신 능력이 성능 요구로서 필수적이다. 더욱이, 제 2 소스 원리를 추구하는 시스템 개발자는 임의의 제조업자로부터 그 디자인의 구성 요소를 선택하는 것이 가능해야 하고, 동시에 완벽하게 이들이 상호 운용되는 것을 요구한다. 이는 그 구성 요소 및 상호 통신을 위한 표준을 정의하는 분야에서 활동하는 복수의 제조업자에 의해 설립된 표준화 기구의 형성을 유도한다. 하나의 이러한 표준화 기구는 모바일 산업 프로세서 인터페이스 연합(MIPI
Figure pct00001
)이다. 현재 이 기구는 모바일 시스템 상호 통신의 상세에 대해 종사하는 대략 150개의 제조업자로 이루어져 있다. 몇몇 정보는 월드와이드웹의 http://www.mipi.org/에서 입수 가능할 수 있다.
구성 요소간 통신을 표준화하기 위해, MIPI
Figure pct00002
연합은 모바일 시스템 내의 디바이스들을 접속하기 위한 직렬 고속 링크로서 UniProSM를 정의하였다. UniProSM 표준은 지속적으로 개발중에 있고, 현재 표준 버전 1.0이 발표되어 있다. 표준의 다양한 버전의 특징에 대한 몇몇 정보는 월드와이드웹의 http://en.wikipedia.org/wiki/Unipro에서 인터넷 백과사전에서 입수 가능하다.
상호 접속 및 통신 표준을 제공함으로써, 제조업자들은 이들의 시스템을 개발하는데 있어 훨씬 더 융통성이 있고, 상이한 요구에 양호하게 적합되고 상이한 판매자에 의해 제공되는 구성 요소를 혼합하여 정합하는 것이 가능하다. UniPro 표준 또는 통합 프로토콜(Unified Protocol)은 고속 직렬 링크를 사용하는 칩간 네트워크(chip-to-chip network)에 관련된다. 이는 에러 처리, 흐름 제어, 라우팅 및 중재와 같은 일반적인 상호 접속 문제점을 해결하는 범용 통신 프로토콜이 되도록 정의된다.
현재, UniPro는 접속이 셋업되도록 요구하면서 동시에 상태 및 버퍼와 같은 다른 리소스를 할당하는 접속 지향 통신을 제공한다. 일반적으로, 접속은 통신에 수반된 버퍼들이 오버플로우하는 것을 방지하기 위해 크레디트 종단간 흐름 제어를 구현한다. 이러한 것은 어떠한 데이터 손실 또는 오손도 없는 것을 보증하는 신뢰적인 네트워크의 사용과 조합하여, 사용자에게 신뢰적인 통신 서비스를 보장한다.
UniPro 버전의 미래의 개발에 대해, 레이어 2 재전송의 수를 제한하는 것은 전송되지 않는 매우 작은 확률의 데이터의 조각을 생성하기 때문에, 레이어 2 재전송의 수를 제한하는 결과를 갖고 실시간 트래픽 클래스를 제공하여, 이에 의해 데이터 전송 자체에 대한 보증을 희생함으로써 패킷의 전송을 위한 시간 한계를 보장하는 것이 예측 가능하다. UniPro 애플리케이션의 더 높은 레이어는 이들이 대응 보고를 수신할 때 조각을 누락하는 것을 주의해야 할 것이다. 접속 지향 통신에 기초하는 신뢰적인 실시간 트래픽 클래스는 접속 유지를 시작하고 종료하기 위한 프로토콜을 필요로 한다. 현재 전송 제어 프로토콜(TCP)로부터 3방향 핸드셰이크가 공지되어 있다. 상세는 1981년 9월, IETF 코멘트 요구 #793, 미국 서던 캘리포니아 대학교, 정보 과학 대학에 의한 전송 제어 프로토콜, DARPA 인터넷 프로그램, 프로토콜 사양에 공개되어 있다. 그러나, TCP는 네트워크에 고유한 높은 비신뢰성에 대처해야 하기 때문에 통합 프로토콜과는 상당히 상이하고 따라서 이러한 비신뢰성에 대처하기 위해 프로토콜에서 예방책을 취해야 할 필요가 있다. TCP는 또한 예를 들어 패킷이 네트워크 내에 상이한 라우트를 취할 수 있기 때문에 데이터 전송에서 어떠한 순서도 취하지 않는다. 따라서, TCP는 접속의 관리를 보장하기 위해 매우 큰 시퀀스 번호 뿐만 아니라 최대 패킷 수명을 사용한다. 그러나, UniPro는 통상적으로 최대 10개의 노드의 작은 네트워크에서 대부분 동작하고 순차 통신을 제공한다. 따라서, 정상 프로토콜에서보다 적은 오버헤드를 사용하고 기능성을 희생하지 않고 단순성을 성취하는 것이 가능하다.
액세스 신호화를 위한 B-ISDN 애플리케이션 프로토콜에서 ITU-T Q.2931에 개시되어 있는 ATM 접속 셋업이 또한 공지되어 있다(ITU-T 추천 Q.2931, 1995년 2월). 관련 접속 셋업은 ATM에 참조라 칭하는 시퀀스 번호를 사용하여 TCP 내에 사용된 것과 유사한 메커니즘을 사용하지만, ATM은 또한 메시지 오버헤드를 생성하고 따라서 통신 채널로부터 대역폭을 취하는 큰 시퀀스 번호에 기초한다.
본 발명의 목적은 리소스의 적절한 할당 및 메시지 오버헤드의 최소값을 갖는 접속의 설정 및 종료를 허용하는 접속 지향 순차 전송 환경에서 접속을 관리하기 위한 대안적인 방법 및 시스템을 제공하는 것이다.
이 문제점은 접속 지향 순차 전송 환경에서 접속을 관리하기 위한 방법으로서,
a) 클라이언트가 제 1 유형의 메시지(1140)를 서버에 송신함으로써 접속을 설정하는 것을 요구하고,
b) 서버는 서버가 접속되게 유도하는 제 2 유형의 메시지를 클라이언트에 송신함으로써 접속을 설정하는 능력을 확인하고,
c) 제 1 유형의 메시지를 송신하는 것은 제 1 클라이언트 타이머를 시동하여 제 1 최대 응답 시간으로서 제 1 사전 정의된 기간을 측정하고, 제 2 유형의 메시지 또는 데이터 메시지를 수신하는 것은 제 1 클라이언트 타이머를 정지시키고,
d) 접속은 제 3 유형의 메시지를 송신함으로써 폐쇄되는 접속 지향 순차 전송 환경에서 접속을 관리하기 위한 방법에 의해 해결된다.
본 발명은 또한 접속 지향 순차 전송 환경에서 접속을 관리하기 위한 시스템으로서,
서버, 클라이언트, 순차 전송을 갖는 네트워크를 포함하고, 서버는 서버에 연관된 전술된 방법의 임의의 동작을 수행하도록 적용되고, 클라이언트는 클라이언트에 연관된 전술된 방법의 임의의 동작을 수행하도록 적용되는 접속 지향 순차 전송 환경에서 접속을 관리하기 위한 시스템을 또한 제공한다.
본 발명은 서버, 클라이언트, 라우터 등에 본 발명의 임의의 방법을 수행하기 위한 컴퓨터 프로그램 제품을 포함한다.
본 발명은 또한 전술된 컴퓨터 프로그램 제품을 저장하는 비일시적 머신 판독 가능 신호 저장 매체를 포함한다. 예를 들어, 비일시적 머신 판독 가능 신호 저장 매체는 CDROM, DVDROM과 같은 광학 디스크, 자기 테이프 메모리, 하드 디스크 또는 디스켓과 같은 자기 디스크 메모리, USB 메모리 스틱, 플래시 메모리와 같은 고상 메모리일 수 있다.
본 발명의 유리한 다른 실시예는 종속 청구항에 제공된다.
편리하게는 본 발명에 따른 방법은 최소 수의 메시지를 제공하고, 서버에 의한 제 1 메시지의 누락을 보호한다. 이 방식으로, 신뢰적인 네트워크를 사용하여 방법은 예를 들어 다른 접속을 프로세싱하는 것에 기인하여 접속을 처리하기 위해 이용 가능한 어떠한 리소스도 갖지 않는 비지 서버에 대해 보호한다.
편리하게는, 본 발명에 따른 방법의 다른 실시예에 따르면, 제 1 사전 정의된 기간이 만료되는 경우에, 다른 제 1 유형의 메시지가 서버에 송신되어 최단 가능한 시간 이내에 접속의 설정을 보장하고 동시에 충분한 양의 프로세싱 시간을 서버에 허용하면서 제 1 전송시에 서버에 의한 제 1 유형의 메시지의 누락을 취급한다.
유리하게는, 본 발명에 따른 방법의 다른 실시예에 따르면, 제 2 유형의 메시지를 수신하는 것은 클라이언트가 접속되게 유도하고, 반면에 제 4 유형의 메시지를 송신하는 것은 방법이 비신뢰적인 네트워크 또는 실시간 트래픽 클래스를 취급하게 하여 확인 메시지가 수신되어 있는 것을 서버에 통신한다.
유리하게는, 서버로부터 클라이언트로의 제 2 유형의 메시지의 형태의 본 발명의 방법의 다른 실시예에 따른 확인 메시지는 이 메시지의 손실로부터 접속 설정을 보호하기 위해 제 2 사전 정의된 기간을 측정하는 제 1 서버 타이머에 의해 안전화되고, 서버로부터의 확인 메시지가 수신되는 것에 대한 클라이언트로부터의 확인으로서 제 4 유형의 메시지를 수신하는 것은 제 1 서버 타이머를 정지시킨다. 이 방식으로 최소 수의 메시지가 접속의 확실한 설정을 보장한다.
편리하게는, 본 발명에 따른 방법의 다른 실시예에 따르면, 서버는 제 5 유형의 메시지를 생성하고 다른 접속 또는 다른 애플리케이션의 높은 프로세싱 부하를 취급하는 것에 기인하여, 이용 불가능한 리소스에 기인하여 접속을 설정할 수 없는 경우에 이 메시지를 클라이언트에 송신한다. 이 메시지는 클라이언트에서 수신될 때 유리하게 접속을 폐쇄할 수 있게 하고 따라서 서버가 이용 불가능한 동안 정의된 상태로 클라이언트를 배치하는 방법을 제공한다.
유리하게는, 본 발명에 따른 방법의 다른 실시예에 따르면, 제 3 유형의 메시지가 송신될 때 일단 제 3 유형의 메시지에 대한 어떠한 응답도 제 3 사전 정의된 기간에 수신되지 않으면, 접속의 정의된 종료를 보장하고 적절한 측정을 취하기 위해, 제 3 사전 정의된 기간을 측정하는 제 2 클라이언트 타이머가 시동된다.
유리하게는, 본 발명에 따른 방법의 다른 실시예에 따르면, 서버가 제 3 유형의 메시지를 수신할 때, 이는 제 3 유형의 메시지의 수신을 확인하기 위해 클라이언트에 제 6 유형의 메시지를 송신하고 따라서 밀접하게 구조화된 처리 및 접속 설정 및 종료의 관리가 보장된다.
편리하게는, 본 발명에 따른 방법의 다른 실시예에 따르면, 제 6 유형의 메시지의 송신은 일단 비신뢰적인 네트워크가 메시지 및 실시간 통신을 위해 트래픽 클래스를 갖는 네트워크를 각각 전송하기 위해 사용되면, 이 경우에 클라이언트와의 보안 통신을 안전하게 하기 위해 제 2 서버 타이머를 시작한다.
유리하게는, 본 발명의 방법의 다른 실시예에 따르면, 제 2 클라이언트 타이머는 일단 제 6 유형의 메시지를 수신하면 정지되고, 따라서 서버가 접속을 폐쇄하는 동시에 제 7 유형의 메시지가 제 6 유형의 메시지의 수신을 확인하고 서버에서 뿐만 아니라 클라이언트에서 정의된 상태를 보장하기 위해 서버에 송신되는 것을 인지한다.
유리하게는, 본 발명의 방법의 다른 실시예에 따르면, 클라이언트와 서버 사이에 교환된 임의의 메시지는 라우터를 통해 통과하는 것이 가능하여, 애플리케이션 및 트래픽 클래스 각각에 따라 접속을 위한 요구된 대역폭을 정의하는 동시에 클라이언트와 서버 사이의 통신의 탄력성을 향상시킨다. 동시에, 라우터는 일단 요구 대역폭이 이용 가능하면 수신된 메시지만을 포워딩하는 것을 제공한다.
편리하게는, 본 발명에 따른 방법의 다른 실시예에 따르면, 일단 라우터가 요구 대역폭을 제공하도록 이용 가능하면, 이는 다른 서버 및 클라이언트로부터의 통신을 거절하면서 클라이언트에 의해 어드레스되는 서버로부터 확인 메시지를 수신할 때까지 다른 대역폭 할당에 대해 보호한다. 이 방식으로, 대역폭 할당은 다른 잠재적인 통신 파트너에 의한 액세스로부터 보장된다.
유리하게는, 본 발명에 따른 방법의 다른 실시예는 클라이언트가 클라이언트에서 메시지를 개시하는 애플리케이션 클라이언트에 의해 어드레스될 수 있게 하고, 반면 서버는 애플리케이션 서버와 통신하여, 따라서 애플리케이션 클라이언트와 애플리케이션 서버 사이의 설정된 접속을 경유하여 데이터 교환을 제공하기 위해 통신 설정을 위해 메시지를 교환하는 클라이언트 및 서버에 의해 애플리케이션 서버와 애플리케이션 서버 사이의 통신을 설정한다.
유리하게는, 본 발명에 따른 시스템은 본 발명에 따른 방법의 동작을 실행하기 위해 최소 구성에서 순차 전송을 서버 및 클라이언트 뿐만 아니라 네트워크에 제공한다.
유리하게는, 본 발명에 따른 시스템의 다른 실시예는 본 발명에 따른 방법의 실시예를 사용하면서 클라이언트와 서버 사이의 탄력성 및 통신 거리를 확장하기 위해 라우터를 제공한다.
유리하게는, 본 발명의 시스템의 다른 실시예에 따르면, 통신 중에 동시에 사용되지 않는 확인 응답 메시지는 단지 하나의 포맷에서 하나의 메시지로서 저장되고 통신 환경에서 서버 및 클라이언트 각각에 정확한 활동을 제공한다. 마찬가지로, 동시에 동작하지 않는 서버 타이머 및 클라이언트 타이머는 또한 단지 요구될 때 활성화되고 이어서 본 발명의 방법 및 그 실시예에 따른 메시지 교환시에 제 1 및 제 2 서버 클라이언트 타이머 각각을 구현하는 각각의 하나의 서버 타이머 및 하나의 클라이언트 타이머로서 구현될 수 있다.
본 발명의 실시예의 이하의 예는 도면에 도시된 예에 기초하여 더 설명될 것이다.
도 1은 신뢰적인 네트워크에서 발생하는 통상의 메시지 교환을 도시하는 도면.
도 2는 신뢰적인 네트워크 내의 상태 및 상태 전이의 예를 도시하는 상태 머신을 도시하는 도면.
도 3은 신뢰적인 네트워크 내의 서버의 상태 및 상태 전이의 예를 도시하는 도면.
도 4는 비신뢰적인 네트워크 내의 예로서 메시지 흐름을 도시하는 도면.
도 5는 비신뢰적인 네트워크 내의 클라이언트의 예로서 상태 및 상태 전이를 도시하는 도면.
도 6은 비신뢰적인 네트워크 내의 서버의 상태 및 상태 전이의 예를 도시하는 도면.
도 7은 대역폭 할당을 포함하는 서버 클라이언트와 라우터 사이의 메시지 흐름의 예를 도시하는 도면.
도 8은 메시지가 라우터를 통해 통과하는 동안 비신뢰적인 네트워크 내의 클라이언트와 서버 사이의 메시지 흐름의 예를 도시하는 도면.
도 9는 메시지 흐름 내의 라우터를 포함하는 비신뢰적인 네트워크 내의 클라이언트의 예로서 상태 및 상태 전이를 도시하는 도면.
도 10은 메시지 흐름 내의 라우터를 포함하는 비신뢰적인 네트워크 내의 예로서 서버의 상태 및 상태 전이를 설명하는 도면.
도 11은 비신뢰적인 네트워크 내의 클라이언트와 서버 사이의 메시지 흐름 내에 포함된 라우터의 예로서 상태 및 상태 전이를 도시하는 도면.
도 12는 서버가 비지 상태일 때 신뢰적인 네트워크 내의 클라이언트와 서버 사이의 메시지 교환의 예를 도시하는 도면.
도 13은 제 1 유형의 메시지가 손실될 때 클라이언트와 서버 사이의 메시지 교환의 예를 도시하는 도면.
도 14는 제 2 유형의 메시지가 손실될 때 클라이언트와 서버 사이의 메시지 교환의 예를 제공하는 도면.
도 15는 서버 애플리케이션이 크래쉬(crash)되어 있는 클라이언트와 서버 사이의 메시지 흐름의 예를 도시하는 도면.
도 16은 서버가 비지 상태인 비신뢰적인 네트워크 내에서 클라이언트와 서버 사이의 메시지 흐름의 예를 제공하는 도면.
도 17은 프로토콜 에러가 발생하는 클라이언트와 서버 사이의 메시지 교환의 예를 도시하는 도면.
도 18은 라우터를 포함하는 비신뢰적인 네트워크 내에서 발생하는 제 1 에러의 예를 도시하는 도면.
도 19는 경로 상에 라우터를 포함하는 클라이언트와 서버 사이의 통신에서 발생하는 예로서 제 2 에러를 도시하는 도면.
도 20은 그 사이에 라우터를 갖는 클라이언트와 서버 사이에 발생하는 통신 에러의 제 3 예를 도시하는 도면.
도 21은 클라이언트와 서버 사이의 통신시에 발생하는 통신 에러의 제 4 예를 제공하는 도면으로서, 메시지 교환은 라우터를 통해 통과하는 도면.
도 22는 비신뢰적인 네트워크 내의 예로서 다른 메시지 흐름을 도시하는 도면.
도 23은 비신뢰적인 네트워크 내의 예로서 다른 메시지 흐름을 도시하는 도면.
본 발명이 특정 실시예를 참조하여 그리고 특정 도면을 참조하여 설명될 것이지만, 본 발명은 이에 한정되는 것은 아니라 청구범위에 의해서만 한정된다. 설명된 도면은 단지 개략적이고 비한정적이다. 도면에서, 일부 요소의 크기는 예시를 목적으로 과장되고 실제 축적대로 도시되어 있지 않을 수 있다.
도 2, 도 3, 도 5, 도 6, 도 9, 도 10 및 도 11에서와 같이 상태 머신과 관련하는 도면의 설명 전체에 걸쳐, 효율을 위해, 이하의 구문이 상태 전이 및 이에 의해 생성된 이벤트의 트리거를 설명하기 위해 사용된다.
<trigger>/<action>과 같은 포맷이 상태 기계 내의 표기법을 위해 사용된다. 여기서 <trigger>는 대응 트랜잭션을 유도하는 트리거로서 기능하는 입력 트리거의 플레이스홀더(placeholder)로서 기능한다. 또한 <action>은 트랜잭션과 연관되는 최종 이벤트의 세트를 위한 플레이스홀더로서 기능한다.
용어 "포함하는"이 본 상세한 설명 및 청구범위에 사용되는 경우, 이는 다른 요소 또는 단계를 배제하는 것은 아니다. 더욱이, 상세한 설명 및 청구범위에서 용어 제 1, 제 2, 제 3 등은 유사한 요소를 구별하기 위해 사용되고, 반드시 순차적인 또는 연대적인 순서를 설명하기 위한 것은 아니다. 이와 같이 사용된 용어는 적절한 상황 하에서 상호 교환 가능하고, 본 명세서에 설명된 본 발명의 실시예는 본 명세서에 설명되거나 예시된 것과는 다른 시퀀스로 동작 가능하다는 것이 이해되어야 한다.
도 1은 신뢰적인 네트워크 내의 본 발명의 실시예에 따른 접속 관리를 위한 메시지 흐름의 예를 도시한다. 도면의 설명 전체에 걸쳐, 동일한 도면 부호가 모든 도면에서 동일한 객체에 대해 사용될 수 있고 그 중복 설명은 효율을 위해 생략될 것이다.
도 1에 예시된 바와 같이, 애플리케이션 클라이언트(1000)는 신뢰적인 네트워크를 사용하여 클라이언트(1100), 서버(1200) 및 애플리케이션 서버(1300)와 통신한다. 네트워크는 간단한 링크일 수 있고, 또는 하나 이상의 라우터를 포함할 수 있다. 그러나, 간단화를 위해, 어떠한 라우터도 도 1에 도시되어 있지 않다. 애플리케이션 클라이언트(1000)는 이 때 접속의 설정을 개시하기 위해 "C_Closed"의 상태(1130)에 있는 클라이언트(1100)에 메시지(1010) "T_OPEN.req"를 송신한다. 클라이언트(1100)에서, 제 1 타이머는 일단 이 때 "S_Listen" 상태에 있는 서버(1200)에 제 1 유형의 메시지(1140) "T_SYN"이 송신되면 시동된다. 서버는 취급이 가능한 경우에 데이터가 서버에 메시지(1320) "T_OPEN. rsp"로 답변하는 애플리케이션 서버(1300)에 메시지 "T_OPEN.ind"를 생성한다. 서버(1200)는 상태(1220) "S_WaitRsp"에 있는 동안에 제 1 서버 타이머로 메시지(1310, 1320) 사이의 시간 간격을 측정한다. 메시지(1320)를 수신하면 제 1 서버 타이머는 정지되고, 이는 제 2 사전 정의된 기간을 측정하고, 상태(1120) "C_WaitAck"에 있고 메시지(1020) "T_OPEN.cnf"를 생성하는 메시지(1140)가 생성될 때 시동되어 있는 제 1 클라이언트 타이머를 정지하는 제 2 유형의 메시지(1150) "T_SYN_Ack"가 클라이언트(1100)에 송신된다. 이제 상태(1230) "S_Connected"에 있는 서버(1200)가 이제 접속된다. 이제, 애플리케이션 클라이언트는 확인 메시지(1040) "T_DATA.cnfL"로 클라이언트(1100)에 의해 확인되는 데이터(1030) "T_DATA.req"의 전송을 위한 요구의 송신을 시작한다. 서버(1200)는 전송된 데이터(1160) "T_DATA"를 수신하고, 서버를 "S_Connected" 상태로, 클라이언트를 "T_Connected" 상태(1110)로 방치하는 메시지(1340) "T_DATA.rspL"로 응답하는 애플리케이션 클라이언트(1330)로부터의 데이터 "T_DATA.ind"를 애플리케이션 서버에 송신한다.
데이터는 또한 메시지(1350) "T_DATA.req"를 서버(1200)에 송신함으로써 애플리케이션 서버로부터 요구될 수 있고, 이는 메시지(1160) "T_DATA"로서 클라이언트(1100)로 포워딩되고 거기로부터 "C_Connected" 상태(1110)에 있는 클라이언트(1100)로 메시지(1060) "T_DATA.rspL"로 응답하도록 애플리케이션 클라이언트를 프롬프트하는 메시지 "T_DATA.ind"(1050)로서 애플리케이션 클라이언트로 포워딩된다.
접속을 종료하기 위해, 애플리케이션 클라이언트는 상태(1240) "S_Listen"로 서버를 전송하는 메시지(1380) "T_CLOSE.rspL"로 서버(1300)에 의해 확인되는 접속 폐쇄(1370) "T_CLOSE.ind"의 지시를 갖고 애플리케이션(1300)에 응답하는 서버(1200)에 제 3 유형의 메시지(1170) "T_FIN"을 생성하는 메시지(1080) "T_CLOSE.cnfL"로 클라이언트(1100)에 의해 확인된 메시지(1070) "T_CLOSE.req"를 송신한다. 대안적으로, 접속은 이것이 메시지(1070) "T_CLOSE.req"[메시지(1080) "T_CLOSE.cnfL"에 의해 확인됨]로 애플리케이션 서버(1300)에 의해 요구될 때 메시지(1170) "T_FIN"을 송신함으로써 서버(1200)에 의해 폐쇄될 수 있고 메시지(1370) "T_CLOSE.ind"[메시지(1380) "T_CLOSE.rspL"로 응답됨]로 지시될 수 있다. 일반적으로, 실시예에서 각각의 메시지 흐름은 서버 및 클라이언트에 관하여 반전될 수 있는데, 즉 서버 및 클라이언트는 교환될 수 있다.
클라이언트는 상태(1130) "C_Closed"로 유지된다. 메시지(1140, 1150) 사이의 타이머는, 메시지를 프로세싱하기 위해 이용 가능한 리소스가 존재하지 않는 경우에 제 1 유형의 메시지(110)가 서버에 의해 누락될 수 있기 때문에 신뢰적인 네트워크가 통신의 기초를 형성하더라도 요구된다. 타이머는 메시지(1310, 1320) 사이의 서버에 의해 동작하여, 통신에 요구되는 애플리케이션 서버에서의 애플리케이션이 크래쉬되거나 다른 이유로 이용 가능하지 않으면 제 2 사전 정의된 기간이 감독을 위해 이용 가능한 것을 측정한다.
편리하게, 클라이언트(1100)는 메시지(1140)를 송신한 후에 도달하는 경향이 있는 메시지(1150)의 수신을 위한 리소스를 제공한다. 이 방식으로 유리하게 서버(1200)에서 어떠한 타이머도 메시지(1150)의 적절한 전송을 감독하도록 요구되지 않는다. 유사하게, 클라이언트(1100) 및/또는 서버(1200)는 메시지(1170)의 수신/처리를 위한 리소스를 제공해야 한다. 이 방식으로, 메시지(1170)의 송신자는 메시지(1170)의 전송 손실에 대해 보호하기 위해 타이머를 필요로 하지 않는다.
도 2는 클라이언트에 의해 채택될 수 있는 상태 및 상태 전이의 예로서 도 1에 도시된 메시지 흐름에 연관된 상태 머신을 도시한다.
이 설명에서 상태 머신의 표기법을 더 설명하기 위해, 도 2를 참조하는 예가 제공되는데, 이는 그러나 상태 머신을 표현하는 다른 도면에 유사한 방식으로 또한 적용 가능하다.
여기서, 도 2에서, 상태(1130)로부터 상태(1120)로의 클라이언트 전이(2100)는 애플리케이션 클라이언트(1000)로부터 T_OPEN.req (my_server)의 수신에 의해 트리거링되고, 또한 서버(1200)로의 전송 T_SYN (to:my_server) 및 클라이언트(1100)에서의 Timer_SYN의 시동을 유도한다. 상기 표기법에서, 이는 2100: T_OPEN.req (my_server) / T_SYN (to :my_server), start Timer_SYN으로서 나타낸다.
예로서, 전이(2200)를 위한 트리거 이벤트는 Timer_SYN의 만료이고, 또한 서버(1200)에 T_SYN (to:my_server)를 전송하고 클라이언트(1100)에서 Timer_SYN를 재시동하는 것을 유도한다. 이는 2200: timeout Timer_SYN / T_SYN (to:my_server), restart Timer_SYN으로서 나타낸다.
상태(1130)에 있는 상태로, 클라이언트는 2100: T_OPEN.req (my_server) / T_SYN (to:my_server), start Timer_SYN에 대응하는 상태(1120) "C_WaitWynAck"로 전달할 수 있다. 클라이언트는 2200: timeout Timer_SYN / T_SYN (to:my_server), restart Timer_SYN에 대응하는 상태(1120)에 유지되고, 반면에 상태(1130)로의 재전이는 2150: T_SYN_ERR from:my_server) / T_OPEN.cnf (error), stop Timer_SYN에 따라 발생한다. 상태(1120)로부터 상태(1110) "C_Connected"로의 전이는 2300: T_SYN_ACK (from:my_server) / T_OPEN.cnf (ok), stop Timer_SYN 또는 2300: T_DATA (from:my_server) / T_OPEN.cnf (ok), stop Timer_SYN, T_DATA.ind에 따라 발생하고, 반면에 클라이언트는 2400: T_DATA.req / T_DATA (to:my_server), 또는 2400: T_DATA (from:my_server) / T_DATA.ind에 대응하여 상태(1110)에 체류하고, 2500: T_CLOSE.req () / T_CLOSE.cnf, T_FIN (to:my_server)에 의해 상태(1130)로 전이한다.
도 3은 서버가 도 1에 도시된 메시지 흐름의 콘텍스트에서 채택될 수 있는 상태 및 상태 전이의 예로서 상태 머신을 도시한다.
상태 "S_WaitCloseRspE"(3220), 상태(3420) "S_Error", 상태(1220) "S_WaitOpenRsp", 상태(1230) "S_Connected" 및 다른 상태(3320) "S_WaitCloseRsp" 및 상태(1210) "S_Listen"이 도시되어 있다.
상태(1210)로부터 상태(1220)로의 전이는 3350: T_SYN (from:my_client) / T_OPEN.ind (my_client), start Timer_Rsp에 의해, 상태(1220)로부터 상태(3420)로의 전이는 3200: timeout Timer_Rsp / stop Timer_Rsp, T_SYN_ERR (to:my_client)에 의해, 그리고 상태(1220)로부터 상태(1230)로의 전이는 3300: T_OPEN.rsp () / stop Timer_Rsp, T_SYN_ACK (to:my_client)에 대응하여 발생한다. 상태(3420)로부터 상태(3220)로의 상태 전이는 3100: T_OPEN.rsp () / T_CLOSE.ind ( )에 따라 발생한다.
상태(1230)로부터 상태(3320)로의 추가의 전이는 3450: T_FIN (from:my_client) / T_CLOSE.ind ()에 대응하여, 상태(3320)로부터 상태(1210)의 전이는 3550: T_CLOSE.rsp / T_FIN (to:my_client)에 의해 발생한다. 상태(1210)는 3650: T_LISTEN.req / -에 의해 초기에 트리거링된다. 서버는 전이(3150): T_SYN (from: any_client) / T_SYN_ERR (to:any_client)에 따라 상태(3420)에 체류한다. 서버는 전이(3400): T_DATA.req (data) / T_DATA (to:my_client, data), 또는 3400: T_DATA (from:my_client, data) / T_DATA.ind (data), 또는 3400: T_SYN (from:my_client) / T_SYN_ACK (to:my_client) 또는 3400: T_SYN (from:other_client) / T_SYN_ERR (to:other_client)에 따라 상태(1230)에 체류한다. 서버는 전이(3500): T_DA A.req (data) / T_DATA (to:my_client, data), 또는 3500: T_SYN (from:other_client) / T_SYN_ERR (to:other_client)에 따라 상태(3320)에서 체류한다.
예를 들어, 상태(3320)에서, 서버는 데이터를 송신하는 것이 여전히 가능하지만, 클라이언트로부터 임의의 더 많은 데이터를 수신하지 않을 수 있다.
도 4는 레이어 2 재전송의 수를 제한하는 네트워크 및 비신뢰적 네트워크 각각에서 발생하는 본 발명에 따른 실시예의 메시지 흐름의 예를 도시한다.
도 1과 비교하여 용이하게 식별될 수 있는 바와 같이, 교환되는 대부분의 메시지는 동일하다. 이 사실에 기인하여, 비신뢰적인 네트워크 내에 접속을 설정하기 위해 요구되는 메시지로부터 신뢰적인 네트워크 내에서 요구되는 메시지를 분리하는 메시지 흐름의 차이에 초점이 맞춰진다. 비신뢰적인 네트워크의 경우에, 부가의 타이머 및 메시지가 바람직하게는 접속의 설정을 보장하고 비신뢰성을 보상하기 위해 제공된다. 이 경우에, 클라이언트(1100)는 제 4 유형의 메시지(4150) "T_ACK_ACK"를 생성한다. 이 제 4 유형의 메시지는 제 2 유형의 메시지(1150)의 적절한 재전송을 감독하기 위해 메시지 흐름을 행하는 비신뢰적인 네트워크의 경우에 제공된다. 제 4 유형의 메시지의 적절한 적시의 전송은 상태(7510) "S_WaitSynAck"에 있는 동안 서버(1200)에서 작동하는 제 2 서버 타이머에 의해 평가된다. 이 경우에, 클라이언트는 제 4 유형의 메시지(4150)를 전송한 후에 상태(4110) "C_Connected"에서 전이한다.
이 메시지 흐름의 다른 특이성은 접속의 종료 중에 제 3 유형의 메시지(1170)로의 적절한 응답이 클라이언트 자체가 상태(4110) "C_WaitFinAck"에 있는 동안 타이머에 의해 감독되는 접속의 종료에 위치된다. 제 2 클라이언트 타이머는 일단 제 6 유형의 메시지(4170)"T_FIN_ACK"가 접속의 종료를 확인 응답하는 서버(1200)로부터 수신되면 정지된다.
비신뢰적인 네트워크 상의 메시지 전송에 기초하는 경우에, 링크는 패킷을 폐기할 수 있다. 이는 예를 들어 메시지 전송 시간을 제한하기 위해 0 또는 1의 재전송의 제한된 수를 갖는 트래픽 클래스에 대해 해당할 수 있다. 이 절차에 기인하여, 때때로 조각 또는 전체 매시지가 손실될 수 있고 또는 메시지는 이들의 페이로드에서 인지된 에러를 갖고 전달될 수 있다. 따라서, 또한 접속 관리 메시지가 프로세싱 없이 폐기될 수 있다. 특히, 여기서 손실에 기인하는 에러 경우에 서버가 먼저 비지 상태에 있고 이어서 제 2 유형의 메시지(1150)로 이용 가능해진 후에 "S_Connected" 상태(1230)에서 유지될 수 있기 때문에, 서버로부터의 제 2 유형의 메시지(1150)는 바람직하게는 보호되어야 한다.
이는 서버가 접속되는 것으로 가정되고 접속되지 않아 따라서 데이터를 수신하도록 준비되지 않은 클라이언트에 데이터를 송신하기 시작하는 경우를 유도할 수 있다.
도 5는 도 4에 도시된 메시지 흐름에 연관된 클라이언트에 대해 상태 및 상태 사이의 예를 나타내는 상태 머신을 도시한다.
이 경우에, 이 실시예에서 도시된 비신뢰적인 네트워크에 존재하는 상황은 도 2에 도시된 신뢰적인 네트워크 내의 클라이언트에 비교하는 차이로서 접속 "C_WaitFinAck"을 종료하는 콘텍스트에서 상태(4110)의 부가를 도시한다. 또한, 상태는 1110 "C_Connected, 1130 "C_Closed", 5120 "C_WaitSynAck" 및 5650 "C_WaitCloseRsp"이다.
상태(1130)로부터 상태(5120)로의 전이는 5150: T_OPEN.req (my_server) / T_SYN (to :my_serever), start Timer_SYN에 대응한다. 상태(5120)로부터 상태(1110)로의 전이는 5250: T_SYN_ACK (from:my_server) / T_ACK_ACK (to:my_server), T_OPEN.cnf (ok), stop Timer_SYN;에 대응하여 발생한다. 상태(1110)로부터 상태(4110)로의 전이는 전이(5450): T_CLOSE.req () / T_FIN (to:my_server), start Timer_FIN에 대응한다. 5300: T_SYN_E (from:my_server) / T_FIN (to :my_server) start Timer_FIN에 따라 상태(5120)로부터 상태(4110)에 도달하는 것이 또한 가능하다. 상태(4110)로부터 상태(1130)는 전이(5550): T_FIN_ACK (from:my_server) / T_CLOSE.cnf (), stop Timer_FIN, 전이(5550): T_FIN (from:my_server) / T_FIN_ACK (to:my_server), T_CLOSE.cnf (), stop Timer_FIN에 따른다. 상태(1110)로부터 상태(5420)는 전이(5460): T_FIN (from:my_client) /T_CLOSE.ind ()에 따른다. 상태(5420)로부터 상태(1130)는 전이 5660: T_CLOSE.rsp ( ) / T_FIN_ACK (to:my_client)에 따른다.
전이(5100): T_FIN_ACK (from:any_server) / -, 전이(5100): T_FIN (from:any_server) / T_FIN_ACK (to:any_client), 전이(5200): T_FIN_ACK (from:any_server) / -, 전이(5200): T_FIN (from:any_server) / T_FIN_ACK (to:any_client), 전이(5200): timeout Timer_SYN / T_SYN (to:my_server), restart Timer_SYN, 전이(5400): T_DATA.req / T_DATA (to:my_server), 전이(5400): T_DATA (from:my_server) / T_DATA.ind, 전이(5400): T_FIN_ACK (from:other_server) / -, 전이(5400): T_FIN (from:other_server) / T_FIN_ACK (to:other_client), 전이(5400): T_SYN_ACK (from:my_server) / T_ACK_ACK (to:my_server), 및 전이(5500): T_SYN_ACK (from:my_server) / T_FIN (to:my_server), 전이 5500: T_SYN_ERR (from:my_server) / T_FIN (to:my_server), 전이(5500): T_FIN_ACK (from:other_server) / -, 전이(5500): T_FIN (from:other_server) / T_FIN_ACK (to:other_client), 전이(5500): timeout Timer_FIN / T_FIN (to :my_server), restart Timer_FIN, 전이(5650): T_FIN_ACK (from:other_server) / -, 및 전이(5650): T_FIN (from:other_server) / T_FIN_ACK (to:other_client)의 경우에, 각각의 상태(1130, 5120, 1110, 4110)가 각각 유지된다.
상태(5120)의 경우에 제 2 유형의 메시지(1150) 각각에서 에러 메시지가 수신되면, 이들은 제 3 유형의 메시지(1170)로 응답한다. 이 경우에, 제 2 클라이언트 타이머가 재시동된다. 이 경우에 양 클라이언트 타이머는 예를 들어 상호 배제적이고 따라서 양자의 기능을 취하는 단일 타이머로서 구현될 수 있다.
도 6은 도 4에 도시된 바와 같이 비신뢰적인 네트워크의 통신 상황에서 서버(1200)의 상태 및 상태 사이의 전이의 예를 나타내는 상태 머신을 도시한다.
여기서, 신뢰적인 네트워크를 사용하는 서버의 상황에 비교하여, 클라이언트(1100)로부터 확인 응답으로서 제 4 유형의 메시지(4150)를 또한 수신한다. 마찬가지로, 이는 제 6 유형의 메시지(4170)를 발행한다.
도 6의 다이어그램에서, 상태(6520) "S_WaitCloseRspE"는 상태(6550) "S_Error" 및 상태(1240) "S_Listen" 뿐만 아니라 상태(6220) "S_WaitOpenRsp" 및 상태(6620) "S_WaitSynAck"와 함께 도시되어 있다. 상태(1230) "S_Connected", 상태(6420) "S_WaitCloseRsp" 및 상태(4112) "S_WaitFinAck"가 또한 도시되어 있다.
상태(1240)는 6800: T_LISTEN.req / -에 의해 개시되고, 6750: T_FIN (from:any_client) / T_FIN_ACK (to:any_client), 또는 6750: T_FIN_ACK (from:any_client) / -의 경우에 유지된다. 거기로부터 6850: T_SYN (from:my_client) / T_OPEN.ind (my_client), start Timer_Rsp에 따른 상태(6220)로의 전이가 발생하고, 이는 6300: T_FIN (from:other_client) / T_FIN_ACK (to:other_client), 또는 6300: T_FIN_ACK (from:other_client) / -의 경우에 유지된다. 거기로부터 상태(6550)는 6250: timeout Timer_Rsp / stop Timer_Rsp, T_SYN_ERR (to:my_client)의 경우에 도달될 수 있고, 6150: T_SYN (from:any_client) / T_SYN_ERR (to:any_client), 6150: T_FIN (from:any_client) / T_FIN_ACK (to:any_client), 또는 6150: T_FIN_ACK (from:any_client) / -에 대응하여 유지된다. 이 상태(6550)로부터, 상태(6520)는 6200: T_OPEN.rsp () / T_CLOSE.ind ()에 의해 도달될 수 있고, 이는 6100: T_SYN (from:any_client) / T_SYN_ERR (to:any_client), 6100: T_FIN (from:any_client) / T_FIN_ACK (to:any_client), 또는 6100: T_FIN_ACK (from:any_client) / -에 따라 유지된다.
상태(6220)로부터 상태(6620)로의 다른 전이는 6350: T_OPEN.rsp () / stop Timer_ sp, T_SYN_ACK (to:my_client), start Timer_ACK;에 대응하여 발생한다. 각각의 상태는 전이(6400): T_SYN (from:my_client) / T_SYN_ACK (to:my_client), 전이(6400): T_SYN (from:other_client) / T_SYN_ERR (to:other_client), 전이(6400): T_FIN (from:other_client) / T_FIN_ACK (to:other_client), 전이(6400): T_FIN_ACK (from:other_client) / -, 또는 전이(6400): timeout Timer_ACK / T_SYN_ACK (to:my_client), restart Timer_ACK;에 대응하여 유지되고, 거기로부터 6450: T_ACK_ACK (from:my_client) / stop Timer_ACK, 또는 6450: T_DATA (from:my_client, data) / stop Timer_ACK, T_DATA.ind (data)에 따라 유지되고, 트랜잭션(6555): T_DATA.req (data) / T_DATA (to:my_client, data), 트랜잭션(6555): T_DATA (from:my_client, data) / T_DATA.ind (data), 트랜잭션(6555): T_SYN_ACK (from: other_client) / -, 트랜잭션(6555): T_SYN (from:other_client) / T_SYN_ERR (to:other_client), 트랜잭션(6555): T_FIN (from:other_client) / T_FIN_ACK (to:other_client), 또는 전이(6555): T_FIN_ACK (from:other_client) / -에 의해 유지되는 상태(1230)가 도달한다. 거기로부터, 상태(6420)가 6600: T_FIN (from:my_client) /T_CLOSE.ind ()에 대응하여 채택되고, 전이(6650): T_DATA.req (data) / T_DATA (to:my_client, data), 전이(6650): T_FIN (from:my_client) / -, 전이(6650): T_SYN (from:other_client) / T_SYN_ERR (to:other_client), 전이(6650): T_FIN (from:other_client) / T_FIN_ACK (to:other_client), 또는 전이(6650): T_FIN_ACK(from:other_client) / -에 대응하여 유지될 수 있다. 이 상태는 이어서 6700: T_CLOSE.rsp / T_FIN_ACK (to:my_client)에 대응하여 초기 상태(1240)로의 전이에 의해 잔류하고 발생한다.
상태(6555)로부터 상태(6640)로의 전이는 6610: T_CLOSE.req () / T_FIN (to:my_client), start Timer_FIN에 대응한다. 상태(4112)로부터 상태(1240)로의 전이는 6645: T_FIN_ACK (from:my_client) / T_CLOSE.cnf (), stop Timer_FIN 및 6645: T_FIN (from:my_client) / T_FIN_ACK (toLmy_client) , T_CLOSE.cnf (), stop Timer_FIN에 대응한다. 상태(4112)는 전이(6640): T_ACK_ACK (from:my_client) / T_FIN (to:my_client), 전이(6640): T_SYN (from:other_client) / T_SYN_ERR (to:other_client), 전이(6640): T_FIN (from:other_client) / T_FIN_ACK (to:other_client), 전이(6640): T_FIN_ACK (from:other_client) / -, timeout Timer_FIN / T_FI (to:my_client), restart Timer_FIN, 또는 T_DATA (from:my_client, data) / -에 따라 유지될 수 있다.
상태(6620)로부터 상태(1240)로의 다른 전이는 6500: T_FIN (from:my_client) / T_FIN_ACK (to:my_client)에 대응하여 발생한다.
용어 "my_client"는 도면에서 애플리케이션 클라이언트를 식별하고, 반면에 용어 "my_server"는 애플리케이션 서버를 식별한다.
도 7은 클라이언트와 서버 사이에 교환된 메시지가 라우터에 의해 포워딩되는 본 발명에 따른 방법의 실시예의 예를 도시한다. 이 방법은 유리하게는 접속의 설정 전에 이용 가능한 대역폭의 검증 및 접속을 위한 대역폭 예약에 적용된다. 이 메시지 차트와 도 4의 신뢰적인 네트워크 내의 접속 관리를 나타내는 메시지 흐름을 도시하는 차트 사이의 주요 차이점은 라우터가 클라이언트(1100)와 서버(1200) 사이에 존재하면 라우터가 도 4에서 클라이언트(1100)와 서버(1200) 사이에 교환되는 메시지를 포워딩하고 유리하게는 각각의 접속에 대해 요구된 대역폭의 이용 가능성을 점검하는 대역폭 평가를 각각 대역폭 할당을 수행한다. 특히, 여기서 라우터(7500)는 신규하고 그 각각의 상태(7510) "R_Ready" 뿐만 아니라 상태(7530) "R_Busy"를 취한다. 더욱이, 이전의 도면에서 설명된 것과 비교하여 제 1 유형의 메시지의 메시지 포맷은 대역폭 요구를 포함하고 따라서 도면 부호 7140 "T_SYN(bw)"에 의해 식별된다. 또한, 제 3 유형의 메시지의 메시지 포맷은 이제 바람직하게는 대역폭 요구를 포함하고 따라서 상이한 도면 부호 7170 "T_FIN(bw)"에 의해 식별된다. 클라이언트(1000)와 서버(1100) 사이의 라우터(7500)는 여기서 예를 들어 대역폭 예약이 계속되면 링크 대역폭의 일부가 다른 접속을 위해 미리 예약될 수 있으면 요구된 대역폭이 링크 용량에 적합되는지를 평가하기 위해 대역폭 파라미터 또는 복수의 대역폭 파라미터를 사용하고, 라우터는 제 1 유형의 메시지를 포워딩하고 그렇지 않으면 예를 들어 클라이언트(1000) 또는 서버(1100)에 통신된 에러를 생성한다. 더욱이, 유리하게는 라우터는 다른 접속을 위한 다른 대역폭 예약 요구를 수용하지 않는 비지 상태에 라우터가 있는 것을 지시하는 상태(7530)에 또한 진입한다. 일단 라우터가 확인하는 동일한 쌍의 클라이언트 및 서버에 대해 클라이언트(1000)에 전송된 서버(1100)로부터 확인인 제 2 유형의 메시지를 식별하면, 모든 수반된 라우터는 이것이 준비 상태(7510)로 이동하는 요구 대역폭을 성공적으로 예약한다. "R_Busy" 상태(7530)는 예를 들어 제 1 유형의 메시지(7140)의 임의의 가능한 재전송을 필터링할 필요가 있고 라우터에서 대역폭 예약의 이중 업데이트를 유리하게 방지한다. 더욱이, 이전의 도면과 비교하여, 접속은 여기서 예를 들어 제 3 유형의 메시지(7170)를 발행하는 서버(1100)와 클라이언트(1000)에 저장되어 있는 제 1 유형의 메시지(7140)와 동일한 대역폭 파라미터(들)를 포함하는 제 3 유형의 메시지(7170)에 의해 종료된다. 제 3 유형의 메시지(7170)를 수신하는 결과로서, 라우터(700)는 그 예약된 대역폭을 점감한다. 메시지 교환이 신뢰적인 네트워크에 기초하여 발생하면, 이 동작은 절대 실패할 수 없고 따라서 제 3 유형의 메시지(7170)는 손실될 수 없고 따라서 이 경우에 바람직하게는 어떠한 타이머도 이 메시지의 적절한 취급시에 속행될 필요가 없다. 라우터에서 평가 프로세스 및 저장 프로세스는 박스 7520에 의해 지시되어 있다.
도 8은 메시지 교환이 실시간 통신을 위해 트래픽 클래스를 지원하는 네트워크 상에서 각각 비신뢰적인 네트워크 상에서 발생하는 본 발명에 따른 방법의 실시예의 메시지 흐름의 다른 예를 제공한다.
도 4에 도시된 메시지 흐름에 비교하여, 이 메시지 흐름은 클라이언트(1000)와 서버(1100) 사이에 교환된 메시지를 포워딩하기 위해 라우터(700)를 이전의 메시지 흐름과 같이 또한 포함한다. 전술된 바와 같이, 비신뢰적인 네트워크를 지원하는 도 4에서의 메시지 흐름에 설명될 때 바람직하게는 클라이언트(1000)와 서버(1100) 사이에 교환된 메시지의 더 밀접한 감독 및 또한 라우터(7500)에서 예방을 필요로 한다.
여기서, 또한, 제 4 유형의 메시지(4150)가 접속을 종료하는 도중에 요구된다. 이유는 3개의 메시지, 즉 제 1 유형의 메시지(7140) 및 제 3 유형의 메시지(7170)와 같은 대역폭을 전달하는 통신을 초기화하는 하나의 메시지, 메시지(1150) 및 메시지(8150) "T_FIN_ACK"와 같은 제 1 유형의 메시지를 호가인 응답하는 제 2 메시지 및 메시지(4150)와 같은 대역폭 변화를 위임하기 위한 제 3 메시지를 요구하는 임의의 라우터 업데이트의 요구에 놓여 있다. 이 경우에, 라우터(7500)는 라우터가 비지 상태이거나 대역폭 변경을 승낙할 수 없는 경우에 "R_Busy"를 지시하는 7530으로 그 상태를 변경하고 또는 이하에 더 설명되는 바와 같이 불충분한 자유 대역폭의 경우에 라우터는 "S_Error" 메시지를 생성한다. 대역폭 할당 및 평가는 여기서 라우터(7500)에서 박스(8550)에 의해 더 지시된다.
도 9는 클라이언트측으로부터 관찰된 도 7의 메시지 흐름에 연관된 상태 머신의 예로서 상태 및 상태 전이를 지시한다.
여기서, 이하의 상태(7120, 1110, 4110, 1130)가 가능하다.
상태(1130)로부터 상태(7120)로의 상태 전이는 9150: T_OPEN.req (my_server, bw) / conn_b = bw, T_SYN (to:my_server, bw), start Timer_SYN에 대응하여 발생하고, 반면에 상태(7120)로부터 상태(4110)로의 상태 전이는 9300: T_SYN_ERR (from:my_server) / T_FIN (to:my_server, conn_bw)에 대응하여 가능하다. 다른 한편으로, 클라이언트에 대한 상태(7120)로부터 상태(1110)로의 상태 전이는 9250: T_SYN_ACK (from:my_server) / T_ACK_ACK (to:my_server), T_OPEN.cnf (ok), stop Timer_SYN에 따라 발생한다. 상태(1110)와 상태(4110) 사이의 추가의 전이 가능성이 9400: T_CLOSE.req () / T_FIN (to:my_server, conn_bw), start Timer_FIN에 대응하여 존재한다. 전이(9100): T_FIN_ACK (from:any_server) / T_ACK_ACK (to:any_server), 전이(9200): T_FIN_ACK (from:any_server) / T_ACK_ACK (to:any_server), 전이(9200): timeout Timer_SYN / T_SYN (to:my_server, conn_bw), restart Timer_SYN, 전이(9350): T_DATA.req / T_DATA (to:my_server), 전이(9350): T_DATA (from:my_server) / T_DATA.ind, 전이(9350): T_FIN_ACK (from:other_server) / T_ACK_ACK (to:other_server), 전이(9350): T_SYN_ACK (from:my_server) / T_ACK_ACK (to:my_server), 및 전이(9450): T_SYN_ACK (from:my_server) / T_FIN (to:my_server, bw), 전이(9450): T_SYN_NAC (from:my_server) / T_FIN (to:my_server, bw), 전이(9450): T_FIN_ACK (from:other_server) / T_ACK_ACK (to:other_server), 전이(9450): timeout Timer_FIN / T_FIN (to:my_server, conn_bw), restart Timer_FIN의 경우에, 각각의 상태(1130, 7120, 9350, 9450)가 유지된다.
여기서, 대역폭 예약이 접속 관리에 추가될 때, 바람직하게는 필요 대역폭 요구가 파라미터로서 메시지(1010)에 제공된다. 예를 들어, 대역폭은 대안의 예를 들어 링크 사용량 퍼센트 대신에 원시 대역폭으로 표현될 수 있고, 예를 들어 각각의 클라이언트 대 서버 방향 및 서버 대 클라이언트 역방향에 대해 상이한 값을 포함할 수 있다. 또한, 더 정교한 대역폭 설명이 가능하다. 예를 들어, 하드 보장이 제공되는 전용 대역폭 및 단지 소프트 보장이 제공되는 공유 대역폭이 제공된다. 이 대역폭 또는 대역폭 파라미터의 세트는 또한 제 1 유형의 메시지(7140) 및 제 3 유형의 메시지(7170)에 추가된다. 대역폭은 예를 들어 메시지(1010)가 수신되고 이어서 제 1 유형의 메시지(7140) 및 제 3 유형의 메시지(7170)의 모두에 대해 사용될 때 접속 대역폭으로서 저장된다. 제 4 유형의 메시지(4150)가 라우터(7500)에서 정확한 대역폭 업데이트를 보장한다. 개량예로서, 제 3 유형의 메시지(7170)의 대역폭 파라미터가 0이면, 제 4 유형의 메시지(4150)가 생략될 수 있다.
도 10은 도 8의 메시지 흐름에 설명되어 있는 본 발명에 따른 방법의 실시예에서 서버가 취할 수 있는 상태 및 상태 전이를 지시하는 상태 머신의 예를 도시한다.
상태 머신은 이하의 상태 및 상태 전이: 10010 "S_WaitCloseRsp", 10020 "S_Error", 1240, 10030 "S_WaitOpenRsp", 7510, 8560, 1230 및 10040 "S_WaitCloseRsp"를 갖는다.
상태(1240)는 10100: T_LISTEN.req / -에 의해 개시되고, 상태(10030)로의 전이는 10150: T_SYN (from:my_client, b) /T_OPEN.ind (my_client), start Timer_ Rsp에 대응하여 발생한다. 상태(10030)로부터 상태(10020)로의 전이는 10200: timeout Timer_Rsp / stop Timer_Rsp, T_SYN_ERR (to:my_client)에 의해 발생하고, 거기로부터 10300: T_OPEN.rsp 0 / T_CLOSE.ind ()에 대응하는 상태(10010)로의 전이가 발생한다.
더욱이, 상태(10030)와 상태(7510) 사이의 상태 전이는 10450: T_OPEN.rsp () / stop Timer_Rsp, T_SYN_ACK (to:my_client), start Timer_ACK에 대응하여 발생한다.
더욱이, 거기로부터, 전이(10600): T_ACK_ACK (from:my_client) / stop Timer_ACK, 전이(10600): T_DATA (from:my_client, data) / stop Timer_ACK, T_DATA.ind (data)에 대응하는 상태(1230)로의 전이, 및 10550: T_FIN (from:my_client, b ) / T_FIN_ACK (to:my_client), start Timer_ACK에 따라 상태(7510)로부터 상태(8560)로의 전이가 가능하다. 더욱이, 상태(1230)로부터 상태(10040)로의 상태 전이는 10700: T_FIN (from:my_client, bw) / T_CLOSE.ind ()에 의해 발생한다. 거기로부터, 상태(8560)로의 추가의 상태 전이가 10800: T_CLOSE.rsp / T_FIN_ACK (to:my_client), start Timer_ACK에 대응하여 가능하고, 상태(8560)로부터 상태(1240)로 시작점으로 뒤로 전이는 10850: T_ACK_ACK (from:my_client) / stop Timer_ACK에 따라 가능하다.
각각의 상태(10010, 10020, 1240, 10030, 7510, 1230, 10040)는 전이(10350): T_SYN (from: any_client, bw) / T_SYN_ERR (to:any_client), 전이(10350): T_ACK_ACK (from:any_client) / -, 전이(10250): T_SYN (from:any_client, bw) / T_SYN_ERR (to:any_client), 전이(10250): T_ACK_ACK (from:other_client) / -, 전이(10900): T_ACK_ACK (from:any_client) / -, 전이(10400): T_ACK_ACK (from:other_client) / -, 전이(10500): T_SYN (from:my_client, b) / T_SYN_ACK (to:my_client), 전이(10500): T_SYN (from:other_client, bw) / T_SYN_E (to:other_client), 전이(10500): T_ACK_ACK (from:other_client) / -, 전이(10500): timeout Timer_ACK / T_SYN_ACK (to :my_client), restart Timer_ACK, 전이(10650): T_DATA.req (data) / T_DATA (to:my_client, data), 전이(10650): T_DATA (from:my_client, data) / T_DATA. ind (data), 전이(10650): T_SYN_ACK (from:other_client) / -, 전이(10650): T_SYN (from:other_client, bw) / T_SYN_ERR (to:other_client), 전이(10650): T_ACK_ACK (from: other_client) / -, 및 전이(10750): T_DATA.req (data) / T_DATA (to:my_client, data), 전이(10750): T_FIN (from:my_client, bw) / -, 전이(10750): T_SYN (from: other_client, bw) / T_SYN_ERR (to:other_client), 전이(10750): T_ACK_ACK (from:other_client) / -에 대응하여 유지된다. 또한, 상태(10010)로부터 상태(1240)로의 전이가 10950: T_CLOSE.rsp / -에 따라 발생한다.
더욱이, 서버는 예를 들어 제 1 유형의 메시지(7140) 및 제 3 유형의 메시지(7170) 상의 대역폭 파라미터를 또한 수신한다. 상태(8560)는 바람직하게는 서버가 제 4 유형의 메시지(4150)를 대기하게 하기 위해 도입된다. 제 6 유형의 메시지(4170)는 또한 바람직하게는 제 6 유형의 메시지(4170)가 전송될 때 시동되고 타이머가 만료되면 재전송을 트리거링하는 타이머에 의해 그 확실한 재전송에서 보호된다. 서버에서 모든 타이머는 이들이 병렬로 운전하지 않기 때문에 바람직하게는 유리하게는 하나의 타이머에서 구현될 수 있다.
도 11은 도 8에 도시되고 설명된 본 발명에 따른 방법의 실시예에 라우터가 채택할 수 있는 상태 및 상태 전이를 위한 상태 머신의 예를 도시한다.
이하의 상태가 예를 들어 가능하다: 7510; 11540 "R_Busy_Fin" 및 11530 "R_Busy_Syn"
상태(7510)의 개시는 11100: R_bw = 0, err_flag = false에 따라 발생한다. 거기로부터 상태(11540)로의 상채 전이가 11400: T_FIN (from:client, to:server, bw) / R_client = client, R_server = server, R_bw -= bw, T_FIN (from:client, to:server, bw)에 따라 발생한다. 상태(11540)로부터 뒤로, 전이는 11500: T_ACK_ACK (from:R_client, to:R_server) / err_flag = false, T_ACK_ACK (from:R_client, to:R_server)에 따라 가능하고 발생한다. 상태(7510)로부터 상태(11530)로의 상태 전이는 또한 전이(11200): T_SYN (from:client, to: server, bw), (R_bw+bw) ≤ MAX_BW / R_client = client, R_server = server, R_bw += bw, T_SYN (from:client, to:server, bw), 또는 전이(11200): T_SYN (from:client, to:server, bw), (R_bw+bw) > MAX_BW / R_client = client, R_server = server, err_flag = true, T_SYN_ERR (from:client, to:server)에 대응하여 발생할 수 있고, 거기로부터 11350: T_ACK_ACK (from:R_client, to:R_server) / err_flag = false, T_ACK_ACK (from:R_client, to:R_server)에 대응하는 시작점에 복귀한다. 상태(11530, 1150) 사이의 다른 상태 전이는 11300: T_FIN (from:client, to:server, bw) / T_FIN (from:client, to: server, bw)에 대응하여 발생한다.
각각의 상태(7510, 11540, 11530) 는 전이(11150): T_DATA (from: node1, to:node2) / T_DATA (from: node1, to:node2), 전이(11150): OTHER_MSG (from: node1, to:node2, ...) / OTHER_MSG (from: node1, to:node2, ...), 전이(11450): T_FIN_ACK (from:R_server, to:R_client) / T_FIN_ACK (from:R_server, to:R_client), 전이(11450): T_FIN (from:R_client, to:R_server, bw) / T_FIN (from:R_client, to:R_server, bw), 전이(11450): T_FIN (from:other_client, to:other_server, bw) / -, 전이(11450): T_DATA (from:node1, to:node2) / T_DATA (from:node1, to:node2), 또는 전이(11450): OTHER_MSG (from: node1, to:node2, ...) / OTHER_MSG (from:node1, to:node2, ...); 및 전이(11250): T_SYN_ACK (from:server, to:client) / T_SYN_ACK (from:server, to:client), 전이(11250) T_SYN_ERR (from:server, to:client) / T_SYN_ERR (from:server, to:client), 전이(11250): T_SYN (from:R_client, to: R_server, bw) && (err_flag == false) / T_SYN (from:R_client, to:R_server, bw), 전이(11250): T_SYN (from:R_client, to:R_server, bw) && (err_flag == true) / T_SYN_ERR (from:R_client, to : R_server), 전이(11250): T_SYN (from:other_client, to:other_server, bw) / -, 전이(11250): T_DATA (from:node1, to:node2) / T_DATA (from:node1, to:node2), 또는 전이(11250): OTHER_MSG (from: node1, to:node2, ...) / OTHER_MSG (from: node1, to : node2, ... )에 따라 유지된다.
예를 들어, 라우터는 접속을 개방하고 폐쇄하는 프로세스 중에 상태를 구성해야 한다. 디폴트 상태는 라우터가 준비되어 있는 7510에 있고 거기로부터 이들의 목적지로 패킷을 포워딩한다. 그러나, 라우터가 제 1 유형의 메시지(7140) 또는 제 3 유형의 메시지(7170)를 수신하면, 라우터 대역폭 예약은 바람직하게는 업데이트되고 이를 행하는 도중에 라우터는 상태(11530, 11540) 각각으로 이동한다. 라우터가 초기 상태(7510)에 있고 할당을 위해 충분한 대역폭을 갖는 메시지(7140)를 수신하는 경우에, 이는 대역폭을 업데이트하고 메시지를 서버에 포워딩한다. 다른 한편으로는, 대역폭 이용 가능성이 불충분하면, 라우터는 대역폭이 업데이트되는 것을 방지하도록 에러_플래그를 발행하고, 에러 메시지는 메시지(7140)를 포워딩하는 대신에 서버에 설정된다. 에러_플래그는 바람직하게는 접속을 폐쇄할 때 대역폭이 업데이트되는 것을 방지하는데 사용될 수 있다. 양 경우에, 접속 셋업에 수반된 클라이언트 및 서버 쌍은 바람직하게는 재전송에 기인하여 다중 대역폭 업데이트를 방지하기 위해 안전하다. 상태(7510)에 있는 상태로, 라우터가 메시지(7170)를 수신하는 경우에 또한 클라이언트 서버 쌍은 메시지(7140)에 대해 안전하고, 라우터 대역폭은 바람직하게는 bw로 증가된다.
상태(11530)에 있는 상태로, 제 4 유형의 메시지(4150)가 저장된 클라이언트 서버 쌍에 정합하여 수신되면, 에러_플래그는 소거되고 라우터는 상태(7510)로 이동한다. 메시지(7170)가 저장된 클라이언트 서버 쌍에 정합하여 수신되면, 라우터는 상태(11540)로 전이한다. 바람직하게는, 메시지(4150) 및 메시지(4170)를 포함하는 모든 메시지가 포워딩된다. 예외적으로, 일단 메시지(7140)가 절약된 클라이언트 서버 쌍을 위해 수신되면, 에러_플래그가 설정된다. 상태(11540)에 있을 때 메시지(4150)가 저장된 클라이언트 서버 쌍에 정합하여 수신되면, 에러_플래그는 소거되고 라우터가 상태(7510)로 이동한다. 이 상태에서, 메시지(4150)를 포함하는 모든 메시지가 포워딩된다. 모든 접속 개방/폐쇄를 위해, 라우터는 어드레스 및 포트로 이루어질 수 있는 클라이언트 및 서버 신분을 참조하는 접속을 식별하는 상태를 바람직하게 저장할 필요가 있다. 예를 들어, 가장 간단한 라우터 구현예는 도 11에 도시된 바와 같이 단일 접속 신분을 저장할 수 있다. 대안적으로, 라우터는 다수의 접속 신분을 저장할 수 있고, 이 경우에 이는 이것이 절약하는 것이 가능한 접속 신분마다 도 11에 도시된 바와 같이 하나의 상태 머신을 이용할 수 있다. 이 경우에, 접속 신분에 저장될 수 있는 메시지(7140 또는 7170)가 수신될 때마다, 라우터는 도 11에 도시된 상태 및 상태 전이에 결합한다. 라우터가 접속 신분을 저장할 수 없는 경우에, 바람직하게는 라우터는 메시지(7140, 7170) 각각을 폐기하고 어떠한 추가의 동작도 취하지 않는다.
도 12 내지 도 21은 동일한 방식으로 본 발명에 따른 시스템에 의해 처리될 수 있는 본 발명의 방법의 설명된 실시예의 방법에 따른 다양한 에러의 예 및 이들의 처리를 설명한다.
도 12는 도 1에 더 상세히 본 발명에 따른 방법의 실시예에서 잠재적으로 발생하는 에러 경우의 예를 제공한다.
이 경우에, 예를 들어 서버(1200)는 비지 상태일 수 있고 따라서 이것이 현재 서버(1200)가 상이한 접속으로 처리되는 것을 지시하는 상태(1230)에 있기 때문에 제 1 유형의 메시지(1140)를 포워딩할 수 없다. 이 경우에, 애플리케이션 서버(1300)와의 접속을 설정하는 대신에, 클라이언트(1100)에 의해 수신될 때 클라이언트가 접속될 수 있는 상태(1110) 대신에 접속이 폐쇄되어 있는 상태(1130)로 클라이언트가 전이할 수 있게 하는 에러 메시지(12150) "T_SYN_ERR"을 생성한다.
도 13 및 도 14는 잠재적으로 손실되거나 폐기될 수 있는 메시지의 전송을 감독하기 위한 타이머의 사용을 도시한다.
도 13은 도 1에 더 상세히 설명되어 있는 본 발명에 따른 방법의 실시예에 에러가 잠재적으로 발생할 수 있는 경우를 도시한다. 이 경우에, 제 1 유형의 메시지는 손실될 수 있고(13140), 따라서 상태(1210)로 유지되는 서버(1200)에 의해 수신되거나 프로세싱되지 않을 수 있다. 그러나, 이 경우에 제 1 사전 정의된 기간을 측정하는 제 1 클라이언트 타이머가 만료되어 제 1 유형의 메시지(1140)의 재전송이 클라이언트(1100)와 서버(1200) 사이의 접속을 설정하게 한다. 제 1 사전 정의된 기간은 바람직하게는 제 2 유형의 메시지(1150)를 생성하도록 충분한 프로세싱 시간 뿐만 아니라 양 방향에서 충분한 전송 시간을 서버(1200)에 허용하는 이러한 방식으로 치수 설정된다. 도 1에 설명된 바와 같은 추가의 처리는 제 2 유형의 메시지(1150)가 클라이언트(1100)에 의해 수신될 때이다.
도 14는 도 14와 연관되어 더 상세히 설명된 본 발명에 따른 방법의 실시예에서 잠재적으로 발생할 수 있는 다른 에러 및 그 처리를 설명한다. 이 경우에, 도면 부호 14150으로 지시된 제 2 유형의 메시지가 손실된다. 또한 이 경우에도, 도 13에서와 같이 도면 부호 13010에 의해 지시된 타임아웃이 발생하여 제 1 유형의 메시지(1140)의 재전송을 유발한다. 서버(1200)에 도달하는 이 메시지가 검출되고, 상태(1210 내지 1220)로부터 처음에 수신된 제 1 유형의 메시지(1140)에 의해 발생된 상태 전이에 기인하여 이는 서버가 이 메시지(110)가 재전송되고 이 메시지의 소스가 최초라는 것을 식별하는 것을 허용한다. 서버가 프로세싱하지 않고 재전송된 메시지(1140)를 폐기할 수 있게 하고 확인(1150)을 위해 제 2 유형의 메시지를 송신하도록 접속되는 상태(1230)로 상태 전이한다.
도 15는 그 메시지 교환시에 도 1에 더 상세히 설명된 본 발명에 따른 방법의 실시예서 발생할 수 있는 다른 에러 경우의 예를 설명한다. 이 경우에, 애플리케이션 서버(1300)에서 애플리케이션이 크래쉬하는 경우에 발생할 수 있는 것이 설명될 것이다. 여기서, 서버(1200)는 메시지(1310)를 송신하지만, 크래쉬된 애플리케이션(1320)으로부터 응답을 수신하지 않을 수 있다. 이는 그 치수 설정시에 양 방향에서의 메시지 전달 및 메시지(1310)를 프로세싱하고 응답(1320)을 생성하기 위해 애플리케이션 서버를 위한 시간의 양을 고려해야 하는 제 2 사전 정의된 기간을 측정하는 제 1 서버 타이머에서 타임아웃(15250)을 유도한다. 타임아웃(15250)에 기인하는 제 1 서버 타이머의 만료는 에러를 지시하는 상태(6550)를 생성하고, 클라이언트에 에러 메시지(15150)를 송신한다. 제 1 유형의 메시지(1140)의 추가의 전송은 서버(1200)로부터 에러 메시지(15140)를, 각각 에러 메시지(15150, 15140)에 응답하여 애플리케이션 클라이언트(15010)에 대응 메시지로서 유도할 수 있다. 양 경우에, 클라이언트는 접속을 폐쇄할 수 있고 상태(1130)로 이동할 수 있다.
애플리케이션 서버가 메시지(1320) T_OPEN.rsp로 서버에 응답하면, 서버는 접속이 메시지(1370) T_CLOSE.ind를 사용하여 실제로 폐쇄되는 것을 애플리케이션 서버에 통지하고, 상태(1210) S_Listen으로 복귀하여, 여기서 서버는 접속 셋업 요구를 수신할 준비가 된다.
도 16은 도 4에 상세히 그 메시지 흐름에서 설명된 본 발명에 따른 방법의 실시예에서 어떻게 에러가 처리될 수 있는지에 대한 예를 제공한다.
여기서, 또한 신뢰적인 네트워크에 대한 경우에 미리 설명된 바와 같이, 서버(1100)는 비지 상태이고 요구시에 접속을 설정하지 않을 수 있다. 이는 따라서 클라이언트(1100)에 통지하기 위해 에러 메시지(12150)를 생성한다. 이는 서버(1200)로부터 발행된 제 6 유형의 메시지(4170)에 의해 확인 응답되는 제 3 유형의 메시지(1150)를 발행하는 클라이언트(1100)에서 접속 폐쇄 동작을 유발한다. 클라이언트는 이어서 상태(1130)로 이동한다.
도 17은 메시지 교환이 도 4에 더 상세히 설명된 바와 같이 비신뢰적 네트워크에 기초하는 본 발명에 따른 방법의 실시예에서 발생하는 잠재적인 에러 경우를 설명한다. 비신뢰적인 네트워크에서와 같이, 임의의 메시지는 오손되거나 손실되고, 또한 제 2 유형의 메시지(1150)는 바람직하게는 그 적절한 처리를 위해 감독되어야 한다. 이러한 감독이 행해지지 않으면, 손실은 서버가 접속(12150)을 성정하기 위해 요구시에 에러 메시지로 응답하면서 제 1 비지 상태에 있는 "S_Connected" 상태(1230)에 잔류하게 유도할 수 있고, 이러서 그러나 도면 부호 17150에 의해 지시된 다른 클라이언트로부터 분리되고 상태(1210)에서 재차 새로운 접속을 위해 이용 가능하게 된다. 그러나, 에러 메시지는 너무 늦게 클라이언트(1100)에 도달하고, 제 1 유형의 메시지(1140)의 재전송을 유발하는 타임아웃(13010) 후에 서버는 애플리케이션 서버(1300)와의 접속을 개방하게 하고 제 2 유형의 메시지(14150)가 손실될 때 프로토콜 에러(1710)를 생성하는 데이터(1160)의 재전송을 시작하게 한다.
도 18 내지 도 21은 더 상세히 도 8 및 연관 설명에 설명되고 도시된 본 발명에 따른 방법의 실시예에서 발생할 수 있는 상이한 에러 경우를 설명한다.
거기서 라우터(7500)는 비지 상태이고 대역폭의 이용 불가능성에 기인하여 대역폭 변경 요구를 승낙할 수 없고, 이 상황에 기인하여 에러 메시지를 생성한다.
도 18은 이 상황의 제 1 경우 처리를 도시한다. 제 1 유형의 메시지(7140)를 수신하여, 라우터(21500)는 대역폭 할당을 거절하고 21520에서 에러 플래그를 설정한다. 이는 클라이언트(1100)에 포워딩되는 라우터(7500)에 에러 메시지(20140)의 전송을 유도한다. 라우터(7500)는 20540에서 에러 플래그를 설정한다. 다른 한편으로는, 에러 메시지(20540)를 수신하는 클라이언트는 에러 메시지(20170) "T_FIN_ERR"시의 종료를 송신하는 접속의 종료를 시작한다. 라우터(21500)에 포워딩되어 이는 클라이언트(1100)에 도달시에 에러 메시지(12020) "T_OPEN.err"의 생성을 트리거링하는 확인 응답 메시지(4170)를 생성한다.
도 19는 메시지 흐름 및 처리의 약간의 변화를 갖는 도 18에 설명된 동일한 에러 경우의 예를 제공한다. 제 1 유형의 메시지(7140)를 수신하여, 라우터(21500)는 19520에서 에러_플래그를 설정하지 않고, 에러 메시지(21140)에서의 대역폭 정보를 클라이언트에 전송하지 않는다. 이전의 예와 대조적으로, 따라서 클라이언트(1100)는 도 8에 설명된 바와 같이 정상 접속 종료로 속행될 수 있다.
이 경우에, 라우터는 에러 경우(19530) "R_BusyERR"에 상이한 상태에 진입한다. 정상 접속 종료는 이용 가능한 경우에 대역폭 할당이 자유롭다. 도 19에 제공된 예의 경우에, 메시지 처리는 더 용이하고 적은 양의 메시지가 전송되는 것을 요구한다. 그러나, 도 18 및 도 19에 도시된 양 경우에, 라우터는 바람직하게는 에러 메시지(21140, 20140)를 발행할 때 서버의 몇몇 기능성을 구현하도록 구성될 필요가 있다.
라우터의 이러한 수정을 회피하기 위해, 잠재적인 대안은 도 20 및 도 21의 예에 설명된 서버(1200)로의 에러 처리를 포워딩하는 것이다.
도 20은 라우터가 비지 상태이고 메시지 교환이 도 8에 설명된 본 발명에 따른 방법의 실시예에서 비신뢰적인 네트워크에 기초하는 에러 경우의 처리의 예를 제공한다.
여기서, 도 18에 설명된 경우와 유사하게, 일단 포워딩된 제 1 유형의 메시지(7140)를 수신하고 어떠한 이용 가능한 대역폭도 갖지 않으면, 라우터는 에러_플래그를 설정하고 이 경우에 대역폭 파라미터를 포함하는 에러 메시지(20140)를 생성하는 서버(1200)에 새로운 에러 메시지(20140)를 포워딩한다. 서버에 의한 다른 부가의 작업은 제 7 유형의 메시지(4150)에 의해 클라이언트(1100)에 의해 발행된 에러시의 접속 종료에 응답하는 것이다.
도 21은 도 19와 연관하여 설명된 에러 처리의 예를 또한 제공하고, 이 경우에 그러나 에러 처리는 서버(1200)에서 발생한다. 수정예로서, 도 19의 프로토콜은 에러 메시지(21140)가 서버(1200)에 포워딩되고 이 서버는 이어서 에러 메시지(21140)를 송신하고 접속의 종료를 처리하는 책임이 있을 수 있는 방식으로 수정된다.
비신뢰적인 네트워크에 대해, 라우터 내의 대역폭을 업데이트하기 위한 잠재적인 대안은 7140 대신에 제 2 유형의 메시지(1150) 및/또는 7170 대신에 메시지(4170)로 이를 행하는 것이다. 여기서, 클라이언트/서버 쌍은 이전과 같이 저장될 수 있고 뿐만 아니라 제 1 메시지(7140 및/또는 7170)가 수신될 때 플래그 ERR_flag가 설정될 수 있다. 그러나, 이 경우에, 대역폭 파라미터는 메시지(1150, 4170)에 의해 전달될 수 있다. 에러의 경우에, 에러 메시지(21140)는 임의의 대역폭 파라미터를 전달하지 않고, 어떠한 대역폭 업데이트도 메시지(1150 및/또는 4170)에 의해 행해지지 않기 때문에 대역폭을 갖지 않는 접속 종료를 유도할 수 있다. 따라서, 메시지(4150)는 이 에러 경우에 더 최적화될 수 있다.
도 22는 접속이 메시지(1070) "T_CLOSE.req"를 송신하는 애플리케이션 클라이언트(1000)에 의해 폐쇄되는 경우를 도시하는 유사한 콘텍스트에서 도 4에 추가하여 상이한 옵션을 예시한다. 대안적으로, 접속은 또한 메시지(1070) "T_CLOSE.req"를 송신하는 애플리케이션 서버(1300)에 의해 폐쇄될 수 있다. 또한, 이 경우에도, 최종적인 단계는 동일하다. T/CO 서버(1200)는 메시지(1070) "T_CLOSE.req"를 수신할 때 메시지(1170) "T_FIN"을 송신하고, 타이머를 시동하고, 상태(4112) "S_WaitFinAck"에 진입한다. T/CO 클라이언트(1100)가 메시지(1170) "T_FIN"을 수신할 때, 이는 메시지(1370) "T_CLOSE.ind"를 애플리케이션 서버에 발행하고, 이 애플리케이션 서버는 메시지(4380) "T_CLOSE.rsp"로 T/CO 클라이언트(1100)에 응답하고, 이어서 메시지(4170) "T_FIN_ACK"를 T/CO 서버에 송신하고 상태(1130) "C_Closed"에 진입한다. 메시지(4170) "T_FI_ACK"를 수신할 때, T/CO 서버는 그 타이머를 정지하고, 메시지(4080) "T_CLOSE.cnf"를 애플리케이션 서버(1300)에 송신하고, 상태(1240) "S_Listen"에 진입한다.
도 23은 유사한 콘텍스트에서 도 4에 추가하여, 접속 폐쇄가 T/CO 클라이언트(1100) 및 T/CO 서버(1200)의 모두에 동시에 요구되는 경우를 도시한다. 이 경우에, T/CO 클라이언트(1100)와 T/CO 서버(1200)로부터 메시지(1070) "T_FIN"이 네트워크 내에서 교차한다. 메시지(1070) "T_FIN"이 T/CO 클라이언트(1100)에서 수신될 때, T/CO 클라이언트(1100)는 타이머를 정지시키고, 메시지(4170) "T_FIN_ACK"를 T/CO 서버(1200)로 송신하고, 상태(1130) "C_Closed"로 이동한다. 메시지(1070) "T_FIN"이 T/CO 서버(1200)에서 수신될 때, T/CO 서버(1200)는 타이머를 정지시키고, 메시지(4170) "T_FIN_ACK"를 T/CO 클라이언트(1100)에 송신하고, 상태(1240) "S_Listen"으로 이동한다.
본 발명은 또한 서버 및/또는 클라이언트 내에 구체화된 바와 같은 시스템의 임의의 기능성이 하드웨어, 컴퓨터 소프트웨어 또는 이들의 조합으로서 구현될 수 있는 것을 포함한다. 시스템, 예를 들어 클라이언트 및/또는 서버는 범용 프로세서, 디지털 신호 프로세서(DSP), 애플리케이션 특정화 집적 회로(ASIC), 필드 프로그램 가능 게이트 어레이(FPGA) 또는 다른 프로그램 가능 논리 디바이스, 개별 게이트 또는 트랜지스터 로직, 개별 하드웨어 구성 요소 또는 본 명세서에 설명된 기능을 수행하도록 설계된 임의의 조합을 포함할 수 있다. 범용 프로세서는 마이크로프로세서 또는 상태 머신일 수 있다. 프로세서는 또한 컴퓨팅 디바이스의 조합, 예를 들어 DSP와 마이크로프로세서의 조합, 복수의 마이크로프로세서, DSP와 조합하여 하나 이상의 마이크로프로세서 또는 임의의 다른 이러한 구성으로서 구현될 수 있다. 클라이언트 및/또는 서버에 사용된 프로세서는 본 발명의 임의의 방법을 수행하도록 적용된다.
본 발명은 또한 예를 들어 서버 및/또는 클라이언트에 사용을 위해 임의의 유형의 컴퓨팅 디바이스 상에서 실행을 위해 적용된 코드 세그먼트를 포함하는 컴퓨터 프로그램 제품, 즉 프로세싱 엔진을 포함하는 것을 포함한다. 컴퓨터 프로그램 제품 내의 소프트웨어 코드는 컴퓨팅 디바이스 상에서 실행될 때 제 1 유형의 메시지를 서버에 송신함으로써 접속의 설정을 요구하는 기능을 클라이언트 내에 제공한다. 서버에서, 소프트웨어는 컴퓨팅 디바이스 상에서 실행될 때 서버가 접속되는 것을 유도하는 제 2 유형의 메시지를 클라이언트에 송신함으로써 접속을 설정하는 능력을 확인한다. 소프트웨어는 바람직하게는 제 1 유형의 메시지의 송신이 제 1 최대 응답 시간으로서 제 1 사전 정의된 기간을 측정하는 제 1 클라이언트 타이머를 시동하도록 배열되고, 바람직하게는 제 2 유형의 메시지 또는 데이터 메시지의 수신시에 제 1 클라이언트 타이머가 정지되도록 배열된다. 소프트웨어는 바람직하게는 또한 접속이 제 3 유형의 메시지를 송신함으로써 폐쇄되도록 배열된다.
소프트웨어는 바람직하게는 또한 제 2 유형의 메시지가 수신되지 않고 제 1 사전 정의된 기간이 만료되면, 다른 제 1 유형의 메시지가 송신되도록 배열된다. 소프트웨어는 바람직하게는 또한 서버가 접속을 수락할 수 없으면 서버가 에러 메시지를 답신하도록 배열된다.
소프트웨어는 바람직하게는 또한
a) 제 2 유형의 메시지의 수신이 접속되지 않은 클라이언트를 유도하고,
b) 클라이언트가 제 2 유형의 메시지의 수신을 확인하기 위해 서버에 제 4 유형의 메시지를 송신하도록 배열된다.
소프트웨어는 바람직하게는 또한 제 2 유형의 메시지의 송신이 제 2 최대 응답 시간으로서 제 2 사전 정의된 기간을 측정하고 제 4 유형의 메시지가 제 1 서버 타이머를 정지시키도록 배열된다.
소프트웨어는 바람직하게는 또한 서버가 접속을 설정하는 것이 가능하지 않은 경우에, 접속되어 있지 않은 클라이언트를 유도하는 클라이언트에 제 5 유형의 메시지를 송신하도록 배열된다.
소프트웨어는 바람직하게는 또한 제 3 유형의 메시지의 송신이 제 3 최대 응답 시간으로서 제 3 사전 정의된 기간을 측정하는 제 2 클라이언트 타이머를 시동하도록 배열되다.
소프트웨어는 바람직하게는 또한 서버가 제 6 유형의 메시지를 송신함으로써 제 3 유형의 메시지의 수신을 확인하도록 배열된다.
소프트웨어는 바람직하게는 또한 제 6 유형의 메시지의 송신이 제 4 최대 응답 시간으로서 제 4 사전 정의된 기간을 측정하는 제 2 서버 타이머를 시동하도록 배열된다.
소프트웨어는 바람직하게는 또한 클라이언트에서 제 6 유형의 메시지의 수신이 제 2 클라이언트 타이머를 정지시키고, 클라이언트가 제 4 유형의 메시지를 송신하게 하도록 배열된다.
소프트웨어는 바람직하게는 또한 서버에 의한 제 3 유형의 메시지의 송신이 제 3 최대 응답 시간으로서 제 3 사전 정의된 기간을 측정하는 제 2 서버 타이머를 시동하도록 배열된다.
소프트웨어는 바람직하게는 또한 제 3 유형의 메시지를 수신하는 클라이언트가 제 6 유형의 메시지를 송신함으로써 제 3 유형의 메시지의 수신을 확인하도록 배열된다.
소프트웨어는 바람직하게는 또한 제 6 유형의 메시지의 송신이 제 4 최대 응답 시간으로서 제 4 사전 결정된 기간을 측정하는 제 2 클라이언트 타이머를 시동하도록 배열된다.
소프트웨어는 바람직하게는 또한 서버에서 제 6 유형의 메시지의 수신이 제 2 서버 타이머를 정지시키고, 클라이언트가 제 4 유형의 메시지를 송신하게 하도록 배열된다.
소프트웨어는 바람직하게는 또한 클라이언트와 서버 사이의 메시지 중 적어도 하나가 라우터를 통해 통과할 수 있도록 배열되고, 적어도 하나의 메시지는 리소스 예약을 위한 요구를 포함하고, 라우터는 단지 이것이 요구된 리소스를 제공하는 것이 가능한 경우에 적어도 하나의 메시지를 포워딩한다.
소프트웨어는 바람직하게는 또한 라우터가 적어도 하나의 메시지를 포워딩하면, 리소스 예약을 위한 요구와 연관된 접속을 설정하는데 수반된 클라이언트 서버 쌍에 연관된 제 2 유형의 메시지를 수신할 때까지 추가의 리소스 예약 요구를 중지하도록 배열된다.
소프트웨어는 바람직하게는 또한 적어도 하나의 메시지가 접속이 폐쇄되는 경우에 리소스 예약을 취소하는데 사용되도록 배열된다.
소프트웨어는 바람직하게는 클라이언트 및 서버가 각각 각각의 애플리케이션 클라이언트와 각각의 애플리케이션 서버 사이에 접속을 설정하도록 배열된다.
본 발명은 또한 전술된 컴퓨터 프로그램 제품을 저장하는 비일시적 머신 판독 가능 신호 저장 매체를 포함한다. 예를 들어, 비일시적 머신 판독 가능 신호 저장 매체는 CDROM, DVDROM과 같은 광학 디스크 또는 자기 테이프 메모리, 하드 디스크 또는 디스켓과 같은 자기 디스크 메모리, USB 메모리 스틱과 같은 고상 메모리, 플래시 메모리 등일 수 있다.

Claims (30)

  1. 접속 지향 순차 전송 환경에서 접속을 관리하기 위한 방법에 있어서,
    a) 클라이언트가 제 1 유형의 메시지를 서버에 송신함으로써 접속을 설정하는 것을 요구하고,
    b) 상기 서버는 서버가 접속되게 유도하는 제 2 유형의 메시지를 상기 클라이언트에 송신함으로써 접속을 설정하는 능력을 확인하고,
    c) 상기 제 1 유형의 메시지를 송신하는 것은 제 1 클라이언트 타이머를 시동하여 제 1 최대 응답 시간으로서 제 1 사전 정의된 기간을 측정하도록 하고, 제 2 유형의 메시지 또는 데이터 메시지를 수신하는 것은 상기 제 1 클라이언트 타이머를 정지시키고,
    d) 상기 접속은 제 3 유형의 메시지를 송신함으로써 폐쇄되는
    접속 지향 순차 전송 환경에서 접속을 관리하기 위한 방법.
  2. 제 1 항에 있어서,
    제 2 유형의 메시지가 수신되지 않고 상기 제 1 사전 정의된 기간이 만료되면, 다른 제 1 유형의 메시지가 송신되는
    접속 지향 순차 전송 환경에서 접속을 관리하기 위한 방법.
  3. 제 1 항에 있어서,
    상기 서버는 상기 서버가 접속을 수용할 수 없으면 에러 메시지를 반환하는
    접속 지향 순차 전송 환경에서 접속을 관리하기 위한 방법.
  4. 제 1 항에 있어서,
    a) 상기 제 2 유형의 메시지를 수신하는 것은 상기 클라이언트가 접속되게 유도하고,
    b) 상기 클라이언트는 제 4 유형의 메시지를 상기 서버에 송신하여 제 2 유형의 메시지의 수신을 확인하는
    접속 지향 순차 전송 환경에서 접속을 관리하기 위한 방법.
  5. 제 4 항에 있어서,
    상기 제 2 유형의 메시지를 송신하는 것은 제 1 서버 타이머를 시동하여 제 2 최대 응답 시간으로서 제 2 사전 정의된 기간을 측정하도록 하고, 상기 제 4 유형의 메시지를 수신하는 것은 상기 제 1 서버 타이머를 정지시키는
    접속 지향 순차 전송 환경에서 접속을 관리하기 위한 방법.
  6. 제 1 항에 있어서,
    상기 서버가 접속을 설정할 수 없는 경우에, 상기 서버는 상기 클라이언트가 접속되지 않게 유도하는 제 5 유형의 메시지를 상기 클라이언트에 송신하는
    접속 지향 순차 전송 환경에서 접속을 관리하기 위한 방법.
  7. 제 1 항에 있어서,
    상기 제 3 유형의 메시지를 송신하는 것은 제 2 클라이언트 타이머를 시동하여 제 3 최대 응답 시간으로서 제 3 사전 정의된 기간을 측정하도록 하는
    접속 지향 순차 전송 환경에서 접속을 관리하기 위한 방법.
  8. 제 1 항에 있어서,
    상기 서버는 제 6 유형의 메시지를 송신함으로써 제 3 유형의 메시지의 수신을 확인하는
    접속 지향 순차 전송 환경에서 접속을 관리하기 위한 방법.
  9. 제 8 항에 있어서,
    상기 제 6 유형의 메시지의 송신은 제 2 서버 타이머를 시동하여 제 4 최대 응답 시간으로서 제 4 사전 정의된 기간을 측정하도록 하는
    접속 지향 순차 전송 환경에서 접속을 관리하기 위한 방법.
  10. 제 7 항에 있어서,
    상기 클라이언트에서 제 6 유형의 메시지를 수신하는 것은 상기 제 2 클라이언트 타이머를 정지시키고,
    상기 클라이언트로 하여금 제 4 유형의 메시지를 송신하게 하는
    접속 지향 순차 전송 환경에서 접속을 관리하기 위한 방법.
  11. 제 1 항에 있어서,
    상기 서버에 의해 제 3 유형의 메시지를 송신하는 것은 제 2 서버 타이머를 시동하여 제 5 최대 응답 시간으로서 제 3 사전 정의된 기간을 측정하도록 하는
    접속 지향 순차 전송 환경에서 접속을 관리하기 위한 방법.
  12. 제 1 항에 있어서,
    상기 제 3 유형의 메시지를 수신하는 상기 클라이언트는 제 6 유형의 메시지를 송신함으로써 제 3 유형의 메시지의 수신을 확인하는
    접속 지향 순차 전송 환경에서 접속을 관리하기 위한 방법.
  13. 제 12 항에 있어서,
    상기 제 6 유형의 메시지의 송신은 제 2 클라이언트 타이머를 시동하여 제 4 최대 응답 시간으로서 제 4 사전 정의된 기간을 측정하도록 하는
    접속 지향 순차 전송 환경에서 접속을 관리하기 위한 방법.
  14. 제 11 항에 있어서,
    상기 서버에서 제 3 유형의 메시지를 수신하는 것은 상기 제 2 서버 타이머를 정지시키는
    접속 지향 순차 전송 환경에서 접속을 관리하기 위한 방법.
  15. 제 1 항에 있어서,
    상기 클라이언트와 상기 서버 사이의 메시지 중 적어도 하나는 라우터를 통해 통과하고,
    상기 적어도 하나의 메시지는 리소스 예약을 위한 요구를 포함하고,
    상기 라우터는 단지 요구된 리소스를 제공하는 것이 가능한 경우에 상기 적어도 하나의 메시지를 포워딩하는
    접속 지향 순차 전송 환경에서 접속을 관리하기 위한 방법.
  16. 제 15 항에 있어서,
    상기 라우터가 상기 적어도 하나의 메시지를 포워딩하면, 상기 라우터는 리소스 예약을 위한 요구에 연관된 접속을 설정하는데 수반된 클라이언트 서버 쌍에 연관된 제 2 유형의 메시지를 수신할 때까지 다른 리소스 예약 요구를 중지시키는
    접속 지향 순차 전송 환경에서 접속을 관리하기 위한 방법.
  17. 제 15 항에 있어서,
    적어도 하나의 메시지는 접속이 폐쇄되는 경우에 리소스 예약을 취소하는데 사용되는
    접속 지향 순차 전송 환경에서 접속을 관리하기 위한 방법.
  18. 제 15 항에 있어서,
    상기 예약된 리소스는 대역폭인
    접속 지향 순차 전송 환경에서 접속을 관리하기 위한 방법.
  19. 제 1 항에 있어서,
    상기 클라이언트 및 상기 서버는 각각의 애플리케이션 클라이언트와 각각의 애플리케이션 서버 사이에 접속을 각각 설정하는
    접속 지향 순차 전송 환경에서 접속을 관리하기 위한 방법.
  20. 접속 지향 순차 전송 환경에서 접속을 관리하기 위한 시스템에 있어서,
    서버,
    클라이언트,
    순차 전송을 갖는 네트워크를 포함하고,
    상기 서버는 상기 서버에 연관된 제 1 항에 따른 방법의 임의의 동작을 수행하도록 구성되고, 상기 클라이언트는 상기 클라이언트에 연관된 제 1 항에 따른 방법의 임의의 동작을 수행하도록 구성되는
    접속 지향 순차 전송 환경에서 접속을 관리하기 위한 시스템.
  21. 제 20 항에 있어서,
    라우터를 포함하고,
    상기 클라이언트와 상기 서버 사이의 메시지 중 적어도 하나는 상기 라우터를 통해 통과하고,
    상기 적어도 하나의 메시지는 리소스 예약을 위한 요구를 포함하고,
    상기 라우터는 단지 요구된 리소스를 제공하는 것이 가능한 경우에 상기 적어도 하나의 메시지를 포워딩하는
    접속 지향 순차 전송 환경에서 접속을 관리하기 위한 시스템.
  22. 제 21 항에 있어서,
    상기 라우터가 상기 적어도 하나의 메시지를 포워딩하면, 상기 라우터는 리소스 예약을 위한 요구에 연관된 접속을 설정하는데 수반된 클라이언트 서버 쌍에 연관된 제 2 유형의 메시지를 수신할 때까지 다른 리소스 예약 요구를 중지하는
    접속 지향 순차 전송 환경에서 접속을 관리하기 위한 시스템.
  23. 제 20 항에 있어서,
    상기 서버 및 상기 클라이언트는 서버 타이머 및 클라이언트 타이머를 각각 구현하기 위해 단지 하나의 타이머만을 각각 포함하는
    접속 지향 순차 전송 환경에서 접속을 관리하기 위한 시스템.
  24. 제 11 항에 있어서,
    상기 서버에서 제 3 유형의 메시지를 수신하는 것은 상기 서버로 하여금 제 4 유형의 메시지를 송신하게 하는
    접속 지향 순차 전송 환경에서 접속을 관리하기 위한 방법.
  25. 제 11 항에 있어서,
    상기 서버에서 제 6 유형의 메시지를 수신하는 것은 상기 서버로 하여금 제 4 유형의 메시지를 송신하게 하는
    접속 지향 순차 전송 환경에서 접속을 관리하기 위한 방법.
  26. 제 24 항 또는 제 25 항에 있어서,
    상기 제 4 유형의 메시지를 수신하는 것은 상기 제 2 서버 타이머를 정지시키는
    접속 지향 순차 전송 환경에서 접속을 관리하기 위한 방법.
  27. 제 11 항에 있어서,
    상기 서버에서 제 6 유형의 메시지를 수신하는 것은 상기 제 2 서버 타이머를 정지시키는
    접속 지향 순차 전송 환경에서 접속을 관리하기 위한 방법.
  28. 제 7 항에 있어서,
    상기 클라이언트에서 제 3 유형의 메시지를 수신하는 것은 상기 제 2 클라이언트 타이머를 정지시키는
    접속 지향 순차 전송 환경에서 접속을 관리하기 위한 방법.
  29. 제 7 항에 있어서,
    상기 클라이언트에서 제 6 유형의 메시지를 수신하는 것은 상기 제 2 클라이언트 타이머를 정지시키는
    접속 지향 순차 전송 환경에서 접속을 관리하기 위한 방법.
  30. 제 10 항에 있어서,
    상기 제 4 유형의 메시지를 수신하는 것은 상기 제 2 서버 타이머를 정지시키는
    접속 지향 순차 전송 환경에서 접속을 관리하기 위한 방법.
KR1020127010820A 2009-09-30 2010-09-30 접속 지향 순차 전송 환경에서 접속을 관리하기 위한 방법 및 시스템 KR20120082430A (ko)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US12/571,018 2009-09-30
US12/571,018 US20110078255A1 (en) 2009-09-30 2009-09-30 Method and system for managing a connection in a connection oriented in-order delivery environment
US12/788,205 2010-05-26
US12/788,205 US20110078313A1 (en) 2009-09-30 2010-05-26 Method and system for managing a connection in a connection oriented in-order delivery environment

Publications (1)

Publication Number Publication Date
KR20120082430A true KR20120082430A (ko) 2012-07-23

Family

ID=43357480

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020127010820A KR20120082430A (ko) 2009-09-30 2010-09-30 접속 지향 순차 전송 환경에서 접속을 관리하기 위한 방법 및 시스템

Country Status (7)

Country Link
US (1) US20110078313A1 (ko)
EP (1) EP2484087A1 (ko)
JP (1) JP2013507023A (ko)
KR (1) KR20120082430A (ko)
CN (1) CN102648612B (ko)
IN (1) IN2012DN02627A (ko)
WO (1) WO2011039332A1 (ko)

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110078255A1 (en) * 2009-09-30 2011-03-31 Andrei Radulescu Method and system for managing a connection in a connection oriented in-order delivery environment
EP2391042B1 (en) * 2010-05-27 2015-07-29 Telefonaktiebolaget L M Ericsson (publ) Efficient error handling on a link using ARQ and multiple NACKs associated with multiple error thresholds
WO2012008582A1 (ja) * 2010-07-16 2012-01-19 積水化学工業株式会社 合わせガラス用中間膜及び合わせガラス
US10812383B2 (en) * 2015-11-05 2020-10-20 Mitsubishi Electric Corporation Communication apparatus and communication method
GR1008894B (el) * 2015-12-15 2016-11-14 Arm Limited Βελτιστοποιημενη συνεχης ροη σε μια μη διατεταγμενη διασυνδεση
CN113055373A (zh) * 2017-03-30 2021-06-29 华为技术有限公司 数据传输方法和通信设备
CN110875952A (zh) * 2018-09-04 2020-03-10 中国移动通信有限公司研究院 一种基于物联网的数据响应处理方法及设备、存储介质
TW202234861A (zh) 2021-02-26 2022-09-01 韓商愛思開海力士有限公司 用於控制器中的錯誤處理的控制方法、其記錄媒體、控制器以及儲存裝置
TW202306365A (zh) 2021-07-29 2023-02-01 韓商愛思開海力士有限公司 用於互連協定的訊框接收的資料處理的方法以及儲存裝置

Family Cites Families (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6161123A (en) * 1997-05-06 2000-12-12 Intermec Ip Corporation Providing reliable communication over an unreliable transport layer in a hand-held device using a persistent session
US7720908B1 (en) * 2000-03-07 2010-05-18 Microsoft Corporation System and method for multi-layered network communications
JP2001350855A (ja) * 2000-06-09 2001-12-21 Nec Corp オンデマンドサービス展開装置およびサービス提供方式
DE10038557B4 (de) * 2000-08-03 2005-12-15 Siemens Ag System und Verfahren zur Übertragung von Daten über Datennetze, insbesondere Internet, mit asynchroner Datenverbindung
DE10038562B4 (de) * 2000-08-03 2005-12-15 Siemens Ag System und Verfahren zur Übertragung von Daten über Datennetze mit Datenumsetzung durch einen COM Automarschaller
US7730202B1 (en) * 2001-07-16 2010-06-01 Cisco Technology, Inc. Dynamic interrupt timer
US7328264B2 (en) * 2001-07-31 2008-02-05 Tandberg Telecom As System and method for fractional resource scheduling for video teleconferencing resources
CN100446613C (zh) * 2001-11-03 2008-12-24 艾利森电话股份有限公司 用于在电信网中建立连接的方法和节点
US7146427B2 (en) * 2002-04-23 2006-12-05 Lsi Logic Corporation Polling-based mechanism for improved RPC timeout handling
US7299264B2 (en) * 2002-05-07 2007-11-20 Hewlett-Packard Development Company, L.P. System and method for monitoring a connection between a server and a passive client device
KR100476457B1 (ko) * 2003-02-13 2005-03-18 삼성전자주식회사 네트워크 디지털 방송 서비스를 위한 제어 방법
JP3736641B2 (ja) * 2004-01-22 2006-01-18 セイコーエプソン株式会社 データ転送制御装置及び電子機器
US7873738B2 (en) * 2004-04-23 2011-01-18 Motorola Mobility, Inc. Session initiation protocol system timeout timer method
US7990978B1 (en) * 2004-12-17 2011-08-02 Verizon Services Corp. Dynamic bandwidth queue allocation
US7694008B2 (en) * 2005-05-04 2010-04-06 Venturi Wireless Method and apparatus for increasing performance of HTTP over long-latency links
CN100455042C (zh) * 2005-07-18 2009-01-21 华为技术有限公司 一种反向信道建立方法
JPWO2007080780A1 (ja) * 2006-01-10 2009-06-11 パナソニック株式会社 通信システム及び通信方法
US20070204046A1 (en) * 2006-02-28 2007-08-30 Puneet Batta Methods and apparatus for balanced load distribution in wireless switch architecture
US20080195912A1 (en) * 2007-02-14 2008-08-14 Nokia Corporation Method of communicatoin
DE102007011071B4 (de) * 2007-03-07 2009-06-18 T-Mobile Internationale Ag Verfahren zur Verbesserung eines TCP Datenübertragungsprozesses im Fall einer Unterbrechung des physikalischen Übertragungsmediums
US7743160B2 (en) * 2007-03-29 2010-06-22 Blue Coat Systems, Inc. System and method of delaying connection acceptance to support connection request processing at layer-7
US8000313B1 (en) * 2008-08-15 2011-08-16 Sprint Spectrum L.P. Method and system for reducing communication session establishment latency
US9338165B2 (en) * 2009-03-12 2016-05-10 Cisco Technology, Inc. Common internet file system proxy authentication of multiple servers
US8032641B2 (en) * 2009-04-30 2011-10-04 Blue Coat Systems, Inc. Assymmetric traffic flow detection

Also Published As

Publication number Publication date
WO2011039332A1 (en) 2011-04-07
CN102648612B (zh) 2015-01-14
EP2484087A1 (en) 2012-08-08
CN102648612A (zh) 2012-08-22
IN2012DN02627A (ko) 2015-09-04
US20110078313A1 (en) 2011-03-31
JP2013507023A (ja) 2013-02-28

Similar Documents

Publication Publication Date Title
KR20120082430A (ko) 접속 지향 순차 전송 환경에서 접속을 관리하기 위한 방법 및 시스템
JP4972304B2 (ja) ウェブサービス環境用の信頼できるメッセージング内の接続生存性の検証および維持
US8190960B1 (en) Guaranteed inter-process communication
US10951742B1 (en) Methods, systems, and computer program products for sharing information for detecting at least one time period for a connection
WO2014194806A1 (zh) 在多路传输控制协议中的链路处理方法和移动终端
US11463339B2 (en) Device and method for delivering acknowledgment in network transport protocols
JP2006229399A (ja) 通信システム、中継ノード及びそれらに用いる通信方法並びにそのプログラム
US20110078255A1 (en) Method and system for managing a connection in a connection oriented in-order delivery environment
US8418017B2 (en) Adaptive acknowledgment mechanism for network communication
Seggelmann Sctp: Strategies to secure end-to-end communication
US20120072520A1 (en) System and Method for Establishing Reliable Communication in a Connection-Less Environment
Cisco Stream Control Transmission Protocol (SCTP) Release 2
WO2023016646A1 (en) A device and method for remote direct memory access
WO2021249651A1 (en) Device and method for delivering acknowledgment in network transport protocols
JP2006148727A (ja) アプリケーションモニタ装置
Cisco Stream Control Transmission Protocol (SCTP) Release 1
KR101587332B1 (ko) 컨트롤러와 네트워크 장치 간 연결 상태 확인 방법
US20230327812A1 (en) Device and method for selective retransmission of lost packets
US20220201070A1 (en) Distributed Session Owner Across Multiple Entities
CN115150332A (zh) 传输控制方法、装置及系统
KR100812822B1 (ko) 무선 네트워크 시스템에서 목적지 상태에 기초한 무선데이터 통신 방법
König et al. 5 Protocol functions
Klaver Using NSIS (Next Steps in Signaling) for support of QoS aware multimedia services
Durand et al. Message Reliability Protocol Standards for Web Services: An Analysis

Legal Events

Date Code Title Description
A201 Request for examination
E902 Notification of reason for refusal
E601 Decision to refuse application