음... iocp의 동작원리를 다시한번 상기해 보시기 바랍니다.
기본적으로 iocp는 proactor라는 패턴의 성격을 가지고 있습니다.
즉, 어떤 작업에 대한 선요청이 있어야지만 해당 작업을 한다는 것이죠...
reactor와 반대되는 넘입니다.
음... 풀어서 설명해보면...
iocp를 이용해서 네떡 프로그래밍 하실때 절차를 다시함 생각해보죠...
먼저 WSARecv()를 호출해 주죠?
이것은 nt kernel에게
"어이~ NT야... 네떡에서 데이터좀 받아야 쓰겠는데... 데이터 있으면
parameter로 넘기는 버퍼에 복사하구 알려줄래?"
라고 하는 의미이지 대부분의 경우 이 함수 호출즉시 실제 데이터가 수신되지는 않죠?
그러다가 실제로 요청한 세션에 데이터가 들어와 있거나 들어오는 데이터가 있다면...
하위 네떡 레이어의 수신버퍼로부터 유저가 제공한 버퍼로
복사가 일어나게 되고, 이사실을 app에게 알려주기 위해서
Kernel은 Completion Packet을 하나 생성하구 그 넘을 Iocp에 queueing하게 되겠죠...
이때가 되서야 우리는 GetQueuedCompletionStatus()를 통해 그 사실을 알게되어
실제 데이터를 얻게되구요...
음... 맞나요?
즉! 우리가 application에서 WSARecv()같은 함수를 통해서 명시적으로
operation을 posting해주지 않는다면 절대로 completion이 일어나지
않습니다. 즉, 님께서 만든 application에서 이전에 받은 데이터를 처리하고
다음 데이터를 받기위해 WSARecv()를 호출해 주지 않는 이상은
completion이 일어나지 않는다는 것이 되기때문에 iocp의 queue가 overflow되는
경우는 발생할 수 없겠죠.
음... 근데 여담으루 이런 경우는 있을 수 있겠네요...
recv posting을 엄청 많이... 그러니깐 completion을 받건 말건 걍 무쟈게 많이
미리 해버리는 경우...
메모리 바닥날때까지 해버린다면... 맛이 갈 수는 있겠네요... ^_^;
아마도 ERROR_INSUFFICIENT_RESOURCES 에러가 나겠죠?
더구나 recv나 send를 해서 소켓 operation이 kernel로 넘어가서 pending상태가 되면
이넘들은 kernel에서 접근하기때문에 pageable메모리에 있으면 안되거든요.
반드시 locking이 가능한 physical memory에 올라와야 하죠...
근데 이 lockable 메모리의 사이즈는 그다지 크기 않기땜에 생각보다 빨리
메모리가 바닥날 수 있겠네요...
근데 일반적인 경우에 이렇게 할 일은 별로 없겠죠? ^_^;
음... 이번에는 좀더 원론적인 부분에서 생각을 해보죠...
자 우리가 사용하는 socket 프로그램의 하위엔 TCP stack이라고 하는 넘이
있습니다. 즉, 우리 일반 application프로그래머들은 신경쓰지 않아도 되는
수많은 TCP/IP protocol의 처리들을 구현해 놓은 녀석들이죠...
sliding window protocol이란 녀석을 들어보셨으리라 생각합니다.
TCP/IP 에서 Flow control을 담당하는 녀석이죠... 즉, 위에서 언급한
iocp메커니즘 관련된 것은 제외하고라도, 이넘이 관계하는
incoming/outgoing buffer가 있습니다. 들어오고 나가는 데이터를 버퍼링 하는
것이죠... 즉, 상대측에서 아무리 데이터를 날리고 싶어도 내 컴터의 app에서
어떤 불가피한 상황에 의해 데이터 받는 즉시즉시 데이터를 빼내가지 않아서
수신버퍼에 데이터가 꽉 차있는 상태라면 상대측에선 어떤 데이터도 날릴 수 없는 것이죠...
아무리 송신측에서 Send를 해도 수신측의 버퍼에 여유가 없다면 송신측은 계속
outstanding상태에 있게 된답니다.
즉, posting된 recv가 없는 상태라면 비록 네떡 수신 버퍼는 꽉꽉차있어도
iocp로부터의 completion은 발생하지 않게 됩니다.
당연하겠죠... 요청한 작업이 없는데도 nt가 알아서 completion packet을
저절로 만드는 일은 결코 없을테니까요.
분명한 사실은 iocp라는 넘의 정체는 소켓, 혹은 네떡 프로그래밍만을 위해 존재하는 녀석은
아닙니다.
말 그대로 컴터에서 일어나는 I/O 작업의 completion을 application에서 인지할 수 있게
해주고, 또한 i/o 작업시에 일어날 수 있는 app의 performance저하를 최대한
피할 수 있도록 능동적인 thread pooling의 기능을 제공하는 하나의 커널객체 입니다.
그 이상도 이하도 아니지요...
즉, 이넘을 네떡에도 쓸 수 있고, 화일처리에도 사용할 수 있습니다.
물론 그밖의 핸들을 사용하는 i/o 작업이면 어디에도 가능한 것이죠...
기본적으로 iocp는 proactor라는 패턴의 성격을 가지고 있습니다.
즉, 어떤 작업에 대한 선요청이 있어야지만 해당 작업을 한다는 것이죠...
reactor와 반대되는 넘입니다.
음... 풀어서 설명해보면...
iocp를 이용해서 네떡 프로그래밍 하실때 절차를 다시함 생각해보죠...
먼저 WSARecv()를 호출해 주죠?
이것은 nt kernel에게
"어이~ NT야... 네떡에서 데이터좀 받아야 쓰겠는데... 데이터 있으면
parameter로 넘기는 버퍼에 복사하구 알려줄래?"
라고 하는 의미이지 대부분의 경우 이 함수 호출즉시 실제 데이터가 수신되지는 않죠?
그러다가 실제로 요청한 세션에 데이터가 들어와 있거나 들어오는 데이터가 있다면...
하위 네떡 레이어의 수신버퍼로부터 유저가 제공한 버퍼로
복사가 일어나게 되고, 이사실을 app에게 알려주기 위해서
Kernel은 Completion Packet을 하나 생성하구 그 넘을 Iocp에 queueing하게 되겠죠...
이때가 되서야 우리는 GetQueuedCompletionStatus()를 통해 그 사실을 알게되어
실제 데이터를 얻게되구요...
음... 맞나요?
즉! 우리가 application에서 WSARecv()같은 함수를 통해서 명시적으로
operation을 posting해주지 않는다면 절대로 completion이 일어나지
않습니다. 즉, 님께서 만든 application에서 이전에 받은 데이터를 처리하고
다음 데이터를 받기위해 WSARecv()를 호출해 주지 않는 이상은
completion이 일어나지 않는다는 것이 되기때문에 iocp의 queue가 overflow되는
경우는 발생할 수 없겠죠.
음... 근데 여담으루 이런 경우는 있을 수 있겠네요...
recv posting을 엄청 많이... 그러니깐 completion을 받건 말건 걍 무쟈게 많이
미리 해버리는 경우...
메모리 바닥날때까지 해버린다면... 맛이 갈 수는 있겠네요... ^_^;
아마도 ERROR_INSUFFICIENT_RESOURCES 에러가 나겠죠?
더구나 recv나 send를 해서 소켓 operation이 kernel로 넘어가서 pending상태가 되면
이넘들은 kernel에서 접근하기때문에 pageable메모리에 있으면 안되거든요.
반드시 locking이 가능한 physical memory에 올라와야 하죠...
근데 이 lockable 메모리의 사이즈는 그다지 크기 않기땜에 생각보다 빨리
메모리가 바닥날 수 있겠네요...
근데 일반적인 경우에 이렇게 할 일은 별로 없겠죠? ^_^;
음... 이번에는 좀더 원론적인 부분에서 생각을 해보죠...
자 우리가 사용하는 socket 프로그램의 하위엔 TCP stack이라고 하는 넘이
있습니다. 즉, 우리 일반 application프로그래머들은 신경쓰지 않아도 되는
수많은 TCP/IP protocol의 처리들을 구현해 놓은 녀석들이죠...
sliding window protocol이란 녀석을 들어보셨으리라 생각합니다.
TCP/IP 에서 Flow control을 담당하는 녀석이죠... 즉, 위에서 언급한
iocp메커니즘 관련된 것은 제외하고라도, 이넘이 관계하는
incoming/outgoing buffer가 있습니다. 들어오고 나가는 데이터를 버퍼링 하는
것이죠... 즉, 상대측에서 아무리 데이터를 날리고 싶어도 내 컴터의 app에서
어떤 불가피한 상황에 의해 데이터 받는 즉시즉시 데이터를 빼내가지 않아서
수신버퍼에 데이터가 꽉 차있는 상태라면 상대측에선 어떤 데이터도 날릴 수 없는 것이죠...
아무리 송신측에서 Send를 해도 수신측의 버퍼에 여유가 없다면 송신측은 계속
outstanding상태에 있게 된답니다.
즉, posting된 recv가 없는 상태라면 비록 네떡 수신 버퍼는 꽉꽉차있어도
iocp로부터의 completion은 발생하지 않게 됩니다.
당연하겠죠... 요청한 작업이 없는데도 nt가 알아서 completion packet을
저절로 만드는 일은 결코 없을테니까요.
분명한 사실은 iocp라는 넘의 정체는 소켓, 혹은 네떡 프로그래밍만을 위해 존재하는 녀석은
아닙니다.
말 그대로 컴터에서 일어나는 I/O 작업의 completion을 application에서 인지할 수 있게
해주고, 또한 i/o 작업시에 일어날 수 있는 app의 performance저하를 최대한
피할 수 있도록 능동적인 thread pooling의 기능을 제공하는 하나의 커널객체 입니다.
그 이상도 이하도 아니지요...
즉, 이넘을 네떡에도 쓸 수 있고, 화일처리에도 사용할 수 있습니다.
물론 그밖의 핸들을 사용하는 i/o 작업이면 어디에도 가능한 것이죠...
