KR101130475B1 - 데이터 통신 프로토콜 - Google Patents

Abstract

서버들이 클라이언트-요청 프로토콜을 수용할 수 없는 경우 클라이언트에게 협상을 재시도할 것을 요구하지 않는 방식으로, 클라이언트와 서버가 협상하는 데이터 통신 프로토콜이 기술된다. 일 구현 예에서는, 요청되는 프로토콜이 SMB 2.0 또는 그 이상이다. 그러한 프로토콜은 고유의 확장성(built-in extensibility)을 위하여 첨부된 아마도 추가적인 컨텍스트 데이터를 갖춘 생성 명령과 복수의 관련된 명령 또는 복수의 관련되지 않은 명령을 포함하는 복합 명령에 관하여 기술한다. 멀티채널 명령은 별도의 데이터 채널 상으로 데이터 전달을 요구하고, 서명 능력 검증은 보안 접속이 확립되는지를 보증하기 위하여 사용될 수 있으며, 이러한 프로토콜은 요청에 응답하여 서버로부터 확장형 에러 데이터를 전달할 능력을 제공한다.

Description

데이터 통신 프로토콜{DATA COMMUNICATION PROTOCOL}

본 출원은, 2005년 5월 25일에 출원되어 본 명세서에 참조로 통합되어 있는 미국가출원 제 60/685,008호의 우선권을 주장한다. 본 출원은, 본 발명의 양수인에게 양수되어 본 명세서에 참조로 통합되어 있으며, 본 출원과 동시에 출원되어 동 계류중인 대리인 사건관리번호 5660/313764 호로서 "시퀀스 번호를 이용한 데이터 통신 조정(Data Communication Coordinaton with Sequence Numbers)"을 발명의 명칭으로 하는 미국 출원과 관련되어 있다.

SMB(Server Message Block) 프로토콜과 같이, 오늘날에도 여전히 사용되는 다수의 데이터 통신 프로토콜은 컴퓨팅 리소스가 지금과 매우 다른 시기, 예컨대 네트워크 대역폭이 일반적으로 제한되어 있고, 메모리가 매우 귀중한 시기에 개발된 것이다. 그 결과, 현재의 네트워크에서 사용되는 경우, 이러한 프로토콜들은 전체 성능을 제한할 수 있다. 예를 들면, 메모리가 제한되었던 때에 설계되었기 때문에 버퍼 사이즈가 작아서 다량의 데이터를 전달하려면 더 많은 교환(round-trip)을 요하게 된다.

나아가, 현재의 SMB 프로토콜은 시간이 지남에 따라 명백해지는 다른 한계점이 있다. 예를 들면, 현재의 SMB 프로토콜은 서비스 거부 공격(denial of service attacks)에 취약한데, 프로토콜 설계상 이러한 공격에 대항하기 어렵게 되어 있다. 마찬가지로, 패킷 보안을 보장하기 위한 방법도 까다롭다. 또한, 현재 양질의 서비스 유사 동작을 수행하기 위한 어떠한 메커니즘도 없는데, 예컨대 신뢰된 클라이언트(trusted client)는 비신뢰된 클라이언트와 동일한 서버 리소스를 입수한다.

오랜 시간동안 SMB 프로토콜의 다양한 개선 또는 다이얼렉트(dialects)이 개발되었지만, 각 변형은 다양한 부분들을 살짝 틀어서 소정의 추가적인 특징들을 추가하는 본질적으로 패치-기반 접근방식이다. 따라서, 확장이 수월하지 않다. 요약하면, 현재의 SMB 버전들은 여전히 자주 이용되고 가치있는 프로토콜이기는 하지만, 현재의 네트워크 리소스들과 함께 이용되는 경우 이상적이지 못하다.

요약해서 말하자면, 본 발명의 다양한 태양들은 클라이언트 및 서버가 파일 공유와 같은 통신을 위해서 사용하는 데이터 통신 프로토콜에 관한 것이다.

클라이언트는 클라이언트가 해석할 수 있는 프로토콜 다이얼렉트 셋트를 식별하는 협상 패킷(negotiation packet)을 서버로 전송한다. 그 패킷은 다른 요청을 할 필요가 없는 포맷이며, 제2 데이터 통신 프로토콜로 통신을 할 수 없는 서버는 제1 통신 프로토콜이 사용되어야 한다고 표시할 것이다. 서버가 제2 데이터 통신 프로토콜로 통신을 할 수 있는 경우, 그러한 취지의 응답을 할 것이다. 클라이언트는, 서버가 표시한 해당 프로토콜로 서버와의 통신을 핸들링하는 드라이버를 호출할 것이다. 일 예시적 구현에서, 제2 통신 프로토콜은 SMB 2.0 또는 그 이상의 버전이다.

프로토콜의 다른 태양 및 향상점은 첨부되는 추가적인 컨텍스트 데이터를 이용한 생성 명령(create command), 및 복수의 관련된 명령 또는 관련되지 않은 명령을 포함하는 복합 명령(compound command)을 포함할 수 있다는 것이다. 또 다른 태양 및 향상점은 별도의 데이터 채널 상으로의 데이터 전송 요청과 관련된 멀티-채널 명령, 보안 접속이 확립되는지를 보장하라는 서명 능력 검증 요청 및 요청에 응답하여 서버로부터 확장된 에러 데이터를 전송할 수 있는 능력을 포함한다.

서버는, 복합 명령을 수신하면 복합 명령이 관련되지 않은 명령을 포함하는지, 또는 관련된 명령을 포함하는 지를 판정한다. 복합 요청이 관련되지 않은 명령을 포함하는 경우, 각 요청은 별도의 요청으로 핸들링되고, 복합 요청이 관련된 명령을 포함하는 경우, 각 요청은 순차적으로 핸들링된다. 관련된 명령이 생성/오픈 명령을 포함하는 경우, 서버에서는 후속하는 각 관련된 명령을 위해 생성/오픈 명령의 파일 핸들이 사용되는데, 예컨대 클라이언트로부터 다시 핸들링을 위해 대기할 필요가 없다.

서버들이 클라이언트가 요청하는 프로토콜을 수용할 수 없는 경우, 서버가 클라이언트에게 협상을 재시도할 것을 요구하지 않는 방식의 데이터 통신 프로토콜이 개시되었다. 이로써 서버는 재협상을 위한 대기 시간을 요하지 않아 복잡한 네트워크 환경에서 특히 유리하며, 이외에도 본 발명을 통해서 복합 명령, 데이터 채널, 보안 접속의 검증 등이 가능해진다.

다른 장점들은 도면들과 관련하여 후술하는 상세한 설명으로부터 명백할 것이다.

본 발명은 첨부되는 도면들을 예시로 도시한 것이며 이에 제한되지 않는다. 도면들에서 동일한 참조 번호는 동일한 요소를 표시한다.
도 1은 본 발명의 다양한 태양들이 통합될 수 있는 범용 컴퓨팅 환경의 일예시도.
도 2는 본 발명의 다양한 태양들에 따라 클라이언트가 서버와 통신하는 예시적인 네트워크 환경을 나타내는 블록도.
도 3은 본 발명의 다양한 태양들에 따라 클라이언트와 서버 간에 예시적인 협상 및 세션 준비를 나타내는 타이밍도.
도 4는 본 발명의 다양한 태양들에 따라 컨텍스트 생성을 갖춘 생성 명령을 포함하는 다양한 명령들을 나타내는 타이밍도.
도 5는 본 발명의 다양한 태양들에 따라 클라이언트와 서버 간에 복합 요청들 및 가능한 응답들을 나타내는 타이밍도.
도 6은 본 발명의 다양한 태양들에 따라 복수의 채널을 통하여 클라이언트-서버 통신을 나타내는 도면.
도 7은 본 발명의 다양한 태양들에 따라 보안 접속의 검증을 나타내는 도면.
도 8은 본 발명의 다양한 태양들에 따라 심볼 링크에 기초한 일예를 사용하여 확장된 에러 리턴 정보를 나타내는 도면.

예시적인 동작 환경

도 1은 본 발명이 구현될 수 있는 적당한 컴퓨팅 시스템 환경(100)의 예시도이다. 컴퓨팅 시스템 환경(100)은 단지 적당한 컴퓨터 환경의 일 예시일 뿐이며, 사용의 범위나 본 발명의 기능에 어떤 제한을 암시하려는 의도가 아니다. 또한, 컴퓨팅 환경(100)은 예시적 운영 환경(100)에 도시된 임의의 컴포넌트 하나 또는 그 조합과 관련하여 어떤 의존성이나 요구사항을 갖는 것으로 해석되어서는 안된다.

본 발명은 다른 일반적인 목적 또는 특별한 목적의 수많은 컴퓨팅 시스템 환경이나 구성에서 작동 가능하다. 본 발명이 사용되기에 적당할 수 있는 잘 알려진 컴퓨팅 시스템, 환경 및/또는 구성의 예로서 개인용 컴퓨터, 서버 컴퓨터, 핸드헬드(hand-held) 또는 랩탑 장치, 태블릿 장치, 멀티프로스세 시스템, 마이크로프로세서-기반 시스템, 셋탑 박스(set top boxes), 프로그램 가능한 소비자 전자기기(programmable consumer electronics), 네트워크 PC, 미니컴퓨터, 메인프레임 컴퓨터(mainframe computers), 임의의 상기 시스템 또는 장치를 포함하는 분산 컴퓨팅 환경, 프린트 서버나 프린터 그 자체와 같은 네트워크 설비 장치들의 다이얼렉트 중 하나 및 NAS 저장 장치 등을 들 수 있으며, 다만 이에 한정되지 않는다.

본 발명은 프로그램 모듈과 같은 컴퓨터-실행 가능한 명령어들의 일반적인 컨텍스트로 서술되어 컴퓨터에서 실행될 수 있다. 일반적으로, 프로그램 모듈은 특정 작업을 수행하거나 특정의 추상 데이터 유형(abstract data types)을 구현하는 루틴(routine), 프로그램, 객체, 컴포넌트, 데이터 구조(data structure) 등을 포함한다. 본 발명은 또한, 통신망을 통해 링크된 원격 처리 장치에 의해 작업이 수행되는 분산 컴퓨팅 환경에서 실시될 수 있다. 분산 컴퓨팅 환경에서 프로그램 모듈은, 메모리 저장 장치를 포함하는 로컬 및/또는 원격 컴퓨터 저장 매체상에 위치할 수 있다.

도 1을 참조하면, 본 발명을 구현하기 위한 예시적인 시스템은, 컴퓨터(110) 형태의 범용 컴퓨팅 장치를 포함한다. 컴퓨터(110)의 컴포넌트들은 처리 유닛(120), 시스템 메모리(130) 및 시스템 메모리를 비롯하여 다양한 시스템 컴포넌트들을 처리 유닛에 연결시키는 시스템 버스(121)를 포함하며, 다만 이에 한정되지는 않는다. 시스템 버스(121)는 메모리 버스 또는 메모리 제어기, 주변 장치 버스 및 임의의 다양한 버스 아키텍처를 사용하는 로컬 버스를 포함하는 다수 유형의 버스 구조물 중 임의의 것이 될 수 있다. 그러한 구조의 예로서, Industry Standard Architecture(ISA) 버스, Micro Channel Architecture(MCA) 버스, Enhanced ISA(EISA) 버스, Video Electronics Standards Association(VESA) 로컬 버스 및 Mezzanine 버스로 또한 알려진 Peripheral Component Interconnect(PCI) 버스를 들 수 있으며, 다만 이에 한정되지는 않는다.

컴퓨터(110)는 일반적으로 다양한 컴퓨터 판독 가능 매체를 포함한다. 컴퓨터 판독 가능 매체란 컴퓨터(110)로 액세스할 수 있는 임의의 가용 매체가 될 수 있으며, 휘발성 및 비휘발성 매체, 착탈식 및 고정식 매체를 모두 포함한다. 컴퓨터 판독 가능 매체의 예로서, 컴퓨터 저장 매체 및 통신 매체를 들 수 있으며 다만, 이에 한정되지 않는다. 컴퓨터 저장 매체는 컴퓨터 판독가능 명령어, 데이터 구조 또는 기타 데이터와 같은 임의의 정보를 저장하기위한 방법 또는 기술로 구현되는 휘발성 및 비휘발성, 착탈식 및 고정식 매체 모두를 포함한다. 컴퓨터 저장 매체는 RAM, ROM, EEPROM, 플래시 메모리 또는 기타 메모리 기술, CD-ROM, DVD 또는 기타 광디스크 저장장치, 자기 카세트, 자기 테이프, 자기 디스크 저장장치, 또는 기타 자기 저장장치 또는 원하는 정보를 저장하는데 사용될 수 있고, 또 컴퓨터(110)로 액세스할 수 있는 기타 임의의 매체를 포함하며, 다만 이에 한정되지는 않는다. 통신 매체는 일반적으로 컴퓨터 판독 가능 명령어, 데이터 구조, 프로그램 모듈 또는 반송파 주파수(carrier WAV)나 기타 전송 메커니즘과 같은 변조 데이터 신호 내에 있는 다른 데이터로 구체화되며, 임의의 정보 전달 매체를 포함한다. 용어“변조 데이터 신호”는 그 특성 집합을 하나 이상 포함하는 신호 또는 신호 내에 정보를 인코드(encode)하는 방식으로 변경된 신호를 의미한다. 통신 매체의 예로서, 유선 네트워크 또는 직접-회선 연결(direct-wired connection)과 같은 유선 매체 및 음향, FR, 적외선 및 기타 무선 매체와 같은 무선 매체를 들 수 있으며, 다만 이에 한정되지는 않는다. 또한 상기에 대한 임의의 조합에 대해서도 컴퓨터 판독 가능 매체의 범주에 포함되어야 한다.

시스템 메모리(130)는 ROM(131) 및 RAM(132)과 같은 휘발성 및/또는 비휘발성 메모리 형태의 컴퓨터 저장 매체를 포함한다. 시동하는 동안과 같이 컴퓨터(110) 내에 요소들 간 정보 전달을 돕는 기본 루틴을 포함하는 기본 입/출력 시스템(BIOS; 133)은 일반적으로 ROM(131)에 저장된다. RAM(132)은 일반적으로 즉시 액세스 가능하고 및/또는 처리 유닛(120)에 의해 현재 동작 중인 데이터 및/또는 프로그램 모듈을 포함한다. 예로서, 도 1에 운영 체제(134), 애플리케이션 프로그램(135), 기타 프로그램 모듈(136) 및 프로그램 데이터(137)가 도시되었으며 다만, 이에 한정되지는 않는다.

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

도 1에 도시되고, 앞에서 설명한 드라이브 및 그와 연관된 컴퓨터 저장 매체는 컴퓨터 판독 가능 명령어, 데이터 구조, 프로그램 모듈 및 기타 컴퓨터(110)에 대한 데이터의 저장장치를 제공한다. 예를 들면 도 1에서, 하드 디스크 드라이브(141)는 운영 체제(144), 애플리케이션 프로그램(145), 기타 프로그램 모듈(146) 및 프로그램 데이터(147)를 저장하는 것으로 도시되어 있다. 이러한 컴포넌트들은 운영 체제(134), 애플리케이션 프로그램(135), 기타 프로그램 모듈(136) 및 프로그램 데이터(137)와 같거나, 또는 다를 수 있다는 것에 주의한다. 운영 체제(144), 애플리케이션 프로그램(145), 기타 프로그램 모듈(146) 및 프로그램 데이터(147)는 최소한 그들이 별개의 사본임을 설명하기 위해 여기에서는 다른 번호로 표시되었다. 사용자는 태블릿이나 전자 디지털기기(electronic digitizer; 164), 마이크로폰(163), 키보드(162) 및 일반적으로 마우스, 트랙볼 또는 터치패드로 불리는 포인팅 장치(pointing device; 161)와 같은 입력 장치를 통해서 컴퓨터(110)로 명령어 및 정보를 입력할 수 있다. 다른 입력 장치들은 도 1에 도시되지는 않았지만, 조이스틱, 게임 패드, 위성 접시 또는 스캐너 등을 포함할 수 있다. 이들 및 기타 입력 장치들은 종종 시스템 버스에 연결된 사용자 입력 인터페이스(160)를 통해 처리 유닛(120)에 접속되지만, 다른 인터페이스 및 병렬 포트, 게임 포트 또는 USB(universal serial bus)와 같은 버스 구조에 의해 접속될 수도 있다. 모니터(191) 또는 기타 유형의 디스플레이 장치도 비디오 인터페이스(190)와 같은 인터페이스를 통해 시스템 버스(121)에 접속된다. 모니터(191)는 또한 터치 스크린 패널 등과 함께 통합될 수 있다. 모니터 및/또는 터치 스크린 패널은, 태블릿 유형의 개인용 컴퓨터 속과 같이 컴퓨팅 장치(110)가 통합되어 있는 몸체(housing) 속에 무리적으로 연결될 수 있음을 주의한다. 또한, 컴퓨팅 장치(110)와 같은 컴퓨터는 출력 주변 장치 인터페이스(190) 등을 통해 접속될 수 있는 스피커(195) 및 프린터(196)와 같은 다른 주변 출력 장치도 포함할 수 있다.

컴퓨터(110)는 원격 컴퓨터(180)와 같은 하나 이상의 원격 컴퓨터에 논리적으로 접속되어 있는 네트워크 환경에서 운영될 수 있다. 원격 컴퓨터(180)는 개인용 컴퓨터, 핸드 헬드 장치, 서버, 라우터, 네트워크 PC, 피어 장치(peer device) 또는 기타 공통 네트워크 노드(common network node)일 수 있으며, 비록 도 1에는 메모리 저장 장치(181)만 도시되어 있지만, 일반적으로 컴퓨터(110)와 관련하여 상술한 요소들을 전부 또는 다수 포함한다. 도 1에 도시된 논리적 접속은 LAN(171) 및 광역 네트워크(WAN: wide area netwok; 173)를 포함하지만, 다른 네트워크들 또한 포함할 수 있다. 그러한 네트워크 환경은 사무실, 기업 영역의 컴퓨터 네트워크, 인트라넷 및 인터넷에서 일반적인 것이다.

LAN 네트워크 환경에서 사용될 경우, 컴퓨터(110)는 네트워크 인터페이스 또는 어댑터(170)를 통해서 LAN(171)에 접속된다. WAN 네트워크 환경에서 사용될 경우, 컴퓨터(110)는 일반적으로 모뎀(172) 또는 인터넷과 같은 WAN(173) 상에서 통신을 확립하기 위한 다른 수단들을 포함한다. 모뎀(172)은 내장형 또는 외장형일 수 있으며, 사용자 입력 인터페이스(160) 또는 기타 적절한 메커니즘을 통해서 시스템 버스(121)에 접속될 수 있다. 네트워크 환경에서, 컴퓨터(110) 또는 그 일부와 관련하여 도시된 프로그램 모듈은 원격 메모리 저장장치에 저장될 수 있다. 예로서, 도 1은 메모리 장치(181)에 상주하는 원격 애플리케이션 프로그램(185)을 도시하는데, 다만 이에 한정되지는 않는다. 도시된 네트워크 접속은 예시적인 것이며, 컴퓨터들 사이에 통신 링크를 확립하기 위한 다른 수단이 사용될 수 있는 것으로 이해될 것이다.

데이터 통신 프로토콜

본 명세서에서 설명되는 기술의 다양한 태양들은, SMB 프로토콜의 최신 버전(2.x 또는 그 이상)과 같은 데이터 통신 프로토콜에 관한 것이다. 본 명세서에서 일반적으로 설명되는 일 예시 구현에서, SMB 프로토콜은 파일 데이터 전송을 위해 사용된다. 그러나, 쉽게 이해될 수 있다시피, 본 발명은 파일 데이터, 본 명세서에서 설명되는 임의의 특정 구현이나 예시에 제한되지 않는다. 대신, 본 발명을 구현하는 다양한 방법들, 프린터, 네임드 데이터 파이프(named data pipe) 및 일반 장치 등과 통신하는데 사용되는 것을 포함하여 다양하게 실행될 수 있다. 따라서, 본 발명은 본 명세서에서 사용되는 임의의 특정 파일-기반 예시에 제한되지 않으며, 오히려 일반적인 컴퓨팅에서 장점 및 효과를 제공하는 다양한 방식으로 사용될 수 있다.

본 명세서에서 설명되는 기술의 다른 다양한 태양들은 파일-서버 상호작용이 구축될 수 있는 새로운 버전의 SMB에 관한 것이다. 이해되다시피, 기존의 기능을 지원하는(업 레벨) 좀 더 경량의 프로토콜(lightweight protocol)이 제공되며, 이 프로토콜은 확장성(scalable)이 있어서 새로운 특징들로 업데이트가 더 수월하다.

이제 도 2를 살펴보면, 하나 이상의 통신 채널을 통하여 클라이언트(202)와 서버(204)가 통신하는 예시적인 네트워킹 환경을 나타내는 블록도가 도시되어 있다. 클라이언트 머신(202)과 서버(204)의 기능 및 컴포넌트가 도 1의 메인 컴퓨터 시스템(110)과 원격 컴퓨터 시스템(180)과 같은 별도의 컴퓨터 2대 안에 위치하는 것으로 도시되어 있지만, 이들 두 컴퓨터의 컴포넌트 또는 이로써 수행되는 기능은 하나의 머신 상에서 제공되거나, 다수의 컴퓨터에 걸쳐 분산될 수 있다.

애플리케이션 프로그램(206)의 네트워크 파일 시스템 명령이 클라이언트 재설정 컴포넌트(client redirector component; 208)에 의해 핸들링되는데, 클라이언트 재설정 컴포넌트(208)는 상대방 공통 네트워크 모듈(SRVNET; 210)과 통신하여 파일 시스템(212) 상에서 명령을 수행한다. 이러한 명령이 처리되기 전에, 클라이언트와 서버가 동의하는 통신 프로토콜, 일반적으로 양자 모두 해석할 수 있는 최신 버전/다이얼렉트가 협상된다.

일반적으로, 도 3에 나타난 바와 같이, 클라이언트(202)는 접속을 확립한 후, 서버(204)와 협상하여 궁극적으로 세션을 준비한다. 클라이언트가 서버에게 SMB 2.x 클라이언트라고 직접 표시할 수 있지만, (본 명세서에서 숫자 2.x는 기존의 SMB 1.x 버전과 비교할 때, 임의의 새로운 버전을 나타냄) 클라이언트는 역-호환(backwards-compatible) 협상 패킷을 통해 협상할 수도 있다. 이러한 방식으로, 클라이언트는 단지 SMB 1.x만 가능한 서버와 통신할 수 있으나, 상위 레벨에서의 협상 시도가 실패했을 경우 별도의 접속을 시작하지 않고도 통신할 수 있다. 동시에, 각 프로토콜을 구현하기 위한 코드는 각각의 독립적인 드라이버로 패키징될 수 있다.

일 예시 구현에서, 클라이언트 SMB 엔진 컴포넌트(220)는 서버(예컨대, 서버; 204)로 패킷을 제공하는데, 이는 클라이언트(202)가 적어도 SMB 1.0 세션에서 협상 중임을 나타낸다. SMB 1 다이얼렉트와 새로운 SMB 2 프로토콜 개정판을 모두 말하는 클라이언트(202)에 있어서, 클라이언트는 종래의 SMB 1 형상 패킷을 전송할 수 있지만, 이 패킷은 사실상 가능하다면 SMB 2.x를 요청하고 있음을 나타내는 표시를 더 포함한다. SMB 2-가능 서버는 이 요청을 감지하여 SMB 2 협상 응답으로 응답할 것이다. 좀 더 구체적으로, 클라이언트(202)가 SMB 2.x 가능함을 표시하기 위해서, SMB 1.0 협상 패킷은 다이얼렉트 스트링(dialect strings)의 셋트를 포함하는데, 이들 중 하나는 클라이언트가 SMB 2.x 통신도 가능함을 표시한다.

따라서, 클라이언트(202)는 지원하는 소수점 이하 개정판 번호를 포함하는 개시 협상(initial negotiate)을 전송한다. 현재 개정판이 0, 즉, SMB 2.0이고, 향후 클라이언트는 다이얼렉트 개정판의 임의의 서브셋트를 지원한다고 주장할 수 있다.

서버(204)가 패킷을 수신한 경우, 자기의 능력에 기초하여 응답할 것이다. 서버(204)는 임의의 1.x 다이얼렉트 정보와 함께 SMB 1.0 협상 응답으로 응답하거나 SMB 2.x 통신이 가능한 경우, SMB 2.0 협상 응답으로 응답할 것이다. 다이얼렉트 스트링 중 하나와 매칭되는 특정 SMB 다이얼렉트 개정판, 보통은 클라이언트(202)가 제공했던 다이얼렉트 개정판들 중에서 서버(204)가 핸들링할 수 있는 가장 큰 숫자의 버전이 리턴될 수도 있다.

이를 위하여, 일단 서버(204)가 클라이언트(202)가 어떤 다이얼렉트 개정판들을 말하는지를 알게 되면, 이들을 서버(204)가 해석할 수 있는 개정판들과 비교하여 바람직한 공통의 다이얼렉트 개정판(보통은 가장 큰 숫자)을 리턴한다. 예를 들면, 서버가 다이얼렉트(1-8)를 지원하지만, 클라이언트는 단지 1, 2 및 4만을 지원하는 경우, 서버는 4를 리턴할 것이다. 이로써 클라이언트(202)는 서버(204)로 전송할 수 있을 명령의 종류에 대해 명확히 이해하게 된다. 어느 다이얼렉트를 사용할지 선택하기 위해서, SRVNET 모듈(210)은 버전/다이얼렉트의 높은 쪽에서 낮은 쪽의 순서로 자기의 SMB 공급기(222₁-222_m) 각각에게 패킷을 전달하면서 본질적으로 협상을 시작하며, 이것은 하나의 SMB 공급기가 패킷 컨텐츠에 기초하여 이 통신 세션을 핸들링한다고 동의할 때까지 계속된다. 결국 이 접속 상의 통신은 그 공급기로 라우팅되는데, 이 예시에서 SMB 2.0 공급기 222_m이다.

클라이언트 말단에서, SMB 엔진 컴포넌트(220)는 응답을 수신하고, 응답 내 버전/다이얼렉트 정보에 기초하여 서버와 통신할 때 어떤 클라이언트 SMB 컴포넌트(224₁-224_n)를 사용할지 알게 된다. 이러한 방식으로, 클라이언트(202)와 서버(204)는 둘 다 주어진 세션에서 어떤 SMB 다이얼렉트를 사용할 지에 동의하게 된다. 클라이언트는 각각이 상이한 버전/다이얼렉트인 복수의 SMB 컴포넌트(224₁-224_n)를 동시에 실행시킬 수 있는데, 예컨대 클라이언트는 SMB 1.x를 통해 하나의 서버와 통신하면서 동시에 다른 서버와 SMB 2.x로 통신할 수 있음을 주의한다.

서버(204)는 서버(204)가 보안 서명을 필요로 하는지 여부를 표시하는 보안 모드를 포함하는 다른 정보를 클라이언트(202)에게 리턴할 수도 있다. 정확히는 보안 서명이 가용인지인데 처음 몇 개의 패킷(예컨대, 능력 협상)이 평문이면, 공격자는 공격자가 취약점을 알고 있는 하위 레벨로 클라이언트를 강제할 수 있음을 주의한다.

보안 접속은 서명된 (서명이 동작되는지 아닌지에 관계없이) 다른 능력 검증 교환을 제공함으로써 동작한다. 도 7은 세션 준비 후 요청/응답을 도시한 것이다. IP 주소와 같은 다른 정보가 패킷 내에 포함되어 서버는 다른 엔티티가 아닌 자신의 응답을 검증할 수 있다. IPSEC 또는 임의의 다른 형태의 네트워크 보안이 활성화된 경우, 서명은 턴오프될 수 있다.

서버(204)는 서버에 대한 능력 비트들, 예컨대 서버가 DFS(Distributed File System)를 알고 있는지, LWIO(Lightweight IO) 가능한지를 리턴할 수 있다. 클라이언트(202)는 해석할 수 없는 임의의 능력 비트들은 버리는데, 이는 서버(204)가 클라이언트의 해당 버전보다 더 새로운 버전을 갖는 경우에 발생할 수 있다. 협상 교환에서 리턴될 수 있는 다른 정보는 서버의 고유 ID, 서버가 수용할 최대 판독/기록 사이즈, 고속 기록 처리를 위한 데이터 오프셋 힌트, 현재 서버의 시스템 시간 및 확장 보안 경우에 보안의 시드로 사용되는 보안 정보를 포함한다.

세션 준비는 새로운 세션을 위한 인증 프로세스를 핸들링하는데, 이는 복수의 교환 이벤트가 될 수 있다. 클라이언트(202)는 로컬 보안 시스템에 네트워크를 통해 전송할 보안 블럽(security blob)을 쿼리하고, 능력, 최대 사이즈 필드 및 후술할 VcNumber를 기입하여 제1 세션 준비를 전송한다. 서버(204)는 이 블럽을 수신하여 보안 시스템에 넘겨 준다. 서버(204)가 좀 더 정보가 필요하다고 판정한 경우, 자신의 보안 블럽을 에러 코드(STATUS_MORE_PROCESSING_REQUIRED)와 함께 리턴할 것이다. 클라이언트(202)는 이 블럽을 로컬 보안 시스템으로 다시 전달하고, 프로세스는 실패가 발생하거나 인증이 성공적일 때까지 반복될 것이다.

VcNumber는 서버(204)에게 이 동일한 클라이언트(202)로부터 확립된 다른 접속이 있는지를 표시한다. 이것이 0이면, 서버(204)는 이 클라이언트로부터 형성된 다른 접속이 없다고 간주하고, 서버가 찾은 임의의 그러한 접속을 (부적절한 것으로 간주하여) 끊을 것이다. VcNumber가 1 이상이면, 서버(204)는 임의의 기존 접속들을 끊지 않을 것이다.

채널은 서버(204)에게 이 클라이언트(202)가 기존의 세션과 더불어 다른 접속을 확립하려고 시도 중인지를 표시한다. 세션은 이 세션 준비를 전송한 사용자/컴퓨터 쌍으로 식별될 수 있다. 채널은 동일한 TreeId/UserID/ProcessID/FileId 정보를 공유한다. 채널 인증을 위하여, 인증 블럽은 제1 채널을 통하여 암호화된 도전-응답(challenge-response)일 수 있으며, 제2 채널을 통해 다시 전송되어 클라이언트(202) 및 서버(204)가 서로 상호 인증하게 할 수 있다. 응답이 성공적이면, 서버(204)는 또한 클라이언트(202)에게 손님으로서, 또는 널 사용자로서 어느쪽이든 적용가능한 것으로 인증되었음을 통지할 것이다.

일단 세션이 준비되면, 클라이언트(202)는 생성, 판독, 기록 및 클로즈를 포함하는 후술할 다양한 명령을 사용하여 데이터 전송을 수행하고, 파일 로킹(file locking) 및 디렉토리 관련 동작을 수행할 수 있다. 상술한 "시퀀스 번호를 이용한 데이터 통신 조정" 특허출원에서, 이들 명령을 사용할 때, 서버는 클라이언트에 의한 서버 리소스의 사용을 제어할 수 있다. 또한, 프로토콜은 어떤 정보가 어떻게 전달되는가와 관련하여 다수의 효율 개선점을 제공한다.

도 4에 일반적으로 도시된 바와 같이, 생성 명령은 컨텍스트 정보의 첨부가 허가되도록 확장되었다; 일반적으로, 컨텍스트 정보는 생성 명령에 태깅되는 임의의 추가 생성 파라미터를 포함한다. 예를 들면, 거래 파일 시스템-관련 생성 명령에 대하여 거래 식별자가 첨부될 수 있다. 서버가 추가 컨텍스트 정보를 해석할 수 있는 한, 서버는 확장 정보를 통보받을 수 있고, (서버는 해석할 수 없는 추가 정보는 무시할 것임을 주의), 컨텍스트 관련 정보를 리턴할 수 있다. 쉽게 이해될 수 있다시피, 이는 프로토콜을 변경하지 않고도 추가적인 기능을 제공하는 것으로 본질적으로 고유의 확장성(built-in extensibility)을 제공하는 것이다.

명령 ID 및 다이얼렉트 개정판 번호는 이하에서 개시되는 새로운 SMB 헤더 내에서 제공된다. 헤더는 UCHAR와 대조되는 명령 필드로서 USHORT를 갖는다; 이 USHORT의 첫째 바이트를 다이얼렉트를 표시하는데 사용함으로써 명령 테이블은 상당 부분을 향후 확장을 위해 비워두면서 기존의 명령에 대해서도 잘 정의된다. 일반적으로, 클라이언트는 각 다이얼렉트에 대해서 주어진 명령을 발행시키는 함수의 포인터들을 포함하는 테이블을 보유할 수 있다. 단일 다이얼렉트를 지원하는 클라이언트에 있어서 테이블은 아래와 같이 개시될 것이다:

명령	다이얼렉트 #1
생성	SmbCreate1
판독	SmbRead1
기록	SmbWrite1
클로즈	SmbClose1

기능의 캐싱을 위하여, 좀 더 많은 정보가 클로즈 상에서 파일로부터 검색될 수 있다. 따라서, 이러한 새 기능을 지원하기 위해서, 새로운 클로즈 명령이 제공된다. 이하 클라이언트는 2개의 다이얼렉트를 지원하며 그 테이블은 아래와 같다.

명령	다이얼렉트 #2	다이얼렉트 #1
생성	SmbCreate1	SmbCreate1
판독	SmbRead1	SmbRead1
기록	SmbWrite1	SmbWrite1
클로즈	SmbClose2	SmbClose1

변경된 클로즈 명령을 제외하고는 열거된 기능 대부분이 동일하다는 것을 주의한다. 클라이언트는 이제 다이얼렉트 2 서버들에 말을 걸고 새로운 기능을 사용할 수도 있는 반면, 다이얼렉트 1 서버들에 대해서는 여전히 구 기능을 사용한다. 다이얼렉트 1 서버와 통신하는데 있어서 변경된 것은 없다.

기술이 진보함에 따라 상대적으로 훨씬 더 대용량의 판독과 기록을 수행할 수 있는 새로운 네트워크 하드웨어가 이용가능해진다. 이러한 출시에 대해 다이얼렉트 #3이 구비되며 테이블은 다음과 같이 확장된다.

명령	다이얼렉트 #3	다이얼렉트 #2	다이얼렉트 #1
생성	SmbCreate1	SmbCreate1	SmbCreate1
판독	SmbRead3	SmbRead1	SmbRead1
기록	SmbWrite3	SmbWrite1	SmbWrite1
클로즈	SmbClose2	SmbClose2	SmbClose1

이러한 테이블을 갖춘 클라이언트는 3개의 다이얼렉트를 말할 수 있으며, 각 다이얼렉트에서 이용가능한 기능의 장점을 취할 것이다. 이러한 방법을 사용하는 소정의 장점으로 명령이 (다이얼렉트|명령)으로 이루어지기 때문에 각 SMB 명령이 자기를 제출한 다이얼렉트로 다시 매핑될 수 있다는 점을 들 수 있다. 이는 명령이 제출되었을 때, 어느 서버가 지원하는지를 판단하는데 도움을 준다. 주어진 명령에 대한 기능이 새로운 다이얼렉트에서 변경되지 않은 경우, 코드는 변경되지 않는다. 기능이 변경된 경우 하위 레벨 인터페이스 코드는 변경되지 않지만, 그 새로운 기능을 지원하기 위해서 새로운 코드가 추가된다.

서버 측에서, 서버 디스패치 테이블은 (다이얼렉트)와 (명령) 간에 더블 스위치가 된다. 이것은 코드 내에서 새로운 기능을 논리적으로 분리할 수 있게 함으로써 해석과 변경을 수월하게 해 준다.

효율성을 제공하는 프로토콜의 한 태양을 살펴보면, 복수의 명령이 단일 패킷 (또는 명령보다 적은 개수의 패킷)으로 복합될 수 있다. 따라서 클라이언트(202)와 서버(204) 간에 교환 회수를 줄인 방식으로 복잡한 작업이 수행될 수 있다. 예를 들자면, 복합 요청 패킷은 파일을 생성/오픈 하라는 명령, 파일에 기록하라는 명령 및 파일로부터 판독하라는 명령을 포함할 수 있다. 따라서 복합은 관련된 동작들(예컨대, 동일한 파일 핸들)에 대한 작업을 수행하며 관련되지 않은 동작들을 결합하기도 한다.

복합 관련 요청들의 예시가 도 5에 일반적으로 나타나 있는데, (예컨대 도 4와 대조적으로) 단일 요청이 적절할 파라미터들을 제공함으로써 판독 및 기록을 핸들링할 수 있다. 도 5에 도시된 바와 같이, 단일 요청은, 예컨대 종료 시점에 따라 복합 응답 및/또는 개별 응답들을 수신할 수 있다. 생성/오픈, 판독, 기록 및 클로즈와 같은 좀 더 복잡한 요청들이 단일 요청으로 될 수 있다. 이는 패킷에 관련 동작들을 갖는 것으로 마킹함으로써 이루어진다; 서버는 생성/오픈에 이어 수신하는 파일 핸들이 복합 요청 내 다른 명령들에게 적용됨을 알게 될 것이다. 그러나, 관련 복합 요청들은 패키징되는 순서로 핸들링되는바, 전송 전에 순서가 올바른지 검증하는 것은 클라이언트의 몫임을 주의한다.

SMB 2에서의 복합은 기존의 SMB 1에서의 복잡한 규칙보다 좀 더 간단하다. 이를 위해, SMB2_HEADER는 (상세한 내용은 후술) 현재 명령의 헤더로부터 다음 명령의 헤더까지의 오프셋을 식별하는데 사용되는 "NextOffset"을 포함한다. 각 명령은 별도의 MessageId를 포함하는 자신의 SMB2_HEADER를 갖는다. 도 5에 도시된 바와 같이, 서버 응답 또는 응답들은 단일의 복합 응답 또는 별도의 응답들로 올 수 있다. 실패의 경우, 응답은 임의의 다른 실패한 명령의 경우와 동일할 것이다.

관련되지 않은 메시지들에 대해서, 명령은 항상 이들이 별도로 수신된 것처럼 처리될 것이다. 이는 재설정기나 중개 컴포넌트가 관련되지 않은 패킷들을 자동으로 복합하도록 해 준다. 지연은 복합할 패킷들을 입수하는데 사용될 수 있는데, 특히 지연 시간이 교환 시간보다 상대적으로 작은 경우 그러하다. 서버가 수신된 패킷들을 별도로 취급하므로, 그렇지 않다면 필요로 할 관련되지 않은 복합 요청들을 풀기 위한 수정을 할 필요가 없다. 그러나 복합을 수행한 엔티티는 임의의 복합 응답들을 분리해야 할 수 있는데, 왜냐하면 그렇지 않다면 서버가 별도의 응답들을 결합할 수 있기 때문이다.

관련 모드는 클라이언트로 하여금, 실행될 일련의 명령들을 시퀀스로 전송하도록 해 주는데, 이 때 하나의 명령의 결과는 잠재적으로 다음 명령에서 사용된다. 이러한 명령들은 동일한 Session/Process/Tree/File ID를 공유하며, 순차적으로 실행될 것인데, 제1 에러 발생시 처리를 중단할 것이다. 실패 이후 진행할 다른 명령들이 있는 경우, 동작들은 즉시 STATUS_NOT_PROCESSED와 함께 진행을 멈춘다. 이것이 어떻게 사용될 수 있는지에 대한 일례로, 세션 준비와 트리 접속을 짝지우는 것을 들 수 있다. 세션 확립이 실패한 경우, 트리 접속은 결코 시도되지 않으며, STATUS_NOT_PROCESSED와 함께 진행이 멈출 것이다. 세션 준비가 성공한 경우, 세션 준비 명령의 SessionID를 사용하여 트리 접속이 이루어진다. QueryFileInformation이 뒤따르는 Create의 실행이나 또는 생성-판독-클로즈 셋트를 실행하는데도 동일한 방법이 사용될 수 있다.

조건부 및 내포(implied) 복합도 실행할 수 있다. 예를 들면, 오픈 및 파일이 64KB 미만인 경우 판독과 같은 조건부 복합 명령이 전송될 수 있어서, 이에 따라 1회 교환시 오픈한 후, 자동으로 작은 파일들을 입수하거나 큰 파일들은 오픈만 할 수 있다. 명시적으로 요청되지 않은 경우에도 디렉토리 오픈 요청에 대한 응답으로 디렉토리 열거 데이터(directory enumeration data)를 자동으로 리턴하는 것과 같은 내포 복합도 교환 회수를 줄일 수 있다. 이와 같이 향상된 복합을 사용하는 이득 및 장점은 대기 시간이 긴 네트워크에서 더욱 커진다.

프로토콜에서 효율 개선을 도모하는 다른 방법은 복수의 채널 통신을 이용하는 것이다. 클라이언트와 서버 간에 명령들을 위한 전송 접속(transport connection)이 사용될 수 있는데, 이 때 명령 하나는 데이터를 스트리밍하는 대안 채널을 지정한다. 예를 들면, 판독 요청은 오프셋과 길이뿐 아니라 데이터를 판독해 들일 대안 채널을 지정할 수 있다; 기록 요청도 마찬가지로 동작한다. 도 6은 오프셋(0)에서 시작하고, 데이터를 데이터 채널(5)로 스트리밍하라고 요청하는 1GB 판독 요청의 일 예시를 도시한다.

대안 채널 상으로 데이터를 스트리밍함으로써 패킷 헤더를 포함하고 처리할 필요가 없는 점을 포함하여 다수의 이점을 갖는다. 클라이언트는 버퍼를 미리 포스트(pre-post)하여 내부에 데이터를 스트리밍시킴으로써 종래의 단일 채널 통신처럼 하나의 버퍼에서 다른 버퍼로 복제할 필요가 없다. 공정성을 또 다른 장점으로 들 수 있는데, 예컨대 제어 채널 상의 요청 하나는 이 요청이 핸들링되기 전에 다량의 데이터(예컨대, 5GB) 전송이 종료될 때까지 대기할 필요가 없는데, 왜냐하면 5GB는 데이터 채널을 통과할 것이기 때문이다.

복수의 NIC가 점차 일반적이 되고 있는데, 프로토콜은 임의의 가용 네트워크 대역폭을 이용한다. 이것은 동일한 세션에 대해 복수의 접속으로, 접속들이 확립된 전송(또는 NIC)에 관계없이 작업하는 것을 포함한다. 특정의 하드웨어가 채택될 수 있다.

따라서, SMB 2. x를 갖춘 세션은 접속에 구속되지 않는다. 그 대신, 별개의 물리적 접속들을 통해 복수의 "채널들"이 확립될 수 있다. 세션들은 이들 접속 각각에 있을 수 있으며, 파일 및 프로세스를 참조하는데 사용되는 ID들이 채널들을 통하여 공통된다. 이는 네임스페이스 동작 및 생성 용으로 정규의 채널을 갖는 한편, 이용가능한 경우 판독 및 기록 용으로 특정의 네트워크 하드웨어를 사용하는 것을 가능하게 해 준다. 또한, 작은 네트워크 글리치가 데이터 손실로 이어지지 않을 수 있는데, 왜냐하면 하나의 채널이 세션을 열고 있는 한, 세션은 활동 상태를 유지하기 때문이다. 본 명세서에서는 세션 준비 명령 및 판독/기록 명령을 참조하여 다양한 구현 세부사항이 기술된다.

예를 들자면, 간단한 TCP로 기업의 공중망을 통해 서버로 접속을 확립한 클라이언트를 고려한다. 이것은 제1 접속이며, 따라서 항상 채널(0)이다. 양측이 데이터 전송용으로 사설망을 갖는다는 것을 감지하면, (예컨대 각각이 기가비트의 카드를 갖는다면) 클라이언트와 서버는 이 카드를 통해 채널(1)로서 제2 접속을 확립할 수 있다. 클라이언트가 소정의 파일을 브라우징하는 동안, 디렉토리 쿼리가 채널(0)을 통해 전송중이고, 데이터는 채널(1)을 통해 전송중이다. 클라이언트가 서버상에서 암호화된 소정의 디렉토리들을 브라우징하기 원하는 경우, 클라이언트가 데이터를 요청할 때, 재설정기는 데이터가 기밀(sensitive)이라는 것을 인식하여 서버에로 IP Sec(IP 보안)이 활동상태인 새로운 채널(채널; 2)을 확립한다. 클라이언트는 기밀 데이터 요청시, 기밀이 덜 한 데이터는 채널(1)로 오는 것을 계속하는 한편 (채널(1)이 더 빠르기 때문), 기밀 데이터는 채널(2) 상으로 전송되도록 요청할 것이다.

쉽게 이해될 수 있다시피, 간단히 대역폭 이득을 제공함과 함께 QoS 와 보안 개선의 기회를 제공함으로써 상당한 장점이 있다. 채널 판독/기록시, 서버/클라이언트는 임의의 데이터 판독 전에 수신 버퍼를 준비할 수 있어서, 메커니즘은 데이터 이동을 복제할 필요가 없으며 이로써 서버/클라이언트 확장성이 한층 개선될 수 있음을 주의한다.

또한, SMB 에러 패킷들이 임의의 데이터와 함께 태깅되도록 허가된다. 따라서 왜 실패했는지에 관한 기술이 제공되는데, 이것은 매우 가치있을 수 있다. 임의의 데이터와 함께 클라이언트에게 유용한 정보를 제공하는 태깅의 일 예로 도 8에 일반적으로 도시된 심볼 링크 평가가 있다. 본질적으로, 클라이언트 생성 요청은 사실상 다른 경로에 대한 심볼 링크인 경로를 요청함으로써 실패할 수 있다. 단순히 요청을 실패로 하는 대신, 새로운 경로를 제공함으로써 클라이언트는 리파스 경로(reparse path)로 변경할 수 있으며 이는 궁극적으로 성공할 것이다; 성공적인 경로를 찾기 위해서는 다수의 요청을 통한 반복이 필요할 수 있음을 주의한다.

예시적인 프로토콜 정의

새로운 헤더는 64 바이트 구조(예컨대, 현재 구조의 2배 사이즈)이다.

Protocol은 단순히 패킷을 식별하기 위한 프로토콜 식별자이다. 기존의 SMB 구현들에 있어서 이것은 {0xFF, 'S', 'M', 'B'}로 이루어진다. 새로운 프로토콜에 있어서, 이것은 {0xFE, 'S', 'M', 'B'}로 이루어진다.

StructureSize는 SMB2_HEADER 구조의 사이즈를 식별하며, 이후 다른 변경이 도입되는 경우 헤더 자체 내에서 소숫점 이하의 버전을 나타내는데 사용될 것이다.

Epoch는 서버의 "버전 카운트(version count)"를 나타낸다. 이것은 서버가 차단된 동안 상태가 유지되었는지 여부를 클라이언트에게 표시하기 위해 서버가 사이클링될 때(또는 서버 서비스가 정지 후 시작될 때)마다 증가된다. 이것은 향후 지속적인 핸들링에서 사용되며, 당분간 "Reserved"로 간주될 수 있다.

Status는 기존의 SMB 구현에서처럼 주어진 동작에 대한 에러 상태를 나타낸다.

Command는 본 명세서에서 기술된 바와 같은 패킷에 대한 명령을 식별한다.

CreditsGranted/CreditsRequested는 발명의 명칭이 "시퀀스 번호를 이용한 데이터 통신 조정"인 관련 특허출원에 기술된 바와 같이, 클라이언트가 좀 더 크레딧을 달라는 요청의 전송시, 또 서버가 새로운 크레딧 관리 기법으로 좀 더 크레딧을 허가하는 응답시 사용된다.

Flags는

를 포함하는 메시지와 관련되는데, Flags가 있으면, 이 메시지는 요청에 반대되는 응답임을 표시한다.

응답시, 서버는 요청을 비동기식으로 처리중임을 표시하도록 이 플래그를 설정하여 STATUS_PENDING을 리턴한다.

는 클라이언트의 복합 메시지 전송시, 동작들이 관련되어 있음을 표시하도록 설정되어 생성에서 오픈된 파일은 이후 동작들에 대해 FileId로서 사용된다.

는 패킷이 서명될 때 설정된다. 수신부는 서명을 검증해야 한다. 서명에 사용되는 키는 패킷을 전송한 세션에 기초한다.

이것은 DFS 동작이다. 서버는 DFS가 명칭을 개조(munge)하도록 허락해야 한다. 이것은 생성 선택으로 대체될 수 있다.

MessageId는 응답으로 전송중인 메시지를 식별한다.

ProcessId는 명령을 발행하는 프로세스의 클라이언트 측 식별정보를 기술한다.

SessionId는 명령에 대해 확립된 세션을 식별하거나, 사용중인 세션이 없는 경우 0이 된다.

TreeId는 명령에 대해 트리 접속을 식별하거나, 사용중인 트리 접속이 없는 경우 0이 된다.

AsyncId: 발명의 명칭이 "시퀀스 번호를 이용한 데이터 통신 조정"인 관련 특허출원에 기술된 바와 같이, 메시지 ID들은 사실상 시퀀스 번호이고, 가용 시퀀스 번호의 윈도우는 항상 오른쪽으로 슬라이딩 하도록 설정된다. 지나치게 오랜 시간 동안 실행될 명령(네임드 파이프 판독이나 변경-통지(change-notification), 오피로크 브레이크(oplock break) 상에서 계류중인 생성, 무기한으로 차단할 수 있는 임의의 것)은 윈도우의 슬라이딩 능력을 정지시킬 수 있다. 이 문제를 해결하기 위해서, 서버는 선택적으로 임의의 명령에 STATUS_PENDING과 함께 응답할 수 있으며, 상술한 SMB2_FLAGS_ASYNC_COMMAND 플래그를 설정하고, Session/Tree/ProcessId를 대신하여 고유의 식별자를 제공할 수 있다. 이것은 클라이언트가 응답을 수신한 것처럼 윈도우 슬라이딩을 계속할 수 있다는 것을 의미한다. 소정 시간 이후, 실제 응답이 매칭 AsyncId(및 CommandId)와 함께 와서 요청을 만족시키게 될 것이다. 클라이언트가 이 명령을 취소하기 원하는 경우, 클라이언트는 설정된 플래그 및 매칭 AsyncId와 함께 취소를 전송한다.

보안 서명은 이전의 프로토콜에서와 동일하며, 다만 숨겨진 인덱스 번호는 더 이상 없다는 점이 다르다. MID에 대해 인덱스가 반드시 시퀀스 번호를 사용해야 하는 것은 아니다(이것은 재생성(replayability)을 직접적으로 방해한다). 이는 동작들을 전송 도중 시퀀스화 시키지 않고도 보안 서명의 사용을 가능하게 해 준다.

NextCommand는 이 헤더의 시작에서부터 메시지 내 다음 명령까지의 오프셋을 나타낸다. 메시지는 쿼드 얼라인(quad-aligned)되어야 한다. SMB2_FLAGS_RELATED_COMMAND를 사용하여 상술한 바와 같은 다양한 복합을 가능하게 해 준다.

명령 포맷

협상

상술된 바와 같이, 클라이언트와 서버는 서로의 능력 판정을 돕는 핸드셰이크(handshake)의 일부로서 협상 요청 및 응답을 교환한다.

포맷

세션 준비

상술한 바와 같이 세션 준비는 새로운 세션을 위한 인증 프로세스를 핸들링한다.

포맷

로그오프

기존의 세션을 로그오프한다.

포맷

이 명령은, 헤더 내에서 지정된 SessionId를 갖는 세션을 찢는다. 오픈된 파일들은 클로즈되고, 기존의 다른 구조(트리 접속 등)는 찢겨진다. 주어진 SessionId에 대해 더 이상의 다른 동작들을 진행될 수 없다.

트리 접속

서버 머신 상의 공유된 리소스로 트리 접속을 생성한다.

포맷

클라이언트는 트리 접속을 확립하기 위해 이 명령을 서버에게로 발행한다. 경로는

의 형태이며, 버퍼를 채운다. 서버의 명칭을 포함함으로써 스코핑 공유와 같은 특징이 가능하다.

서버로부터의 응답이 성공적이면, 클라이언트는 ShareFlags 및 ShareCapabilities와 함께 헤더 내 TreeId를 수신한다. 현재는, ShareFlags가 어떤 CSC 캐싱 특성이 공유를 위한 것인지를 클라이언트에게 표시하지만, 향후 좀 더 추가될 수 있다. ShareCapabilities는 공유를 지원하는 파일 시스템이 파일-레벨의 보안, 타임워프(timewarp), TxF(거래 파일 시스템) 또는 클라이언트-측 암호화를 지원하는지 여부를 클라이언트에게 표시해준다. 파일 시스템이 전부는 아니고 일부 서브트리(장착 부분과 같은 경우) 상에서 이들 특성을 지원하는 경우, 파일 시스템은 이들 특성을 지원하지만, 허가되지 않은 경우 이들 특성을 사용하라는 요청 각각은 단지 실패할 것임을 리턴해야 한다. 클라이언트는 자신이 해석할 수 없는 임의의 플래그나 능력은 무시해야한다.

트리 차단

기존의 트리 접속을 찢는다.

포맷

일단, 이 명령이 처리되면, 주어진 TreeId 상에서 더 이상의 동작들이 성공적으로 종료되지 못할 수 있다. TreeId는 헤더로부터 취한다.

생성

파일, 프린터 또는 파이프를 오픈한다.

포맷

생성 요청은 가변 길이 요청으로서, 종래의 잘 정의된 속성들뿐 아니라 다양한 속성들을 갖는 파일의 생성을 가능하게 해 준다. 표준적인 경우(확장형 속성이 없는 경우)는 명백하다; 클라이언트는 RootDirectoryFid (원하는 경우, 상대적인 오픈를 위해), DesiredAccess, FileAttributes, ShareAccess, CreateDisposition 및 CreateOptions을 기입한다. 이들은 원하는 오피로크 레벨을 설정하며, QoS를 위한 SecurityFlag 및 Impersonaton 레벨을 기입한다. 현재는 SmbCreateFlags가 정의되어 있지 않지만, 사용을 위한 공간은 할당되었다. 클라이언트가 서버로 이 패킷을 전송하면, 서버는 파일을 오픈하고, 실패 코드를 리턴하거나, 또는 파일을 식별하는 FileId, Creation/LastAccess/LastWrite/LastChangeTime, AllocationSize와 EndOfFile 정보 및 FileAttributes와 함께 성공을 리턴한다.

이것은 현재의 프로토콜이 동작하는 것과 똑같은 표준적인 경우이다. 좀 더 발전된 경우로서, 사용자가 확장형 속성(EAs: extended attributes)을 갖춘 파일 생성을 원하는 경우를 고려한다. 이전의 프로토콜에서는, 거래 호출(Transact call)을 통한 완전히 다른 방식으로 이것을 처리하였다. 이제, 클라이언트는 표준으로서 생성 요청을 구축할 수 있으며, 생성 요청의 말단에 CreateContext를 부가할 수 있다. 요청은 "ExtA"라는 명칭을 가지며, 데이터는 파일 상에 설정될 EAs를 포함할 것이다. 서버가 이를 수신하면, EA 데이터를 파싱 아웃하여 생성과 함께 발행할 것이다. 생성 응답시, 추가적인 정보를 제공하기 위해서 CreateContext도 리턴될 수 있다. 1회 반복시, 명칭들은 길이(4)를 가지므로 이들을 long으로 포맷화하고, 스위칭할 수 있다. CreateContext의 현재 리스트는 다음과 같다.

1) "ExtA" - 데이터는 생성된 파일 상에 부가될 확장형 속성을 포함한다.

2) "SecD" - 데이터는 생성된 파일 상에 부가될 자가-상대적(self-relative) 보안 기술자를 포함한다.

3) "TWrp" - 데이터는 오픈할 파일을 찾는데 사용되어야 하는 타임워프 타임 스탬프를 포함한다. 타임스탬프는 시스템 시간 포맷을 갖는다.

4) "MrTx" - 데이터는 파일을 거래로 오픈할 때 사용될 정돈된 거래(marshalled transaction)를 포함한다.

5) "MnVr" - 데이터는 거래된 파일을 오픈 위한 미니-버전 번호(ULONG)를 포 함한다.

6)"Vers" - 데이터는 오픈된 파일(생성 응답)의 버전 번호(ULONG)를 포함한 다.

7)"NFid" - 데이터는 오픈된 파일(생성 응답)의 NTFS Fid(LARGE_INTEGER)를 포함한다.

8) "$Efs" - 데이터는 새로 암호화된 파일 상에 스탬핑될 $EFS 스트림을 포 함한다.

9) 'CSEl" - 데이터는 오픈된 암호화된 파일(생성 응답)의 $EFS 스트림을 포 함한다.

서버들이 지원하게 되면 이 외의 CreateContext 값들이 추가될 수 있다(값들이 추가됨에 따라 값들은, 서버와 관련된 능력 비트를 갖거나 또는 새로운 다이얼렉트 개정판과 관련될 수 있는데 이에 따라 클라이언트는 생성 요청을 발행하기 전에 서버가 어떤 태그를 지원하는지 알 수 있다). 인식되지 않는 컨텍스트 태그를 갖는 생성 요청을 수신한 서버는 그 요청을 실패로 처리할 것이다.

클로즈

클라이언트는 앞서 오픈된 파일의 인스턴스를 클로즈하도록 클로즈를 전송한다. 일단 클로즈 처리가 되면, 그 이전 FID에 대해 어떠한 파일 동작도 허용되지 않는다.

포맷

클로즈 명령을 위해, 클라이언트는 (SystemTime 포맷에 있어서) LastWriteTime과 함께 그 클로즈되는 파일의 FileID를 지정한다. 이는 클라이언트로 하여금 캐시된 기록이 해당 파일에 대해 수행되었던 최종 시간을 그 파일에 대한 최종 기록 시간으로서 설정할 수 있게 한다. 클라이언트는 또한 LastWriteTime에 대하여 0을 전송하여 1을 지정하고자 하지 않는다는 점을 표시할 수 있다. 이러한 구조는 또한 현재는 정의되어 있지 않지만 추후 이용될 수 있는 Close 플래그를 위하여 공간을 할당한다.

플러시(FLUSH)

플러시 명령은 서버에게 소정 파일 상에 캐시된 모든 데이터를 플러시하도록 알리는 것이다.

포맷

서버로부터 성공적으로 응답이 있으면, 클라이언트는 그 보조적 영구 저장소로 모든 캐시된 데이터가 플러시되었음을 보장받게 된다. 클라이언트는 플러시를 원하는 파일의 FileId를 지정한다. 파이프 상의 플러시는 그 파이프에서 전체 데이터가 소모될 때까지 잠시 동안 다시 나타나지 않을 것이다.

판독

오픈 파일에서 데이터를 판독한다.

포맷

판독은 매우 자명한 것이다. 클라이언트는 (FileId를 통하여) 파일, 오프셋 및 판독 길이를 지정하고, 서버는 데이터를 리턴한다. 클라이언트가 지정할 수 있는 기타 다른 몇 가지가 있다. MinCount는 성공적 리턴을 위하여 파일로부터 판독할 최소량을 서버에게 알려준다. 판독이 부족하게 되면, 서버는 전체 데이터 버퍼를 리턴하는 대신에 간단하게 실패를 리턴할 것이다. 클라이언트는 또한 보다 양호한 처리를 위하여 Padding(패딩)을 추천할 수 있다. 이는 서버가 데이터를 두어야 하는 판독 응답 패킷에 대한 오프셋이다. 이는 클라이언트로 하여금 전송 중의 정보를 수신하였을 때 판독 응답 버퍼들을 좀 더 효율적인 상태에 놓이도록 한다. 나머지(remaining) 필드는, 판독의 단지 일 섹션인 경우, 서버에게 전체 판독은 얼마나 많은 양에 대한 것인가를 알린다. 따라서, 클라이언트가 1K 청크 단위로 8K 판독을 하고자 할 경우, 이는 Remaining = 7K와 함께 1K에 대한 판독을 발행할 것이다. 이는 한 번의 동작으로 전체 8K를 판독하고 그 데이터를 다시 클라이언트에게 버퍼링함으로써 최적화할 수 있는 옵션을 서버에게 허용한다.

서버의 응답시, 이는 판독 명령에서 지정된 DataRemaining과 함께 (DataLength 필드 내에서) 자신이 얼마나 많은 데이터를 리턴하는지를 나타낸다.

명령 내에서 지정된 채널이 명령이 들어왔던 채널이 아닌 경우, 사용자는 채널 판독을 요청한다. 이는 내가 채널 0 상에서 "channel(채널)=1" 및 "Length(길이)=0, Remaining(나머지)=64K"에 의해 판독을 요청하는 경우, 서버는 "DataLength=0, DataRemaining=64K"로 응답할 것이고 Channel(채널)1을 통하여 오는 다음 64K 바이트가 데이터가 될 것임을 의미한다. 클라이언트는 이 명령이 발행된 때 채널 1 상에는 아무런 데이터도 계류 중이지 않다는 점을 보장하기 위하여 이를 동기화할 책임을 진다. 클라이언트는 또한 (채널 0 상에서) "판독 Channel=1, DataLength=1K, Remaining=7k"를 발행했을 수 있고, 그 결과 응답은 처음 1K의 데이터를 포함할 것이고 그 데이터의 나머지(뒤 7K)는 채널 1을 통하여 스트리밍될 것이다.

기록

오픈 파일에 데이터를 기록한다.

포맷

클라이언트는 (FileId에 의해서 지정된) 파일, 오프셋 및 기록 길이를 채우고, 데이터를 첨부한다. 서버 성능을 돕도록 원래의 협상 응답으로서 리턴된 데이터가 패딩될 것이 추천된다. 클라이언트는 또한 서버에게 얼마나 더 많은 데이터를 기록할 것인지 서버에게 알려서 서버로 하여금 최적화가 가능하게 할 수 있다. 응답 시, 서버는 얼마나 많이 기록되었는지를 표시하고, 앞으로 기대되는 양을 리턴한다.

기록으로서 지정된 채널이 명령이 들어왔던 채널이 아닌 경우, 클라이언트는 다른 채널 상의 데이터를 스트리밍하도록 요구한다. 채널 0 상에서 "Channel=1, Length=0, Remaining=64K"으로 수신된 기록이 일 예가 된다. 클라이언트는 채널(1) 상에서 64K 기록을 스트리밍할 것을 요구하고 있다. 서버는 그 기록을 허용하기 위하여 "Count=0, Remaining=64K"로 응답할 것이다. 그 응답은 그 채널 상에서 데이터가 전송되고 ack된 이후에 올 두 번째 응답을 위한 AsyncID를 포함할 것이다. 그 다음, 채널(1) 상에서 스트리밍된 다음 64K 바이트가 데이터가 될 것이다. (헤더는 없다). 완료 시, 특정 채널이 고유 승인을 갖춘 경우(그러한 경우에는 그 채널 자체 상에서 고유의 승인이 발생할 것이다)가 아니라면, 서버는 채널 0 상에서 SMB2_RESP_WRITE를 전송하여 동작의 성공/실패를 표시하고 AsyncId 정보를 이용하여 두 번째 응답을 전송할 것이다.

브레이크_오피로크

파일 상에 이루어진 기회 로크(opportunistic locks)의 해제를 요청하고 승인하는데 이용된다.

포맷

클라이언트가 기회 로크를 유지하고 있는 파일에 대해, 그 기존 로크의 브레이크를 요구하는 방식으로 또 다른 사용자가 액세스를 요구할 경우, SRV는 그 클라이언트에게 SMB2_RESP_BREAK_OPLOCK을 전송할 것이다. 그러면, 클라이언트는 해당하는 소정의 파일에 대해 그 oplock을 해제하도록 REQ_BREAK_OPLOCK을 전송해야 하고, SRV가 다시 이를 승인하는 응답을 할 것이다.

로크

바이트-범위 로크를 요청하는데 이용되고, 또한 기회 로크를 요청하는데 (그리고 하나가 브레이크되었을 때 클라이언트에게 알리는데) 이용된다.

포맷

LOCK 요청을 위한 신택스는 SMB1 로크 요청과 유사하다. 클라이언트는 FileId를 지정하고, 로크하기 원하는 길이와 오프셋을 표시하는 하나 이상의 SMB_LOCK 구조들을 지정한다. 이들 LOCK 구조들은 모두가 로크들 또는 언로크(unlock)들 중 하나여야 한다. 그러나, 하나의 배치(batched) 로크 동작으로 공유 로크 요청들과 배타적 로크 요청들을 혼합할 수도 있다. 로크 배치(lock batching)에 관한 가장 일반적 사용은 일련의 로크들을 배치 오피로크 브레이크의 일부로서 청구하는 것일 것이고, 모든 로크가 성공할 것임을 확신할 경우 가장 유용하다.

성공적 리턴은 그 요청된 바이트 범위 로크를 달성(또는 해제)했다는 점을 클라이언트에게 알린다. 실패한 경우에는, 바이트 범위 로크가 허용되지 않은 것이다.

에코(ECHO)

에코는 서버가 주어진 시점에 정지해 있는지 여부를 판정하기 위하여 클라이언트에 의해서 이용된다. 이 명령을 수신하면, 서버는 단지 스스로를 돌아본 다음 성공을 리턴할 것이다.

포맷

서버는 자신이 적절하게 동작 중임을 표시하기 위하여 해당 패킷에 응답한다. 클라이언트로 하여금 서버를 "핑(ping)"할 수 있게 하는데 사용된다.

취소(CANCEL)

전송된 동작의 취소를 요청하기 위하여 클라이언트에 의해서 사용된다.

포맷

취소는 아무런 응답도 갖지 않지만, 해당 명령 자체는 STATUS_CANCELLED와 함께 성공적으로 완료되거나 실패로 끝나야 하고, 이는 가능한 빨리 일어나야 한다. 전송되는 동작은 그 취소 명령의 MessageId를 공유할 것이므로 식별된다. 이는 서버로 전송된 MessageId가 이미 앞서 사용되었을 수 있는 하나의 경우이다. 응답이 AsyncId와 함께 도달한 경우라면, 이는 헤더에 존재해야 하고, 해당 명령을 서버에 배치하는데 이용될 것이다.

IOCTL

Ioctl은 네트워크 전체에 걸친 Device Control(장치 제어) 또는 File System Control(파일 시스템 제어) 명령을 발행하는데 이용된다.

포맷

IOCTL은 네트워크 전체에 걸쳐 일반적 파일 시스템이나 장치 제어 명령을 발행하는데 이용된다. 이는 제어 코드의 메소드(METHOD)에 기초하여 입력 및 출력 버퍼들을 패킹하고 네트워크 전체에 걸쳐 이들을 전송한다. 그 다음 서버 측에서는 이들을 재패키징하여 파일 객체에 대해 FSCTL/IOCTL을 발행한다. 그 결과가 마찬가지로 패킹되어 상태 코드와 함께 사용자에게 리턴된다. 허용 가능한 FSCTL/IOCTL 코드 셋트는 SRV 또는 하부의 파일 시스템들 양자에 의해서 제한될 수 있다. (모두가 각각 반드시 유효한 것은 아니다)

버퍼링된 요청 또는 직접적 요청들에 있어서, 요청 상에서는 Input 만이 유효하고 응답 상에서는 Output 만이 전송된다. 어떤 요청의 경우에도, Input과 Output 모두가 양 방향으로 전송되지는 않는다.

디렉토리 쿼리(QUERY DIRECTORY)

클라이언트로 하여금 네트워크 전체에 걸쳐 오픈 디렉토리 핸들 상에서 디렉토리 열거를 쿼리할 수 있게 한다.

포맷

QueryDirectory 호출은 기존의 NT 의미론에 매우 밀접하게 매칭된다. 호출자는 InfoClass, 디렉토리 오픈을 위한 FileId, (와일드카드/파일 검색 파람(params) 또는 기존 검색용 레쥬메 네임(resume name)을 지정하는) 파일명 부분 및 그 호출과 관련된 임의의 유효 SL_ flags를 제공하고, SRV는 버퍼를 OutputBufferLength까지 리턴할 것이다.

QueryDirectory 플래그 구조 내에 포함될 수 있는 새로운 플래그(SMB2_REOPEN)도 존재한다. 이러한 플래그는 SL_RESTART_SCAN 플래그의 좀 더 강력한 버전이다. 후자는 단지 지정된 검색이 변경되지 않은 스캔들의 재개를 허용한다. (즉, *.* 또는 t* 검색을 재개한다.) 후자는 서버에게 지정된 검색이 변경된 스캔을 재개하도록 알린다. 이러한 플래그를 사용하기 위하여, 호출자는 그 호에 대한 배타적 사용과, 어떠한 계류 중인 동작(예컨대, 변경 통지)도 없음을 보장해야만 한다. 서버는 이러한 동작을 수행하기 위한 적절한 단계들을 취하는데, 서버측에서 하부의 디렉토리 핸들을 클로즈하고 재오픈하는 과정을 포함한다. 이는 클라이언트에 대해 투명하다.

변경 통지(CHANGE NOTIFY)

이러한 잠재적인 장기 동작(potentially long-running operation)은 클라이언트로 하여금 디렉토리 상의 변경 통지들을 등록할 수 있게 한다.

포맷

호출자는 그 호출자가 어떤 변경들에 관심을 갖고 있는지 지정하는 CompletionFilter와 함께 해당 디렉토리에 대한 FileID를 전송한다. 이들은 또한 SL_WATCH_TREE 플래그를 전송하여 순환적 통지 동작을 표시한다. 이러한 동작은 무한정한 시간 동안 계류할 수 있으므로 "async" 작동상태(behavior)를 거의 항상 호출할 것이다. 또한 동일 핸들 상에서 어떠한 추가적 변경 통지 요청들도, 로컬 파일 시스템 작동상태에서와 같이, 첫 번째 변경이 완료하는 것을 기다리면서 연기할 것임을 알아야 한다.

정보 쿼리(QUERY INFO)

클라이언트로 하여금 원격 시스템으로부터의 정보를 쿼리할 수 있게 한다. 현재 이는 파일 정보, 파일-시스템 정보, 보안 정보 또는 할당 정보를 쿼리하는데 이용될 수 있다.

포맷

클라이언트는 파일 정보, 파일 시스템 정보, 보안 정보 또는 할당 정보에 대한 요청인지 여부를 표시하기 위하여 InfoType에 SMB2_0_INFO_* 옵션들을 지정한다. FileId는 (파일 인포 또는 보안 정보를 위하여) 문제가 된 파일을 표시한다. 파일 시스템 인포 또는 할당 요청들을 위하여 파일이 존재하는 볼륨이 사용된다.

하위 정보 레벨이 FileInfoClass에 채워지는데, 이는 쿼리 중인 정보 유형에 의존한다. 파일 정보 쿼리의 경우 이는 FILE_INFORMATION_CLASS가 될 것이고, 파일 시스템 정보의 경우는 FS_INFORMATION_CLASS가 될 것이다. 할당 및 보안에 대해서는 0이 될 것이다.

현재 입력 버퍼는 Quota 요청들을 위해서만 사용되는데, 그러한 요청들은 무엇이 요청되고 있는지를 결정하기 위하여 입력에 대해 SMB2_QUERY_QUOTA_INFO 구조를 취하기 때문이다. 다른 요청들에 대해서는 비어있는(empty) 상태가 될 것이다.

OutputBufferLength는 사용자에게 리턴할 최대 데이터량을 지정한다.

정보 설정(SET INFO)

클라이언트로 하여금 원격 시스템 상에서 정보를 설정할 수 있게 한다. 현재 이는 파일 정보, 파일-시스템 정보, 보안 정보 또는 할당 정보를 설정하는데 이용될 수 있다.

포맷

설정되는 정보의 타입과 구체적 클래스가 QUERY_INFO에 대해 기술된 바와 같이 Flags 및 FileInfoClass 필드에 설정된다. 제공되는 입력 버퍼가 설정되는 정보이고, FileId는 그 파일을 식별한다.

SetSecurity 호에 있어서, SecurityInformation 필드는 설정되는 인포를 표시한다(즉, OWNER_SECURITY_INFORMATION 등).

결론

본 발명은 다양한 변형 및 대안적 구조를 허용할 수 있으며, 본 발명에 관한 예시적인 소정의 실시예들이 도면에 도시되어 있고 앞서 상세히 기술되었다. 그러나, 본 발명이 개시된 특정 형태로 제한되는 것은 아니고, 반대로 모든 변형, 대안적 구조들 및 등가물들은 본 발명의 사상과 영역 내에 속하는 것이다.

Claims (10)

1. 실행될 때에 단계들을 수행하는, 컴퓨터 구현된 방법으로서,
   상기 단계들은,
   네트워크 파일 서버에서, 클라이언트로부터 복수의 파일 시스템 명령을 포함하는 제1 복합 요청을 수신하는 단계 - 상기 복수의 파일 시스템 명령 중 적어도 하나는 상기 복수의 파일 시스템 명령 중 또 다른 하나와는 상이함 -;
   상기 제1 복합 요청이 상기 파일 시스템에 저장된 하나보다 많은 파일에서 실행되는 관련되지 않은 파일 시스템 명령들을 포함한다고 판정하는 단계;
   상기 제1 복합 요청이 상기 파일 시스템에 저장된 하나보다 많은 파일에서 실행되는 관련되지 않은 파일 시스템 명령들을 포함한다고 판정한 것에 응답하여, 상기 복수의 파일 시스템 명령들 각각을 상기 복수의 파일 시스템 명령들이 연달아 처리될 것을 요청하지 않고 별도의 파일 시스템 명령으로서 핸들링하는 단계;
   상기 네트워크 파일 서버에서, 상기 클라이언트로부터 제2 복수의 파일 시스템 명령을 포함하는 제2 복합 요청을 수신하는 단계;
   상기 제2 복합 요청이 상기 파일 시스템에 저장된 단일 파일에서 실행되는 관련된 파일 시스템 명령들을 포함한다고 판정하는 단계; 및
   상기 제2 복합 요청이 상기 파일 시스템에 저장된 단일 파일에서 실행되는 관련된 명령들을 포함한다고 판정한 것에 응답하여, 상기 제2 복수의 파일 시스템 명령을 연속하여 핸들링하는 단계
   를 포함하는, 컴퓨터 구현된 방법.
2. 제1항에 있어서,
   상기 제2 복합 요청은 생성/오픈 명령을 포함하고,
   각각의 요청을 연속하여 핸들링하는 것은 각각의 후속하는 관련된 명령에 대해 상기 생성/오픈 명령으로부터의 파일 핸들을 사용하는 것을 포함하는 컴퓨터 구현된 방법.
3. 제2항에 있어서,
   상기 생성 명령과 함께 수신된 추가적 컨텍스트 데이터를 처리하는 단계를 더 포함하는 컴퓨터 구현된 방법.
4. 제1항에 있어서,
   상기 제2 복합 요청이 수신되었던 채널과는 별도의 데이터 채널에서 I/O 관련된 요청을 핸들링하는 단계를 더 포함하는 컴퓨터 구현된 방법.
5. 제1항에 있어서,
   명령들의 집합으로부터 하나 이상의 명령들을 수신하는 단계를 더 포함하고,
   상기 집합은 별도의 데이터 채널에서 추가의 컨텍스트 데이터가 첨부된 생성 명령 및 데이터 통신을 요청하는 데이터-관련된 명령을 포함하는 컴퓨터 구현된 방법.
6. 컴퓨터 시스템으로서,
   컴퓨터-실행가능 명령어들을 실행하기 위한 하나 이상의 프로세서;
   컴퓨터-실행가능 명령어들을 저장하기 위한 컴퓨터 판독가능 매체
   를 포함하고,
   상기 컴퓨터-실행가능 명령어들은 상기 하나 이상의 프로세서에 의해 실행될 때에, 단계들을 수행하며,
   상기 단계들은,
   네트워크 파일 서버에서, 클라이언트로부터 복수의 파일 시스템 명령을 포함하는 제1 복합 요청을 수신하는 단계 - 상기 복수의 파일 시스템 명령 중 적어도 하나는 상기 복수의 파일 시스템 명령 중 또 다른 하나와는 상이함 -;
   상기 제1 복합 요청이 상기 파일 시스템에 저장된 하나보다 많은 파일에서 실행되는 관련되지 않은 파일 시스템 명령들을 포함한다고 판정하는 단계;
   상기 제1 복합 요청이 상기 파일 시스템에 저장된 하나보다 많은 파일에서 실행되는 관련되지 않은 파일 시스템 명령들을 포함한다고 판정한 것에 응답하여, 상기 복수의 파일 시스템 명령들 각각을 상기 복수의 파일 시스템 명령들이 연달아 처리될 것을 요청하지 않고 별도의 파일 시스템 명령으로서 핸들링하는 단계;
   상기 네트워크 파일 서버에서, 상기 클라이언트로부터 제2 복수의 파일 시스템 명령을 포함하는 제2 복합 요청을 수신하는 단계;
   상기 제2 복합 요청이 상기 파일 시스템에 저장된 단일 파일에서 실행되는 관련된 파일 시스템 명령들을 포함한다고 판정하는 단계; 및
   상기 제2 복합 요청이 상기 파일 시스템에 저장된 단일 파일에서 실행되는 관련된 명령들을 포함한다고 판정한 것에 응답하여, 상기 제2 복수의 파일 시스템 명령을 연속하여 핸들링하는 단계
   를 포함하는, 컴퓨터 시스템.
7. 제6항에 있어서,
   상기 제2 복합 요청은 생성/오픈 명령을 포함하고,
   각각의 요청을 연속하여 핸들링하는 것은 각각의 후속하는 관련된 명령에 대해 상기 생성/오픈 명령으로부터의 파일 핸들을 사용하는 것을 포함하는 컴퓨터 시스템.
8. 제7항에 있어서, 상기 단계들은,
   상기 생성 명령과 함께 수신된 추가적 컨텍스트 데이터를 처리하는 단계를 더 포함하는 컴퓨터 시스템.
9. 제6항에 있어서, 상기 단계들은,
   상기 제2 복합 요청이 수신되었던 채널과는 별도의 데이터 채널에서 I/O 관련된 요청을 핸들링하는 단계를 더 포함하는 컴퓨터 시스템.
10. 제6항에 있어서, 상기 단계들은,
    명령들의 집합으로부터 하나 이상의 명령들을 수신하는 단계를 더 포함하고,
    상기 집합은 별도의 데이터 채널에서 추가의 컨텍스트 데이터가 첨부된 생성 명령 및 데이터 통신을 요청하는 데이터-관련된 명령을 포함하는 컴퓨터 시스템.

Images