IRP_MJ_DEVICE_CONTROL Irp의 완료처리

IRP_MJ_DEVICE_CONTROL IRP의 처리를 완료할 때 사용하는 일반적인(?) 코드이다.

irp->IoStatus.Information와 irp->IoStatus. Status 는 정확히 어떠한 용도로 사용되는가?

드라이버 입문서적을 자세히 읽어 본 사람이라면 잘 알고 있겠지만, 드라이버 개발 초기 많이 실수를 하기도 했던 부분이라 정리해 본다.

n  irp->IoStatus.Status

ü  IRP의 처리 결과를 설정한다. 여기에 설정한 Status값에 따라 User-mode에서 DeviceIoControl()함수를 호출한 후, 이어서 호출하는 GetLastError()의 에러값이 설정된다.

n  irp->IoStatus.Information

ü  Buffered-Methord방식으로 버퍼를 관리하는 DeviceIoCotrol의 경우, 시스템 버퍼에서 user-buffer로 복사되는 사이즈를 기술한다. 예를 들어 irp->AssociatedIrp.SystemBuffer에 10Byte를 복사했더라도 irp->IoStatus.Information에 0을 대입한 후 리턴해 주면, user-buffer에는 어떠한 데이터도 복사되지 않는다.(즉 user-mode에서는 드라이버에서 복사한 내용을 확인 할 수 없다)

FILE_OBJECT의 RelatedFileObject 필드가 유효한 경우

* MSDN의 FILE_OBJECT 섹션을 찾아보면 RelatedFileObject필드는 IRP_MJ_CREATE IRP를 처리하는 시점에서만 유효함을 알 수 있다.

그렇다면 IRP_MJ_CREATE IRP를 처리할때는 RElatedFileObject필드가 항상 유효한가?
MS 문서에 Documentation 되어 있는 내용은 아니지만, 테스트 해보면 다음과 같은 결과를 알수 있다.

1) 절대 경로를 이용하여 파일을 생성하는 경우, [ fopen("E:\\test.txt", _T("w")); ]

FileObject->RelatedFileObject == NULL

FileObject->FileName 필드가 포함하는 값 : 파일경로+파일명 포함

* FullPath를 얻기 위해서는 [볼륨명+FileObject->FileName]의 조합이면 된다.

2) 상대 경로를 이용하여 파일을 생성하는 경우, [ fopen("test.txt", _T("w")); ]

FileObject->RelatedFileObject != NULL

FileObject->RelatedFileObject->FileName 필드가 포함하는 값 : 폴더패스

FileObject->FileName 필드가 포함하는 값 : 파일명

* FullPath를 얻기 위해서는 [볼륨명+FileObject->RelateFileObject+ FileObject->FileName]의 조합이 필요하다.

File System의 로드와 볼륨마운트 과정

1.     파일시스템의 로드

A.     IRP_MJ_FILE_SYSTEM_CONTROL : IRP_MN_MOUNT_VOLUME

B.     IRP_MJ_FILE_SYSTEM_CONTROL : IRP_MN_LOAD_FILE_SYSTEM

2.     볼륨 마운트 - 일반 볼륨

A.     IRP_MJ_FILE_SYSTEM_CONTROL : IRP_MN_MOUNT_VOLUME

B.     IRP_MJ_FILE_SYSTEM_CONTROL : IRP_MN_LOAD_FILE_SYSTEM

C.     Attatch시점

                i.         IRP_MJ_FILE_SYSTEM_CONTROL : IRP_MN_MOUNT_VOLUME

               ii.         볼륨 R/W 감시를 위한 필터 설치

ü  볼륨별 필터 DeviceObject 생성

ü  볼륨별 Device Attatch

3.     볼륨 마운트 - 네트워크 드라이브 볼륨
네트워크 드라이브는 일반 볼륨과는 다른 방식으로 마운트 된다.

A.     Attatch시점

                i.         IRP_MJ_CREATE

ü  DriverName= "\FileSystem\MRxSmb"

ü  DeviceName= "\Device\LanmanRedirector"

               ii.         볼륨 R/W 감시를 위한 필터 설치

ü  모든 네트워크 드라이브 볼륨에 대해 하나의 필터 DeviceObject

*SMB(Server Message Block) - 네트워크를 통해 데이터를 전송 할 수 있도록 클라이언트와 서버 사이에

사용되는 네트워크 프로토콜

Organization of Wdm.h, Ntddk.h, and Ntifs.h

http://msdn.microsoft.com/en-us/library/aa906303.aspx

WDK의 Vista이전 버전에는 드라이버 개발에 쓰이는 메인 header(Wdm.h, Ntddk.h, and Ntifs.h) 들이 중복된 선언을 많이 가지고 있었다.

WDK Vista버전부터 Wdm.h, Ntddk.h, and Ntifs.h 파일들은 중복된 정보를 포함하지 않도록 계층적으로 구성되었다.
higher-level 파일들은 lower-level 파일들을 포함(include)하며 각각의 함수와 구조체들은 단 한번만 선언되어 있다.

Ntifs.h 는 Ntddk.h 를 include하며 Ntddk.h 는Wdm.h를 include한다. 아래의 그림은 이러한 구조를 보여준다.

Diagram illustrating hierarchical header files

최대 소켓연결 세션 늘리기

출처: http://serious-code.net/moin.cgi/WindowsRegistryReference

Windows 2000에서는 아래의 레지스트리 값을 변경해주지 않으면, 생각보다 적은 숫자의 연결 밖에 받아들이지 못한다.

아래의 네가지 값을 적당히 세팅한 레지스트리 파일 : socket.reg

1 MaxFreeTcbs

위치 : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

시스템이 TCP 연결 유지를 위해 생성하는 TCP Control Blocks(TCBs)의 숫자를 결정한다. 하나의 연결은 하나의 블록을 요구하기 때문에, 이 값은 TCP가 동시에 몇 개의 연결을 처리할 수 있느냐를 결정하게 된다. 모든 블록이 사용 중인 상황에서 새로운 연결이 들어오게 되면, TCP는 TIME_WAIT 상태인 연결 중에 하나를 강제로 끊어버리고, 블록을 해제한 후, 그 블록을 새로운 연결에 사용하게 된다.

보통 TCP는 TcpTimedWaitDelay에 지정되어 있는 시간이 지나지 않은 경우, 연결을 해제하지도 않고, 그 연결에 사용된 자원을 재사용하지도 않는다. 이 시간은 보통 TIME_WAIT 또는 2MSL (2 x maximum segment lifetime) 상태라고 불린다. 하지만 시스템이 매우 많은 연결을 받아들여 자원이 바닥날 상황에 이르면, TcpTimedWaitDelay에 지정된 시간이 아직 남아있는 경우에도 연결에 할당되어 있는 자원을 해제하게 된다.

이 항목의 기본 값은 시스템의 물리적 메모리 크기와 OS 버전에 따라 달라진다. 그 값들은 다음과 같다.

Windows 2000은 기본적으로 이 항목을 레지스트리에다 생성하지 않으므로 직접 생성해줘야한다.

2 MaxHashTableSize

위치 : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

TCP Control block이 저장되는 해쉬 테이블의 크기를 결정한다.

TCP는 컨트롤 블록들을 빠르게 검색하기 위해 해쉬 테이블에다 저장한다. 만일 시스템이 동시에 생성할 수 있는 TCB의 숫자를 변경한다면(MaxFreeTcbs 값을 변경한다면), 이 항목의 값 또한 그에 비례해서 변경해줘야한다.

이 항목의 값은 반드시 2의 승수여야한다. 만일 2의 승수를 입력하지 않는다면, 시스템은 자동으로 입력한 수보다 큰 2의 승수 중에 가장 작은 것을 찾아 사용한다.

Windows 2000은 기본적으로 이 항목을 레지스트리에다 생성하지 않으므로 직접 생성해줘야한다.

3 MaxUserPort

위치 : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

bind()를 명시적으로 호출하지 않는 경우(connect 등을 호출했을 때), 시스템이 자동으로 할당하는 포트 번호의 최대값을 결정한다. 보통 이런 포트 번호는 1024에서 5000 사이의 값이다.

Windows 2000은 기본적으로 이 항목을 레지스트리에다 생성하지 않으므로 직접 생성해줘야한다.

4 TcpTimedWaitDelay

위치 : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

TCP가 소켓 연결을 해제하고, 할당한 자원을 재사용하기 위해 기다려야할 시간을 결정한다. 소켓 연결을 끊는(close) 시점과 소켓 연결을 해제(release)하는 시점 사이의 간격은 TIME_WAIT 또는 2MSL 상태라고 불린다. 이 시간 동안 클라이언트와 서버가 새로 연결을 만드는 일은, 완전히 새로운 연결을 만드는 것보다 훨씬 적은 시간을 요구한다.

RFC 793은 끊긴(closed) 연결을 적어도 2MSL 시간 동안은 완전히 해제(release)하지 말고 기다릴 것을 요구하고 있다. 연결이 해제되면 그 연결에 할당되어 있던 소켓 쌍(클라이언트 및 서버)과 TCB(TCP control block)을 다른 연결을 위해 사용할 수 있다. 기본적으로 MSL은 120초로 설정되어 있다. 그리고 이 레지스트리 항목의 값은 2MSL, 즉 240초(4분)로 설정되어 있다. 이 값을 변경하면 간격을 조정할 수 있다.

이 항목의 값을 줄이면, TCP는 연결을 더 빨리 해제(release)하고, 할당되어 있던 자원을 새로운 연결을 위해 재사용할 수 있다. 하지만 이 값이 너무 작아지면, 클라이언트와의 연결 해제 작업이 끝나기도 전에 자원을 반환하게 된다. 이 경우, 연결 해제 작업을 계속하기 위해 서버는 또다시 새로운 연결을 할당해야 한다.

보통 TCP는 이 항목에 지정되어 있는 시간이 지나지 않은 경우, 연결을 해제하지도 않고, 그 연결에 사용된 자원을 재사용하지도 않는다. 하지만 시스템이 매우 많은 연결을 받아들여 자원이 바닥날 상황에 이르면, 지정된 시간이 아직 남아있는 경우에도 연결에 할당되어 있는 자원을 해제하게 된다.

Windows 2000은 기본적으로 이 항목을 레지스트리에다 생성하지 않으므로 직접 생성해줘야한다

Run-time String 함수와 kernel String함수의 대응관계