KR100860152B1 - 순차 번호를 통한 데이터 통신 코디네이션 - Google Patents

Abstract

서버 자원을 클라이언트가 사용하는 것을 제어하기 위해 클라이언트-서버 통신에 관한 순차 번호가 기술된다. 서버는 클라이언트에 크레디트를 수여하고, 클라이언트는 서버에 명령을 보낼 때마다 크레디트를 소모한다. 각 크레디트는 순차 번호에 해당하고, 일련의 순차 번호들은 유효 명령 윈도우(valid command window)를 형성한다. 서버는 각 수신된 명령에 관해서 명령이 유효 명령 윈도우 내의 순차 번호를 포함하고, 상기 순차 번호는 다른 명령에 사용되지 않았다는 것을 강제한다. 서버는 또한 최대 윈도우 크기를 유지해서 크레디트를 가진 클라이언트가 최대 순차 번호를 초과하는 순차 번호를 가진 명령을 보내지 못하도록 할 수 있다. 이를 데이터 통신 프로토콜에 편입시에, 서비스 품질(quality of service), 서비스 거부에 대항(combating denial of service), 메시지 손실의 탐지, 서버 자원의 분산, 보안 메시지 서명 및 다른 다수의 이점이 생긴다.

순차 번호, 크레디트, 유효 명령 윈도우

Description

순차 번호를 통한 데이터 통신 코디네이션{DATA COMMUNICATION COORDINATION WITH SEQUENCE NUMBERS}

본 발명은 첨부 도면에서 제한되지 않는 예시를 통해 설명되며, 같은 도면부호는 유사한 구성요소를 지시한다.

도 1은, 본 발명의 다양한 측면이 구체화되는 범용 연산 환경(general-purpose computing environment)의 도시적인 일례.

도 2는, 본 발명의 다양한 측면에 따라 클라이언트가 서버와 통신하는 네트워크 환경의 일례를 표현하는 블록도.

도 3 내지 13은, 본 발명의 다양한 측면에 따라 순차 번호(sequence number)를 사용하기 위해 관리되는 클라이언트 및 서버 데이터의 표현.

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

202: 클라이언트

204: 서버

330s: 유효 동작 윈도우

320: 기준/수여 데이터

322: 할당기

본 출원은 2005년 5월 25일에 출원된 미국 가특허출원 제60/685,008호에 대한 우선권을 주장하며, 이 가특허출원은 참조로 본 명세서에 편입된다. 본 출원은, 본 출원과 동시에 출원되며 본 발명의 양수인에게 양수되는, 대리인 관리 번호 제5612/311754호, "Data Communication Protocol"이라는 명칭의 계류 중인 미국 특허출원과 관련되며, 상기 특허출원은 참조로 본 명세서에 편입된다.

서버 메시지 블록(Server Message Block; SMB) 프로토콜과 같이 지금도 여전히 사용되고 있는 많은 데이터 통신 프로토콜은, 연산 자원(computing resources)이 지금과 매우 달랐던 - 예컨대, 네트워크 대역폭이 대체로 얼마 되지 않으며 기억장치(memory)가 매우 고가였던 - 때에 개발된 것이다. 그 결과, 현재의 네트워크에서 사용될 때, 이런 프로토콜이 전체 성능(performance)을 제한할 수 있다. 예컨대, 기억장치가 얼마 되지 않던 때에 설계되었기 때문에 작은 크기의 버퍼가 사용되어서, 많은 양의 데이터를 통신하기 위해서는 더 많은 왕복(round trip)을 필요로 하게 된다.

더구나, 기존의 SMB 프로토콜은 시간이 흐름에 따라 명확하게 된 또 다른 제한도 가진다. 예컨대, 기존의 SMB 프로토콜은 서비스 거부(denial of service; DoS) 공격에 취약한데, 상기 프로토콜의 설계는 이들 공격에 대항하는 것을 곤란하다. 게다가, 패킷 보안을 확보하기 위한 방법이 번거롭다. 또한, 서비스 품질 유사(quality of service-like; QoS-like) 동작(operation) - 예컨대, 신뢰할 수 있 는 클라이언트(trusted client)가 신뢰할 수 없는 클라이언트(untrusted client)와 동일한 서버 자원을 획득하는 - 을 수행하기 위한 메커니즘이 현재 없다. 요컨대, 여전히 빈번히 사용되고 가치있는 프로토콜이기는 하지만, 기존의 SMB 버전(version)은 현대의 네트워크 자원과 함께 사용될 때에 이상적이지는 않다.

간단히 말해서 본 발명의 다양한 측면은, 클라이언트의 서버 자원 사용을 제어하기 위해, 데이터 통신 프로토콜로 편입될 수 있는, 클라이언트-서버 통신에 관한 순차 번호(sequence number)의 사용에 관한 것이다. 다양한 측면이, 오더링(ordering)이 중요하지는 않은 프로토콜에 적용되나, 서비스 품질(QoS), 서비스 거부(DoS) 대항, 서버 자원의 분할, 안전한 메시지 서명(signing) 및 다른 많은 이익을 제공한다.

서버는 클라이언트에게 크레디트(credit)들을 부여하고, 클라이언트는 각각의 명령(command)을 서버로 전송하기 위해 크레디트를 사용한다. 크레디트 각각은 순차 번호와 대응되고, 순차 번호들의 집합은 유효 명령 윈도우(valid command window)를 형성한다. 서버는 각각의 수신된 명령마다 유효 명령 윈도우 내의 순차 번호를 포함하며, 그 순차 번호는 다른 명령에 사용되지 않았을 것을 강제한다. 서버는 또한 최대 윈도우 크기를 관리하여, 최대 윈도우 크기에 해당하는 최대 순차 번호를 넘어서는 순차 번호를 가진 명령은 크레디트를 가진 클라이언트라고 하더라도 전송할 수 없도록 할 수 있다.

일반적으로, 클라이언트로부터 명령을 수신하면, 서버는 순차 번호가 윈도우 내에 있으며 이전에 사용되지 않은 것인지를 검증한다. 이어서, 서버는 클라이언트가 사용할 수 있는 순차 번호 중에서 해당 순차 번호를 제거함으로써, 하나의 크레디트를 소모한다. 이어서, 서버는 클라이언트에게 하나 이상의 다른 크레디트를 부여할지 여부를 결정한다.

그래서, 클라이언트에게 부여되는 각각의 크레디트에 대한 고유한 번호를 포함하고 있는 유효 동작 윈도우를 통해서 클라이언트에게 부여된 다수의 크레디트를 제어하는 것에 의해, 서버 자원의 사용을 제한하는 메커니즘이 제공된다. 강제(enforcement) 메커니즘은, 수신된 명령에 따른 서버 동작을 허용하기 위해서 명령이 유효 동작 윈도우 내에 있는 순차 번호를 포함하고, 그 고유한 번호가 다른 명령과 함께 사용된 적이 없는 순차 번호를 그 명령이 포함할 것을 보장한다. 할당(allocation) 메커니즘은, 클라이언트에게 부여된 크레디트와 유효 동작 윈도우 내의 고유한 번호들을 제어한다.

다른 이점들(advantages)은 하기의 상세한 설명으로부터, 도면과 함께 해석될 때, 명확하게 될 것이다.

예시적 운영 환경(exemplary operating environment)

도 1은, 본 발명이 구현될 수 있는, 적합한 연산 시스템 환경(100)의 일례를 도시한다. 본 연산 시스템 환경(100)은 적합한 연산 환경의 단지 일례일 뿐이며, 본 발명이 사용 범위나 기능성 범위에 어떠한 한정도 시사하려는 것이 아니다. 또한, 연산 환경(100)은, 예시적 운영 환경(100)에서 도시되는 컴포넌트(component) 중 어느 하나 또는 조합과 관련된 어떤 의존이나 필요를 가지는 것으로 해석되어서는 안 된다.

본 발명은, 수많은 다른 범용 또는 특수목적 연산 시스템 환경 또는 구성을 가지고서도 동작할 수 있다. 본 발명과 함께 사용되기에 적합할 수 있는 잘 알려진 연산 시스템, 환경 및/또는 구성의 예(examples)로는, 개인용 컴퓨터(personal computer; PC), 서버 컴퓨터, 핸드헬드 또는 랩톱 장치, 타블렛 장치, 다중프로세서 시스템, 다중프로세서 기반 시스템, 셋톱 박스, 프로그램가능 가전 제품, 네트워크 PC, 미니컴퓨터, 메인프레임 컴퓨터, 그리고 상기 시스템이나 장치 중 어떤 것을 포함하는 분산 연산 환경 등을 포함하지만, 이것에 제한되는 것은 아니다.

본 발명은 일반적인 맥락에서, 컴퓨터에 의해 실행되는, 프로그램 모듈과 같은 컴퓨터 실행가능 명령어(computer-executable instructions)로 서술될 수 있다. 일반적으로 프로그램 모듈은 루틴(routine), 프로그램, 객체(object), 컴포넌트, 데이터 구조 등을 포함하는데, 이들은 특정한 작업을 수행하거나 특정한 추상 데이터 타입(abstract data type)을 구현한다. 본 발명은 또한, 통신 네트워크를 통해 연결되어 있는 원격 처리 장치들에 의해 작업이 수행되는 분산 연산 환경에서 실시될 수 있다. 분산 연산 환경에서, 프로그램 모듈은 메모리 저장 장치를 포함하는 로컬 및/또는 원격 컴퓨터 저장 매체에 위치할 수 있다.

도 1을 참조하면, 본 발명을 구현하기 위한 예시적 시스템은 컴퓨터(110) 형태의 범용 연산 장치를 포함한다. 컴퓨터(110)의 컴포넌트는 처리장치(120), 시스템 메모리(130), 그리고 시스템 메모리를 포함하는 다양한 시스템 컴포넌트를 처리 장치(120)에 연결하는 시스템 버스(121)를 포함하지만, 이것에 제한되는 것은 아니다. 시스템 버스(121)는, 메모리 버스나 메모리 컨트롤러, 외부 버스(peripheral bus) 및 로컬 버스 - 다양한 버스 아키텍처 중 어느 것이든 사용됨 - 를 포함하는 여러 타입의 버스 구조 중 어떤 구조라도 될 수 있다. 제한이 아닌 예시로서, 이러한 아키텍처는, ISA(Industry Standard Architecture) 버스, MCA(Micro Channel Architecture) 버스, EISA(Enhanced ISA) 버스, VESA(Video Electronics Standards Association) 로컬 버스, 및 메짜닌 버스(Mezzanine bus)라고도 알려진 PCI(Peripheral Component Interconnect) 버스를 포함한다.

컴퓨터(110)는 대체로 각종 컴퓨터 판독가능 매체를 포함한다. 컴퓨터 판독가능 매체는 컴퓨터(110)에 의해 접근 가능한 어떤 이용가능한 매체라도 될 수 있으며, 휘발성 및 비휘발성 매체, 착탈식 및 고정식 매체를 모두 포함한다. 제한이 아닌 예시로서, 컴퓨터 판독가능 매체는 컴퓨터 저장 매체 및 통신 매체를 포함할 수 있다. 컴퓨터 저장 매체는, 컴퓨터 판독가능 명령어, 데이터 구조, 프로그램 모듈 또는 다른 데이터와 같은 정보를 저장하기 위한 어떤 방법 또는 기술로든 구현된, 휘발성 및 비휘발성, 착탈식 및 고정식 매체를 포함한다. 컴퓨터 저장 매체는, 램(RAM), 롬(ROM), 이이피롬(EEPROM), 플래시 메모리, 또는 다른 메모리 기술, 시디롬(CD-ROM), DVD(digital versatile disk), 또는 다른 광 디스크 저장장치, 자기 카세트, 자기 테이프, 자기 디스크 저장장치, 또는 다른 자기 저장 기기, 또는 원하는 정보를 저장하기 위해 사용될 수 있고 컴퓨터(110)에 의해 접근될 수 있는 어떤 다른 매체든지 포함하지만, 이것에 제한되는 것은 아니다. 통신 매체는, 전 형적으로 컴퓨터 판독가능 명령어, 데이터 구조, 프로그램 모듈 또는 다른 데이터를 캐리어 파와 같은 변조된 데이터 신호 또는 다른 전송 메커니즘(transport mechanism)에 구체화하는데, 임의의 정보 전달 매체를 포함한다. "변조된 데이터 신호"라는 용어는, 신호에 정보를 인코딩(encode)하는 방식으로 설정이나 변경되는 하나 이상의 특성을 가지는 신호를 의미한다. 제한이 아닌 예시로서, 통신 매체는, 유선 네트워크나 직접 유선 연결(direct-wired connection)과 같은 유선 매체, 그리고 음파, 무선 주파수(radio frequency; RF), 적외선 및 다른 무선 매체와 같은 무선 매체를 포함한다. 상기한 것 중 어떤 것의 조합이든 역시 컴퓨터 판독 가능 매체의 범위 내에 포함되어야 한다.

시스템 메모리(130)는, 롬(read only memory; ROM)(131) 및 램(random access memory; RAM)(132)과 같은 휘발성 및/또는 비휘발성 메모리 형태의 컴퓨터 저장 매체를 포함한다. 예컨대 시동(start-up) 중에 컴퓨터(110) 내의 구성요소 간에 정보를 전달하는 것을 돕는 기본적인 루틴을 포함하는 바이오스(133)(basic input/output system; BIOS)는 일반적으로 롬(131)에 저장된다. 램(132)은 일반적으로, 처리장치(120)에 의해서 즉시 접근가능하고/접근가능하거나 현재 작동되고 있는, 데이터 및/또는 프로그램 모듈을 포함한다. 제한이 아닌 예시로서, 도 1은 운영체제(134), 응용 프로그램(135), 기타 프로그램 모듈(136) 및 프로그램 데이터(137)를 도시한다.

컴퓨터(110)는 또한 다른 착탈식/고정식, 휘발성/비휘발성 컴퓨터 저장 매체를 포함할 수 있다. 예시만으로서, 도 1은 고정식 비휘발성 자기 매체에 대한 판 독 및 기록을 하는 하드 디스크 드라이브(141), 착탈식 비휘발성 자기 디스크(152)에 대한 판독 및 기록을 하는 자기 디스크 드라이브(151), 그리고 시디롬 또는 다른 광 매체와 같은 착탈식 비휘발성 광 디스크(156)에 대한 판독 및 기록을 하는 광 디스크 드라이브(156)를 도시한다. 예시적 운영 환경에서 사용될 수 있는 또 다른 착탈식/고정식, 휘발성/비휘발성 컴퓨터 저장 매체는, 자기 테이프 카세트, 플래시 메모리 카드, DVD, 디지털 비디오 테이프, 솔리드 스테이트 램(solid state RAM), 솔리드 스테이트 롬(solid state ROM) 등을 포함하지만, 이것에 제한되는 것은 아니다. 하드 디스크 드라이브(141)는 일반적으로 인터페이스(140)와 같은 고정식 메모리 인터페이스를 통해 시스템 버스(121)에 연결되며, 자기 디스크 드라이브(151) 및 광 디스크 드라이브(155)는 통상적으로 인터페이스(150)와 같은 착탈식 메모리 인터페이스에 의해 시스템 버스(121)에 연결된다.

위에 서술되고, 도 1에 도시된, 드라이브 및 이에 관련된 컴퓨터 저장 매체는 컴퓨터 판독가능 명령어, 데이터 구조, 프로그램 모듈 및 다른 데이터의 저장 장치를 컴퓨터(110)에 제공한다. 예컨대 도 1에서 하드 디스크 드라이브(141)는 운영체제(144), 응용 프로그램(145), 기타 프로그램 모듈(146) 및 프로그램 데이터(147)를 저장하는 것으로 도시된다. 이들 컴포넌트는 운영체제(134), 응용 프로그램(135), 기타 프로그램 모듈(136) 및 프로그램 데이터(137)와 동일할 수도 있고 다를 수도 있다는 것을 유념해야 한다. 여기서 운영체제(144), 응용 프로그램(145), 기타 프로그램 모듈(146) 및 프로그램 데이터(147)에는 별도의 도면번호를 부여하여, 적어도 별도의 사본(copy)이라는 것을 도시하고 있다. 사용자는, 타블 렛(또는 전자 디지타이저(electronic digitizer))(164), 마이크로폰(163), 키보드(162) 및 일반적으로 마우스, 트랙볼 또는 터치패드로 불리는 포인팅 장치(161)와 같은 입력 장치를 통해 컴퓨터(110)에 명령 또는 정보를 입력할 수 있다. 도 1에 도시되지 않은 다른 입력 장치는 조이스틱, 게임 패드, 위성 접시 안테나(satellite dish), 스캐너 등을 포함할 수 있다. 이들 및 다른 입력 장치는, 흔히 시스템 버스에 연결된 사용자 입력 인터페이스(160)를 통해 처리장치(120)에 연결되지만, 병렬 포트(parallel port), 게임 포트 또는 USB(universal serial bus)와 같은 다른 인터페이스 및 버스 구조에 의해 연결될 수도 있다. 모니터(191) 또는 다른 타입의 디스플레이 장치도 또한 비디오 인터페이스(190)와 같은 인터페이스를 통해 시스템 버스(121)에 연결된다. 모니터(191)는 또한 터치스크린 패널 등과 통합될 수도 있다. 모니터 및/또는 터치스크린 패널은, 타블렛 타입 개인용 컴퓨터와 같은, 연산 장치(110)가 편입된 하우징(housing)에 물리적으로 결합될 수 있다는 점을 유념해야 한다. 덧붙여, 연산 장치(110)와 같은 컴퓨터는 또한, 스피커(195) 및 프린터(196)와 같은 다른 외부 출력 장치를 포함할 수 있는데, 이들은 출력 주변장치 인터페이스(194) 등을 통해 연결될 수 있다.

컴퓨터(110)는, 원격 컴퓨터(180)와 같은 하나 이상의 원격 컴퓨터에 대한 논리적 연결을 사용하는 네트워크된 환경에서 동작할 수도 있다. 원격 컴퓨터(180)는 개인용 컴퓨터, 서버, 라우터(router), 네트워크 PC, 피어(peer) 장치 또는 다른 일반적인 네트워크 노드가 될 수 있다. 원격 컴퓨터(180)는, 비록 도 1에는 메모리 저장 장치(181)만이 도시되었지만, 일반적으로 컴퓨터(110)와 관련하여 위에 서술한 구성 요소의 다수 또는 전부를 포함한다. 도 1에 도시된 논리적 연결은 LAN(local area network)(171) 및 WAN(wide area network)(173)을 포함하지만, 다른 네트워크를 포함할 수도 있다. 이러한 네트워킹 환경은 사무실, 기업 범위 컴퓨터 네트워크, 인트라넷 및 인터넷에서 흔한 것이다.

LAN 네트워킹 환경에서 사용될 때, 컴퓨터(110)는 네트워크 인터페이스 또는 어댑터(adaptor)(170)를 통해 LAN(171)에 연결된다. WAN 네트워킹 환경에서 사용될 때, 컴퓨터(110)는 전형적으로 모뎀(172) 또는 인터넷과 같은 WAN(173)을 통해 통신을 설립하기 위한 다른 수단들을 포함한다. 내장형 또는 외장형이 될 수 있는 모뎀(172)은 사용자 입력 인터페이스(160) 또는 다른 적절한 메커니즘을 통해 시스템 버스(121)에 연결될 수 있다. 네트워크된 환경에서, 컴퓨터(110)에 관련해 묘사된 프로그램 모듈 또는 그 일부분은 원격 메모리 저장 장치에 저장될 수도 있다. 제한이 아닌 예시로서, 도 1은 메모리 장치(181) 상에 존재하는 것으로서 원격 응용 프로그램(185)을 도시한다. 도시된 네트워크 연결은 예시적인 것이고, 컴퓨터 간에 통신 링크를 설립하는 다른 수단이 사용될 수도 있다는 것이 인식될 수 있을 것이다.

순차 번호를 사용한 데이터 통신 코디네이션(data communication coordination with sequence numbers)

본 명세서에서 서술되는 기술의 다양한 양상은, SMB 프로토콜의 수정 버전(2.x 이상)과 같은 데이터 통신 프로토콜에 채용될 수 있는 메커니즘에 대한 것이 다. 본 명세서에 전반적으로 기술되는 구현의 일례에서, 상기 메커니즘은, Windows^® 기반 파일 공유를 위해 사용되는 상기 개정된 SMB 프로토콜 내에서 데이터/명령 흐름을 제어한다. 하지만, 용이하게 이해될 수 있는 바와 같이, 본 발명은 Windows^® 기반 시스템 또는 SMB 프로토콜에 제한되는 것이 아니다. 오히려, 본 예시 기술은 다른 파일 공유 프로토콜 및 파일 데이터를 필수적으로 다루지는 않는 프로토콜을 포함하는 데이터 통신 프로토콜에도 일반적으로 적용 가능하다. 예컨대, 본 발명을 구현하기 위한 다수의 방법이 가능한데, 프린터, 네임드 데이터 파이프(named data pipe), 제네릭 디바이스(generic device) 등과의 통신에 사용하기 위한 것을 포함한다. 이와 같이, 본 발명은 본 명세서에서 사용되는 특정한 파일 기반 또는 다른 예들 중 어느 것에도 제한되지 않으며, 오히려 일반적으로 연산하는 데에 이익 및 이점을 제공하는 수많은 방법으로 사용될 수 있다.

도 2를 살펴보면, 하나 이상의 통신 채널을 통해 클라이언트(202)가 서버(204)와 통신하는 네트워킹 환경의 일례를 나타내는 블록도가 도시되어 있다. 클라이언트 머신(client machine)(202) 및 서버(204)의 기능 및 컴포넌트는, 도 1의 메인 컴퓨터 시스템(110) 및 원격 컴퓨터 시스템(180)과 같은 두 개의 구별되는 컴퓨터 내에 위치하는 것으로 기술되었지만, 이 두 컴퓨터의 컴포넌트나 이에 의해 수행되는 기능은 하나의 머신(machine)에서 제공될 수도 있으며, 다수의 컴퓨터에 분산될 수도 있다. 예컨대, 컴퓨터 시스템은 프린터 서버나 프린터 자체, 또는 NAS 저장 장치 등과 같은 각종 네트워크 설비 제품 중 하나를 포함할 수 있다.

응용 프로그램(206)으로부터의 네트워크 파일 시스템 명령은 클라이언트 리디렉터 컴포넌트(208)에 의해 처리되는데, 이는 파일 시스템(212) 상에서 명령어를 실행하는 상대방 공통 네트워크 모듈 (SRVNET)(210)과 통신한다. 보통, 클라이언트(202)는 연결을 설정하고 난 후, 서버(204)와 협상해서 종국에는 세션을 설정한다. 이것의 일부분으로서, 파일 시스템-지향 명령어가 처리되기 전에, 클라이언트 및 서버는 통신 프로토콜을 합의한다. 본 예에서, 이 연결/세션에 관한 합의된 프로토콜은 SMB 2.0인데, 이에 의해 클라이언트측 SMB 엔진(220)은 서버(204)와의 통신을 위해 SMB 2.0 드라이버를 채택한다. 유사하게 공통 네트워크 모듈(SRVNET)(210)은 이 연결을 통해 클라이언트 통신을 처리하기 위해 SMB 2.0 프로바이더(226)를 채용한다. 프로바이더(226)는 이하에서 설명하는 바와 같이, 클라이언트가 적절한 순차 번호를 사용한다는 것을 확보하는 데이터 구조 및 강제 메커니즘을 포함하거나 그렇지 않으면 이들과 연관된다.

순차 번호를 이용한 데이터 통신 코디네이션의 개념에서, 순차 번호는 소정의 클라이언트가 서버에 대해 발행할 수 있는 작업의 양을 조절할 수 있는 메커니즘을 제공한다. 이해될 수 있는 바와 같이, 이것은 소정의 명령을 식별시, 클라이언트가 사용하도록 된 이용가능한 순차 번호들의 윈도우를 서버가 제공하도록 해서 달성된다. 순차 번호들과 원하는 동작을 구현하기 위해, 크레디트(credit)의 개념이 채택되는데, 크레디트는 클라이언트에 서버측 자원 부분을 소모할 권리를 주는데, 여기에는 동작 및 그것이 소모할 수 있는 CPU 사이클을 소모하는데 필요한 메모리를 포함한다. 클라이언트는 각 보내어지는 명령에 대해 크레디트를 소모하는 데, 서버의 응답에 종속하고, 0개 또는 하나 이상의 추가 크레디트를 받을 수도 있다. 클라이언트는 순차 번호를 재사용할 수 없어서 클라이언트가 발행할 수 있는 명령의 수는 제어된다. 편의를 위해 단조로 증가하는 순차 번호가 사용되지만, 임의의 고유(세션/연결 당) 번호도 사용될 수 있음을 주목하라.

예컨대, 서버가 클라이언트에 5개 크레디트를 주면, 서버는 클라이언트에 5개의 동작을 동시에 제출할 수 있는 권리를 주는 것이다. 서버가 클라이언트를 억제할 필요가 있으면, 서버는 그 클라이언트에 대해 이용가능한 크레디트를 줄여서 억제한다. 서버가 클라이언트에게 일할 더 많은 자원을 주기를 원하면, 서버는 크레디트를 주어서 그러할 수 있다.

상기 방식은 서버에 여러 선택사항을 준다. 서버는 클라이언트에 0개의 크레디트를 주어서 클라이언트에 할당된 자원을 감소시키거나, 한 개의 크레디트를 반환해서 이전 윈도우 크기를 유지하거나, 하나 초과의 크레디트를 반환해서 명령을 실행하기 위해 더 많은 자원을 클라이언트에 허용한다. 한가지 제한은 프로토콜이 엄격한 명령-응답 프로토콜이라는 가정 아래에서 서버가 무리(band)를 벗어난 크레디트를 수여하는 방법을 구비하지 않으면, 서버는 윈도우 크기가 0(유효한 순차 번호가 없음)이 되도록 할 수 없다는 것이다. 본 방법에서 사용되는 프로토콜 내에서 클라이언트가 크레디트를 청하도록 요구하지 않고 클라이언트에 크레디트를 수여하는 방법이 있다면, 상기 제한은 적용되지 않는다는 것을 주목하라.

협상 요청/응답은 0의 순차 번호(또는 메시지 식별자 또는 MID라고도 불림)를 가지고, 윈도우 크기가 1임을 주목하라. SMB 2.0에서, 다음의 헤더는 그런 정 보의 전달을 촉진하는데, 앞에서 관련되어 언급된 동시 출원 중인 미국 특허 출원 "Data Communication Protocol"에 더 기술되어 있다.

상기 헤더 구조로부터 알 수 있는 바와 같이, 클라이언트는 원하는 만큼의 크레디트를 요청하지만, 서버는 크레디트를 클라이언트에 수여하는 것을 제어한다. 그래서, 서버는 클라이언트의 식별, 행동, 또는 임의의 다른 속성 또는 기준에 기반해서 윈도우를 줄이거나 늘리는 능력을 구비한다. 순차 번호는 또한 소정의 연 결에 관해 클라이언트로부터 서버로 보내어진 명령을 고유하게 식별하는 방법도 제공한다.

클라이언트 및 서버는 명령 윈도우를 설정해서 시작된다. 명령 윈도우는 디폴트나 타협이 이뤄진 초기 순차 번호(ISN)(초기 메시지 식별자, 또는 MID라고도 언급됨)와 주어진 명령을 식별하기 위해 수용될 허용가능한 번호들의 범위를 나타내는 크레디트 수(Number of count; NoC)를 이용해서 시작한다. 그래서, 명령 윈도우는 초기에 [ISN, ISN+NoC-1]을 포함한다. 대부분의 프로토콜에 있어서, 디폴트는 ISN=1, NoC=1일 수 있는데, 그래서 최초 협상시에 명령 윈도우는 단순히 [1, 1]인데, 이는 서버가 명령을 식별하기 위해 수용할 유일한 순차 번호는 일(1)임을 나타낸다.

통신이 진행됨에 따라, 클라이언트는 범위 내의 번호들을 모두 사용해서 윈도우 내의 번호들을 감소시킨다. 번호가 일단 사용되면, 서버에 의해 강제되어 재사용될 수 없다. 동시에, 서버에 의해 결정되는 바와 같이, 서버는 더 많은 크레디트를 클라이언트에 수여해서 윈도우의 말단을 확장할 수 있다. 예를 들어, 명령어 윈도우가 [A, B]이면, 클라이언트가 명령 A를 송신하면, 유효한 명령 윈도우는 실질적으로 [A+1, B]가 된다. 서버가 명령 A에 응답할 때, 0부터 임의의 실질적인 번호의 크레디트 중 임의의 것을 클라이언트에 제공할 수 있다. 그래서, 서버가 N 크레디트를 반환하면, 유효한 명령 윈도우는 [A+1, B+N]이 된다.

허용가능한 범위의 순차 번호의 사용은 순서대로일 필요는 없다. 그 번호가 유효한 영역 내에서 사용된다면 순차 번호의 비동기적인 사용이 촉진되도록 프로토 콜이 설정된다. 이것은 네트워크 프로토콜이 순서대로 발신하도록 하는 대신에, 패킷들이 이용가능할 때 패킷들을 발신하도록 한다. 그래서, 순차 번호 A가 매우 큰 패킷을 위해 요구하지만, 버퍼들이 준비되는 동안에 A+1 및 A+2를 위한 발신이 오고 매우 작으면, (윈도우의 말단이 A+2 이상이면) A의 발신이 시작되기를 기다리지 않고 A+1 및 A+2를 보내는 것이 적법하다.

[1, 5]의 유효 명령 윈도우가 있고 패킷 2, 3, 4가 발송되면, 서버는 {2, 3, 4}를 제외한 [1, 8]의 윈도우(2에서 4를 제외한 1 및 8 사이의 모든 번호를 의미함)를 허가하는 크레디트를 다시 수여할 수 있다. 결국, 서버는 패킷 1이 발송되고 윈도우가 슬라이드 될 수 있을 때까지, 크레디트의 수여를 멈출 것이다. 이 시점에서 클라이언트가 1을 발송하고 서버가 크레디트 수여에 응답하면, 윈도우는 [5, 9]가 된다.

유효 명령 윈도우의 강제가 서버측에서 이루어진다. 이 시스템은 유일하게 요구되는 동기 방법으로서 현재 순차 번호 및 최대 순차 번호를 가지고 인터록된(interlocked) 비교 및 증가를 사용하는 것과 같이 클라이언트측의 구조를 단순화되도록 한다.

그래서, 유효 명령 윈도우(또는 유효 동작 또는 유효 Op 윈도우라고 불림)는 서버가 수신할 유효 식별자(valid identifier)의 윈도우를 포함한다. 클라이언트는 다음 유효 순차 번호와 같이 (유효 크레디트까지) 각 후속 명령을 보내고, 유효 윈도우의 뷰를 관리할 필요는 없다. 클라이언트는 후술할 "최대 윈도우 크기(Maximum Window Size)"의 개념을 이행할 필요가 있다. 유효 명령/동작 윈도우 사 용의 예는 다음과 같다.

변화-통보(change-notify)나 네임드-파이프 판독(named-pipe read)과 같이 양이 정해지지 않은 시간 동안 블로킹할 수 있거나 (오프록 브레이크(oplock break) 상에 계류 시에) 생성될 수 있는 임의의 동작은 블로킹 동작으로 간주 된다. 그런 동작들을 촉진하기 위해, 클라이언트는 "동작 컨텍스트(operation context)" 값 즉, 블로킹 플래그를 명령 발신에 공급할 수 있다. 그 후, 서버는 그 동작을 성공적으로 개시할 때에 응답해서, 상기 동작이 서버측에서 여전히 진행중임에도 순차 번호가 증가하도록 응답할 것이다. 그러나 그런 장기간 진행되는 동작에 의해 사용되는 자원은 흔히 정상 명령에 필요한 자원의 서브세트(subset)일 수 있다. 따라서, 서버는 클라이언트가 소모할 수 있는 "블로킹 Op 크레디트(LOC(long-operation credit)라고 불리기도 함)"의 최대 번호를 결정할 수 있다. 순차 번호는 또한 클라이언트가 소모할 수 있는 자원의 수를 제어해서 균형을 잡은 장시간 진행 명령 및 서버로부터의 다중 응답을 가진 명령을 참작한다.

그래서, 유효 명령 윈도우의 확장은 윈도우가 정상과 같이 슬라이드할 수 있도록 하고, 비한정된 시간이 소요되는 동작에 의해 지체되지 않도록 한다. 이를 위해, 클라이언트는 서버에 의해 소정의 수의 블로킹 Op 크레디트를 서버로부터 부여받고, 블로킹 Op 플래그와 함께 발행된 임의의 동작은 블로킹 Op 크레디트를 소모할 것이다. 서버가 명령을 수신시에, 서버는 장시간 유지되는 명령의 수신을 알리고 장시간 유지되는 명령(비동기 식별자(AsyncID)로 불리기도 함)을 반환하는 플래그 세트와 함께 클라이언트에 인터림 응답(interim response)을 다시 보낼 수 있 다. 이 응답은 유효 명령 윈도우를 보통처럼 슬라이드하도록 한다. 장시간 유지되는 명령이 완료되면, 새 응답이 클라이언트에 어떤 패킷에 응답하고 있는지를 나타내는 장시간 유지되는 명령 ID을 이용해서 보내어진다. 이 발신-응답-응답(send-response-response) 아키텍처는 윈도우가 계속 움직이도록 하고, 크레디트 메커니즘은 서버가 클라이언트가 얼마나 많은 자원을 소모할 수 있는지에 관한 제어를 유지하도록 한다. 또한 클라이언트로부터 진행되는 장시간 유지되는 동작이 다수 있다면 서버는 유효 명령 윈도우를 축소할 수 있다.

또 다른 구현은 클라이언트가 서버에 장시간 유지되는 명령이 올 수 있다는 것을 암시하도록 하는 프로토콜을 포함한다. 비동기 개념의 또 다른 구현은 클라이언트가 임시 "수용(accept)" 등을 발행할 수 있어서, 비동기/블로킹 동작이 단순히 "send-rec-rec" 형태와 반대로 "send-rec-send-rec"의 형태를 가지도록 한다. 일부 하부 전송(예컨대, TCP)은 흔히 요청-응답 트래픽(request-response traffic)을 수행해서 요청-응답-응답 상태에서의 지연을 유도할 수 있음을 주목하자.

프로토콜 및 전송의 비동기적 성질로 인해, 현재의 유효 윈도우는 현재 최소 일련 ID 더하기 크레디트가 정확하게는 아닌데, 일부 중간 명령이 먼저 수신될 수 있거나 예컨대 일련 ID=1인 명령이 처리하는데 장시간이 소요될 수도 있기 때문이다. 그러나 서버는 이 유효 윈도우가 커지는 것을 멈추기 전에 얼마까지 커질지에 대한 한계를 둘 수 있다. 상기 예에 이어서, 서버는 최대 윈도우 크기를 10으로 한정할 수 있다. 서버가 패킷 1을 수신하고 처리를 완료하기 전에 패킷 2, 3, 4, 5 및 6을 수신하고 처리한다면, 이것은 유효 동작 (명령) 윈도우가 [1, 10]으로 커 질 수 있다는 것을 의미한다. 그래서, 유효한 순차 번호는 1, 7, 8, 9, 10일 수 있다. 그러나 서버가 패킷 7을 수신하고 이를 처리한다면, 유효 동작 (명령) 윈도우는 [1, 11]로 슬라이드하지 않고 수용가능한 순차 번호 1, 8, 9, 10을 가진 [1, 10]에 남아있다. 명령 8에 대한 응답은 (-1) 크레디트가 클라이언트에 클라이언트가 수용가능한 한계에 이르고 있다, 즉 크레디트 값이 현재 4라는 것을 말한다는 것을 나타낼 수 있다. 윈도우를 원활하게 슬라이딩하는 것을 방해하는 순차적인 소정의 번호를 클라이언트가 건너뛰는 것을 서버가 방해하도록 하는 하나의 방법이다. 이것은 또한 장시간 소요될 명령들에 관해 서버에 대해 "블로킹 동작들"을 발행하는 값을 설명한다.

서버가 교차하는 집합(intersecting set)을 추정하는 것이 필요하기 때문에, 서버측에서 유효 명령 윈도우를 트랙킹하는 것을 계산하는 것은 비싸다. 이를 간단하게 하기 위해, 하나의 예시적 구현은 서버가 명령 윈도우로 되게 하는 최대 윈도우 크기로 상술한 최대 원도우 크기를 설정할 것이다. 이것이 일단 설정되면, 서버는 이 크기를 나타내는 버퍼를 할당하고, 명령들이 들어옴에 따라 버퍼의 위치에서의 값이 변경된다. 윈도우 크기가 최대 윈도우 크기 이하이면, 윈도우의 시작이 앞으로 진행됨에 따라 서버가 버퍼의 포인터를 앞으로 이동시킨다. 유사하게, 크레디트가 수여됨에 따라 말단이 커지면, 서버는 그 말단 포인터를 버퍼를 따라 움직인다. 산술은 버퍼가 최대 윈도우 크기를 "포함하는(wrap)" 경우를 처리한다. 더 큰 버퍼를 할당하고 현재 값들을 여기로 복사해서 최대 윈도우 크기를 동적으로 크게 하는 것이 가능하다. "이용가능(AVAILABLE)"로 시작하는, 윈도우 내의 유효 명령의 상태를 추적하기 위해 인터록된 동작(interlocked operation)이 사용될 수 있다. 클라이언트로부터 명령을 수신하면 IN_PROGRESS로 전환하고, 응답(또는 장시간 실행되는 명령 경우에 인터림 응답)이 보내지며 사용됨(USED)으로 전환한다. 사용됨으로 전환되는 값이 윈도우 내의 제1값이면, 그 윈도우는 비사용됨(non-USED) 값에 도달하기 전까지 앞으로 슬라이딩한다.

다른 구현은 서버가 다른 채널을 경유해서나 비연속적인 통신을 통해서 크레디트를 철회하도록 한다. 예컨대, 서버가 클라이언트에 10개의 크레디트를 주었다고 하자, 그러나 클라이언트를 5개의 크레디트로 삭감하기를 원한다(클라이언트가 보통은 5개의 명령을 사용하기 전에는 일어나지 않음). 클라이언트가 아이들(idle)이면, 서버는 클라이언트에 다음 N 초 동안에 5 크레디트를 사용해야만 하고 그러하지 못하고 위반되면 종결(또는 크레디트를 잃음)된다고 나타낼 수 있다. 이것은 서버가 그들의 윈도우를 이동하기 위해 클라이언트에 의존 없이, 서버가 클라이언트를 제어하도록 한다.

다양한 예를 사용해서 본 발명의 동작을 설명하면, 현재 상태는 다음 형태로 설명될 것이다.

최소 열은 클라이언트가 사용하도록 된 최소의 미사용 클라이언트 순차 번호를 나타내고, 현재 크레디트 열은 얼마나 많은 크레디트가 (정상 크레디트, 블로킹 동작 크레디트) 형태로 클라이언트에 수여되었는지를 나타낸다. 클라이언트는 발 신(send)에 크레디트를 소모하고 가능하면 (응답에 따라서) 수신시에 재증가한다. 다음 열인, "크레디트"는 클라이언트에 허가된 현재 최대 수의 크레디트를 도시한다.

유효 및 최대 열은 순차 식별자 유효에 관한 서버측 구조를 나타내는데, 클라이언트가 이들에 대해 알 필요가 없음을 주목하라. 유효 열은 이미 사용된(예컨대, 비트맵에 의해 트래킹됨) 순차 식별자의 제외와 함께 유효 동작 윈도우를 도시하고, 최대 열은 제1 동작(즉, 윈도우가 쉬프트하도록 하는 동작)을 완료하기 전에 클라이언트가 채울 수 있는 최대 명령 윈도우(MAX Command Window)를 도시한다.

도 3 내지 9는 유효 동작(Valid Op) 윈도우(330s)는 서버(204)에서 관리되면서 어떻게 자라는지에 관한 예를 나타내는데, 도 3 내지 9에서 유효 동작 윈도우가 변함에 따라 라벨의 제1 숫자가 변하는데, 예컨대 도 3은 유효 동작 윈도우(330s로 라벨됨)를 가지고, 도 4는 440s로 라벨된 유효 동작 윈도우를 가진다.

도 3에서, 클라이언트는 5개의 크레디트를 수여받고 시작하는 순차 번호 (또는 MID)는 1이다. 일반적으로 상술된 일부 기준(320)(예컨대, 클라이언트의 유형)은 할당기 컴포넌트(322)에 의해 클라이언트에 수여할 양을 결정하는데 사용된다. 이 예에서, 현재 유효 동작 윈도우는 그래서 도 5의 윈도우(330s) 내에 개별적인 숫자로 수직으로 나타내진 것과 같이 [1, 5]이다. 그래서 서버(204)는 클라이언트(202)로부터 순차 번호 1, 2, 3, 4 또는 5의 패킷을 수용할 것이다. 이것은 상술한 형태로 또한 다음과 같이 나타내진다.

유효 동작 윈도우(320s)는 간단하게 패킷을 거부하는데 사용되는데, 유효 동작 윈도우(320s) 내에 패킷이 있으면, 서버(204)는 순차 번호가 이미 사용되지 않았는지를 확보하기 위해 내부의 제외 맵(internal exception map)을 확인한다.

단조로 증가하는 수신의 전형적인 경우에, 클라이언트가 MID=1을 가진 패킷을 보내고, 클라이언트 및 서버는 도 4 및 다음의 표로 나타내진 상태로 전이하는데, [1, 5]는 유효한 것으로 고려되고, 1은 서버로부터의 응답에 관해서 진정으로 유효하고, 클라이언트로부터의 다른 수신(최소=2 확인에 의해 대해 먼저 실패할 것임)에 대해서는 그렇지 않음을 주목하라.

도 4에서, 서버는 순차 번호=1과 함께 명령을 수신하고 처리한다. 이것은 1이 더 이상 후속 명령들에 대해 유효 순차 번호가 아님을 의미하는데, 상기 표 및 도 4의 유효 동작 윈도우(430s) 내의 유효/제외 열에서 브래킷 {1}로 나타내진다.

서버가 응답시에, 서버는 클라이언트에 추가적인 (+1) 크레디트를 응답시 수여하고, 도 5 및 아래의 표에 나타낸 것과 같이 윈도우를 슬라이딩한다.

클라이언트는 현재 [2, 6]의 유효 윈도우를 구비한다. 무질서한 수신이 생길 때, 예컨대 전송 상의 비동기 발송이 서버가 명령 3을 명령 2전에 수신하고 (이 에 응답하는) 것과 같은 경우를 고려하라. 유효 동작 윈도우(630s)는 도 6 및 아래의 표에 개념적으로 나타내진다.

표에서 유효 윈도우는 확장되었으나 최대 윈도우는 슬라이딩하지 않은 것을 주목하라. 그러나 서버가 명령 2를 수신하고 응답시에, 윈도우(730s)는 도 7 및 아래와 같이 두 개 모두 슬라이딩할 것이다.

명령을 보내고 응답을 거절해서 자원을 고갈하려고 시도하는 다음의 악의의 클라이언트를 고려하자. 여기서 클라이언트는 서버에 명령 4 및 5를 보내고, 응답을 거절한다. 상태는 도 8 및 다음의 표로 나타내진다.

순차적인 식별자 6, 7, 8과 함께 명령이 보내어진 후에, 크레디트 강제로 인해 클라이언트는 도 9 및 아래 표에 나타내어진 것과 같이 크레디트가 고갈되어 모든 패킷이 거절된다.

최대 윈도우 강제의 예로 가서, 도 10-13 및 유사한 표들이 사용된다. 우리에게 N개의 패킷을 보내지 않고 N+1 이상의 패킷을 보내려고 하는 악의의 클라이언트를 고려하자. 도 10 내지 13의 예들은 최종 공격자 전의 상태에서 시작할 것인 데, 즉 도 10은 실질적으로 도 7이다.

클라이언트는 명령 4를 보내지 않고 명령 5, 6, 7, 8, 9, 10을 보내고, 서버는 응답한다. 이 상태는 도 11 및 다음 표에서 도시된다.

명령 윈도우에 여전히 5개의 실행 가능한 슬롯이 있으므로 클라이언트가 여전히 5개의 크레디트를 구비하고 있음을 주목하라. 그러나 클라이언트가 보내고 명령 11에 서버가 응답할 때, 도 12 및 아래의 표의 상태가 존재한다.

클라이언트는 12, 13, 14로 계속함을 주목하라. 클라이언트의 이용가능한 수의 크레디트는 각 명령에 대해 1 줄었는데, 최대 윈도우(MaxWindow)에 이용가능한 슬롯이 없기 때문이다. 명령 12, 13, 14에 대해서도 계속될 것이다.

도 13에 도시된 바와 같이, 서버가 클라이언트로부터 수용할 유일한 명령은 명령 4이다.

용이하게 알 수 있는 바와 같이, 순차 번호 윈도우의 속성은 다수의 원하는 시나리오에서 매우 유용하다. 이들 시나리오 중 일부는 서비스의 거부(denial-of- service)를 방지하고, 서비스 품질(quality-of-service)을 허용하고, 소정의 연결을 통해 실행되는 명령들을 참조하고 클라이언트 및 서버가 장시간 수행되는 명령 및 서버로부터 다중 응답을 가진 명령을 허용하나 클라이언트가 얼마나 많은 자원을 소모할 수 있는지를 제어해서 이의 균형을 잡도록 공통 언어를 제공하고, 보안 서명의 계속적인 사용을 허용하는 것을 포함한다.

서비스 거부를 방지하는 것에 관해서, 서버는 소정의 클라이언트 연결이 소모할 수 있는 자원의 양을, 서버가 클라이언트를 인증하고 클라이언트가 정당하게 행동할 때까지 제한할 수 있다. 예컨대, 명백한 공격이 탐지되면 서버가 클라이언트에 할당된 자원을 제어하도록 해서, 서버는 클라이언트에 이용가능한 자원을 최소치로 줄이고 신뢰가 되면 이들 자원을 다시 수여하는 "패닉 모드(panic mode)"에 들어갈 수 있다. 서버는 각 클라이언트에 일이 발생할 수 있으나 임의의 단일 클라이언트가 실질적으로 모든 자원을 압도하는 것을 방지하기에 충분한 작은 윈도우를 준다. 공격이 끝나거나 줄면, 서버는 믿을만한 클라이언트에 자원을 재수여한다.

서비스 품질을 허용하는 것에 관해서, 가변 윈도우 방식은 클라이언트의 식별 및/또는 그들의 행동에 기반해 클라이언트에 할당된 자원의 양을 서버가 조정하도록 한다. 예컨대, 서버는 개개의 문서에 액세스하는 단일 사용자보다 파일 서버에 연결하는 웹 서버에 더 많은 자원을 할당할 수 있다. 다른 예로서, 또 다른 서버가 파일 서버에 액세스하는 데이터베이스 서버이면, 상기 파일 서버는 크레디트의 수를 평균 사용자에 수여되는 것보다 더 많이 가중할 수 있다.

더구나, 서비스 품질을 제어시에, 자원의 클라이언트로의 할당은 클라이언트의 다양한 필요에 기반해 동적으로 변경될 수 있다. 이 서버가 완벽하게 공정한 방식으로 크레디트를 수여하게 하거나, 다른 정보를 고려하게 한다. 집행부(administrator)는 자원 우선 기반에서 장치를 구성할 수 있고, 사용자가 연결하고 연결해제하는 것에 따라 동적으로 변화시키는데 사용될 수 있다.

또한 순차 번호는 클라이언트 및 서버가 주어진 연결을 통해 실행된 명령들을 참조하도록 공통 언어를 제공한다. 이것은 지속적인 처리를 포함하는 다양한 특성을 세우는데 도움이 된다. 예컨대, 클라이언트 및 서버는 그들이 송신하고 수신한 명령을 식별하기 위한 공통 언어, 즉 순차 번호 메커니즘에 동의하였으므로, 연결해제가 발생하면, 서버 및 클라이언트가 어떤 명령은 수신하고 어떤 것은 수신하지 않은 지를 판정하기 위한 연결 재설정에 관한 간단한 방법이 있다. 그런 세트 방식 없이는, 명령 식별자가 클라이언트에 의해 선택되고 잠재적으로 재사용될 때는 추적하기는 더 어렵다.

(전체 패킷의 체크섬(checksum)이 여전히 계산될 필요가 있고, 발행 전에 수신된 전체 패킷에도 그러함에도 불구하고), 순차 번호는 또한 보안 서명의 계속적인 사용을 현재 모델의 극단적인 성능 문제없이 허용한다. 패킷 서명의 관점에서, 재연가능성은 불가능하다. 더 구체적으로, 서명을 하는 네트워크 프로토콜은 서명된 패킷의 재연가능성을 방지하기 위해 패킷에 인덱스 번호를 내장할 필요가 있고, 그렇지 않으면 공격자는 간단히 이를 다시 서명하지 않고 패킷을 재발행할 수 있어 패킷은 유효하게 남아 있다. 다른 방법은 타임스탬프 등을 포함하는데, 이들은 클 라이언트 및 서버 사이에 소정 형태의 동기화를 요구한다. 인덱스 번호가 사용되면, 클라이언트 및 서버 사이의 네트워크 트래픽은 흔히 직렬화되는데, 클라이언트는 패킷 2를 보내지 전에 서버가 패킷 1을 수신한 것을 확신해야만 하기 때문이다.

명령 식별자로 내장된 순차 번호 및 서버상에 지원되는 유효 윈도우로, 그들 내의 순차 번호를 가진 병렬 명령 송달이 자연스럽게 생긴다. 서버는 유효 윈도우를 강제해서, 각 명령이 오직 한 번만 발행되도록 할 수 있고, 이에 의해 프로토콜이 서명을 위해 사용된 키가 각 인증된 연결에 대해 고유하다면 재연가능성은 문제가 아니다. 명령 식별자가 문제가 생기면, 재연가능성도 문제가 될 수 있으므로 그래서 이를 방지하기 위해 순차 번호는 32 비트나 64비트의 자릿수가 바람직한데, 끊어진 연결의 재설정이 허용된다면 64비트가 더 바람직하다.

본 발명은 다양한 변형 및 다른 구성이 적합하지만, 도면에서 본 발명의 소정의 도시된 실시예가 도시되고 위에서 상세히 기술되었다. 그러나 개시된 특정 형태로 본 발명을 한정하려는 의도가 아니고, 반대로 본 발명의 사상 및 범위 내의 모든 변형, 다른 구성 및 등가물을 포함하려는 의도임이 이해될 수 있을 것이다.

클라이언트가 서버 자원 사용을 제어하기 위해 클라이언트-서버 통신에 대한 순차 번호를 사용하는 데이터 통신 프로토콜을 이용할 수 있다.

Claims (20)

1. 클라이언트와 서버를 구비한 네트워크 컴퓨팅 환경에서,

   상기 서버가, 적어도 1개의 순차 번호(sequence number)를 포함하는 유효 명령 윈도우(valid command window)를 설정하는 단계;

   상기 서버가, 서버 자원을 소비하며, 연관된 순차 번호를 포함하는 명령을 수신하는 단계;

   상기 서버가, 상기 연관된 순차 번호가 상기 유효 명령 윈도우의 범위 내인지를 판정하는 단계;

   상기 서버가, 상기 연관된 순차 번호가 이전에 다른 명령에 포함되어 있었던 적이 없는 지를 판정하는 단계; 및

   상기 서버가, 상기 연관된 순차 번호가 상기 유효 명령 윈도우의 범위 내이며 이전에 다른 명령에 포함되어 있었던 적이 없음을 판정했을 경우, 상기 명령을 허가하는 단계

   　를 포함하는 방법.
2. 제1항에 있어서,

   상기 서버가, 상기 연관된 순차 번호가 최대 순차 번호를 넘지 않은 것으로 판정한 경우에, 상기 명령을 허가하는 단계를 더 포함하는 방법.
3. 제1항에 있어서,

   상기 서버가, 상기 클라이언트에 크레디트(credit)를 수여하는 단계 및

   상기 서버가, 미사용 순차 번호를 포함하도록 상기 유효 명령 윈도우를 조정

   하는 단계

   를 더 포함하는 방법.
4. 제3항에 있어서,

   상기 서버가, 상기 수신된 명령에 응답해서, 상기 클라이언트에 추가 크레디트를 수여하는 단계; 및

   상기 서버가, 제2 미사용 순차 번호를 포함하도록 상기 유효 명령 윈도우를 조정하는 단계를 더 포함하는 방법.
5. 제3항에 있어서,

   상기 서버가 상기 명령을 허가하는 단계는, 상기 클라이언트에게 수여된 크레디트 하나를 소비하는 단계인 방법.
6. 제1항에 있어서,

   상기 서버가, 상기 클라이언트에 1개 또는 복수의 블로킹 동작 크레디트를 수여하는 단계; 및

   상기 서버가, 블로킹 동작 크레디트의 최대 번호를 초과하지 않는 블로킹 명령을 상기 클라이언트로부터 수신하는 것에 응답해서 블로킹 동작을 실행하는 단계

   를 더 포함하는 방법.
7. 제6항에 있어서,

   상기 서버가, 상기 블로킹 동작의 진행을 나타내는 데이터를 반환하는 단계; 및

   상기 서버가, 상기 블로킹 동작의 식별자(identifier)를 반환하는 단계

   를 더 포함하는 방법.
8. 제7항에 있어서,　

   상기 서버가, 상기 클라이언트에 추가 크레디트를 수여하는 단계; 및

   상기 서버가, 상기 블로킹 명령의 수신에 응답하여 상기 유효 명령 윈도우를

   조정하는 단계

   를 더 포함하는 방법.
9. 제3항에 있어서,

   상기 서버가, 상기 클라이언트로부터 수신한 추가 크레디트에 관한 요청을 처리하는 단계를 더 포함하는 방법.
10. 제3항에 있어서,

    상기 서버가, 상기 클라이언트에 이전에 수여된 적어도 1개의 크레디트를 취소하는 단계를 더 포함하는 방법.
11. 서버가, 적어도 1개의 순차 번호를 포함하는 유효 명령 윈도우를 설정하는 단계;

    　상기 서버가, 서버 자원을 소비하며, 연관된 순차 번호를 포함하는 명령을 수신하는 단계;

    상기 서버가, 상기 연관된 순차 번호가 상기 유효 명령 윈도우의 범위 내인지를 판정하는 단계;

    　상기 서버가, 상기 연관된 순차 번호가 다른 명령에 포함되어 있었던 적이 없는 지를 판정하는 단계;

    　상기 서버가, 상기 연관된 순차 번호가 상기 유효 명령 윈도우의 범위 내이며 다른 명령에 포함되어 있었던 적이 없음을 판정했을 경우 상기 명령을 허가하고, 그 외의 경우에는 상기 명령을 거부하는 단계

    를 포함하는 단계들을 실행시키기 위한 컴퓨터 실행 가능 명령어들을 구비하는 적어도 하나의 컴퓨터 판독가능 매체.
12. 제11항에 있어서,　

    상기 서버가, 상기 클라이언트에 크레디트를 수여하는 단계; 및

    상기 서버가, 미사용 순차 번호를 포함하도록 상기 유효 명령 윈도우를 조정하는 단계를 수행하기 위한 명령어들을 더 포함하는 컴퓨터 판독가능 매체.
13. 제12항에 있어서,　

    상기 서버가 상기 클라이언트에 크레디트를 수여하는 단계는, 상기 클라이언트에 이전에 수여된 크레디트를 취소하지 않음을 판정했을 경우에 실행되는 컴퓨터 판독가능 매체.
14. 제12항에 있어서,　

    클라이언트에 크레디트를 수여하는 단계는, 상기 유효 명령 윈도우 내의 상기 순차 번호가 최대 윈도우 크기를 넘지 않는 경우에 수행되는 컴퓨터 판독가능 매체.
15. 제12항에 있어서,

    상기 서버가, 상기 클라이언트에 이전에 수여된 크레디트 가운데 적어도 하나의 크레디트를 취소하는 단계를 수행하기 위한 명령어들을 포함하는 컴퓨터 판독가능 매체.
16. 제11항에 있어서,

    상기 서버가, 상기 클라이언트에 하나 또는 복수의 블로킹 동작 크레디트를 수여하는 단계; 및

    상기 서버가, 블로킹 동작 크레디트의 최대 수를 넘지 않는 블로킹 명령을 상기 클라이언트로부터 수신하는데 응답해서, 블로킹 오퍼레이션을 실행하는 단계를 수행하기 위한 명령어들을 더 포함하는 컴퓨터 판독가능 매체.
17. 클라이언트 및 서버를 구비한 네트워크 컴퓨팅 환경에서의 시스템으로서,

    상기 클라이언트에게 수여되는 크레디트의 수를 제어하는 것에 의해 서버 자원의 사용을 제한하는 서버 메커니즘을 포함하고, 상기 크레디트는 서버 자원을 소비하는 명령을 허가받을 권리를 상기 클라이언트에게 주며, 상기 메커니즘은,

    상기 클라이언트에게 수여된 각 크레디트에 1개씩 대응하는 고유 번호를 포함하는 유효 명령 윈도우;

    상기 명령에 포함되는 고유 번호가 상기 유효 명령 윈도우의 범위 내이고 다른 명령에 포함되어 있었던 적이 없으면, 상기 클라이언트가 상기 명령에 의한 서버 자원의 소비를 할 수 있는 강제 메커니즘; 및

    상기 클라이언트에게 수여되는 크레디트와 상기 유효 명령 윈도우의 범위 내의 상기 고유 번호를 제어하는 할당 메커니즘을 포함하는 시스템.
18. 제17항에 있어서,　

    서버 자원의 사용을 제한하는 상기 메커니즘은, 서버 메시지 블록 프로토콜 드라이버를 포함하는 시스템.
19. 제17항에 있어서,　

    서버 자원의 사용을 제한하는 상기 메커니즘은, 상기 클라이언트에 이전에 수여된 적어도 하나의 크레디트를 취소하는 수단을 포함하는 시스템.
20. 제17항에 있어서,　

    상기 할당 메커니즘은, 상기 강제 메커니즘이 상기 클라이언트로부터 수신한 명령이 서버 자원을 사용하도록 하는 것에 응답해서, 상기 클라이언트에 추가 크레디트를 수여하는 시스템.

Images