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함수의 대응관계

Name Mangling

프로그램에서 함수를 선언하거나 전역 변수 등을 선언 했을 때, 실제 생성되는 함수는 컴파일 단계에서 일정한 규칙을 가지고 변경되는데, 이를 네임 맹글링(Name Mangling)혹은 네임 데커레에션(Name Decoration)이라 부른다.

이러한 작업은 Linker가 다른 Scope에 있는 같은 이름의 함수와 변수에 대해 구별할 수 있도록 하는 요소이므로, Compiler 입장에서는 중요한 작업이다.

일반적으로 Compiler 는 함수에 대해서 그 함수의 이름과 함수의 파라미터 타입 그리고 Calling Convention등을 사용하여 그 이름을 만들어 내게 된다.

이러한 네임 맹글링은 컴파일러 마다 다른 규칙을 가지게 된다.

외부라이브러리를 링크하여 컴파일 할때 선언부만 포함하고 실 라이브러리를 포함하지 않으면 발생하는 에러에서 간혹 보게 되는 ?TestFunc1@@YAXHPAH@Z와 같은 형태의 함수이름이 네임 맹글링된 함수의 이름이다.

* C++로 작성되는 프로그램에서 함수 앞에 붙이는 extern "C" 선언은 함수를 컴파일 할 때, 네임 맹글링을 하지 않고 함수이름만으로 네이밍 하도록 한다(즉 C type으로 함수명을 네이밍하게 된다).

아래의 예에서 extern "C"를 기술했을 경우와, 그렇지 않은 경우의 차이를 확인 할 수 있다.

 

 extern "C" __declspec(dllexport) void TestFunc( int x);

__declspec(dllexport) void TestFunc( int x);

(이 유틸리티는 Visual Studio 설치폴더 C:\Program Files\Microsoft Visual Studio x.x\VC\bin 에서 찾을 수 있으며, 파일로 첨부한다.)

undname.zip

 

위에서 생성된 함수를 UNDNAME.exe를 이용해 데코레이션을 제거하면 예상대로 아래와 같이 표시된다.

* 이러한 이유 때문에 정적으로 링크하여 사용할 것이 아니라면
   - 즉,
   - LoadLibrary(), GetProcAddress()의 절차를 통해 함수포인터를 얻어 사용하거나,
   - 다른 언어로 작성된 Application에서 Dll을 로드하여 사용
할 용도의 Dll이라면 export되는 함수에 대해 함수의 export선언부에 extern "C"를 붙여주거나 .def파일을 이용해서 네임맹글링이 적용되지 않도록 하여야 한다.