[윤성우의 열혈 TCP/IP 소켓 프로그래밍] Chapter22 - 내용 확인 문제 풀이

 

 

 

 [윤성우의 열혈 TCP / IP 소켓 프로그래밍] 책을 기반으로 개인적으로  문제 풀이 및 개념을 정리한 내용입니다.

모든 소스 코드와 강의, 확인 문제의 정확한 답안은 (23년 7월 1일부터 전면 무료화 예정)

http://www.orentec.co.kr/

====== 오렌지 미디어 ======

에서 확인할 수 있습니다.

 

 

---

 

 

01. Asynchronous(비동기) Notification IO 모델과 Overlapped IO 모델 사이에서 비동기로 처리되는 영역이 어떻게 차이가 나는지 설명해보자.

두 모델은 처리되는 영역에서 차이가 있다.

 

1. Asynchronous Notification IO 모델

- 이 모델에서는 입출력 작업이 완료되면 운영체제가 알림을 전달한다. 이 알림은 주로 이벤트 객체를 통해 이루어진다.

- 프로그래머는 이벤트 객체를 대기 상태로 만들고, 입출력 작업이 완료되면 해당 이벤트를 통해 알림을 받는다.

- 프로그래머는 알림을 받으면 결과를 확인하고 필요한 후속 작업을 진행한다. 이때 다른 스레드에서 작업을 수행하는 것이 일반적이다.

- 비동기로 처리되는 영역은 입출력 작업 완료를 대기하고 결과를 처리하는 부분이다.

 

2. Overlapped 모델

- 이 모델에서는 입출력 작업이 진행되는 동안에도 프로그램은 다른 작업을 수행할 수 있다.

- 입출력 작업은 운영체제에 의해 백드라운드에서 처리되며, 작업이 완료되면 알림을 받을 필요가 없다.

- 프로그래머는 입출력 작업의 시작과 끝을 지정하고, 작업이 완료되면 결과를 확인할 수 있다.

- 비동기로 처리되는 영역은 입출력 작업의 시작과 끝을 지정하는 부분이다.

 

따라서, Asynchronous Notification IO 모델에서는 입출력 작업 완료를 대기하고 결과를 처리하는 이벤트 대기와 후속 작업 수행이 비동기로 처리되는 반면, Overlapped IO 모델에서는 입출력 작업의 시작과 끝을 지정하는 과정이 비동기로 처리된다.

 

모범 답안

Asynchronous Notification IO 모델의 경우 IO 관련 이벤트의 발생을 알리는 과정이 비동기로 처리가 된다.

그러나 Overlapped IO 모델의 경우는 IO가 완료된 상황을 확인하는 과정이 비동기로 처리된다.

 

 

02. 넌-블로킹 IO, 비동기 IO 그리고 Overlapped IO의 관계를 하나의 문장으로 연결해서 설명해보자.

Non-blocking IO와 Overlapped IO는 모두 비동기 입출력 기법이지만, Non-blocking IO는 입출력 작업을 블로킹하지 않고 진행하며 결과를 즉시 반환하고, Overlapped IO는 입출력 작업을 백그라운드에서 비동기적으로 처리하고 완료시 알림을 받아 결과를 확인할 수 있다.

 

모범 답안

비동기 IO는 IO가 완료된 상황을 확인하는 과정이 비동기로 처리됨을 의미한다.

그리고 이러한 유형으로 IO 를 진행하기 위해서는 IO가 넌-블로킹 모드로 동작해야 하며, IO가 넌-블로킹 모드로 동작해서 비동기로 IO를 진행하게 되면, 이를 바탕으로 IO를 중첩시킨 형태인, Overlapped IO가 가능해진다.

 

 

03. 다음 코드의 일부를 보면서 문제점이 있다면 어떠한 문제가 있는지 지적해보자. 그리고 이에 대한 해결책도 함께 제시해보자.

while(1)
{
    hRecvSock=accept(hLisnSock, (SOCKADDR*)&recvAdr, &recvAdrSz);
    evObj = WSACreateEvent();
    memset(&overlapped, 0, sizeof(overlapped));
    overlapped.hEvent = ovObj;
    dataBuf.len=BUF_SIZE;
    dataBuf.buf=buf;
    WSARecv(hRecvSock, &dataBuf, 1, &recvBytes, &flags, &overlapped, NULL);
}

참고로, 위의 코드가 완벽하진 않지만, 이 코드만 가지고도 충분히 발견할 수 있는 구조적인 문제점이 있다.

 

WSARecv 함수호출 시에는 인자로 OVERLAPPED 구조체 변수의 주소 값을 전달하게 되어 있는데,
이 때 한번의 함수 호출당 하나의 OVERLAPPED 구조체 변수가 필요하다.
왜냐하면 WSARecv 함수 내에서 OVERLAPPED 구조체 변수를 활용하기 때문이다.
그래서 제시된 while 반복문은 잘못되었다.
연결요청을 수락한 다음에 이어서 WSARecv 함수를 호출하는데, 
이 때 사용하는 OVERLAPPED 구조체 변수가 모두 동일한 변수이기 때문이다.
결과적으로 하나의 OVERLAPPED 구조체 변수를 이용해서 다수의 WSARecv 함수호출을 진행한 셈이 되었다.
이 문제의 해결을 위해서는 OVERLAPPED 구조체 변수를 동적 할당 하는 방법도 생각해볼 수 있다.

 

 

04. WSASend 함수호출 이후에 IO가 Pending된 상황과 그렇지 않은 상황을 확인하는 방법에 대해서 소스코드 수준에서 설명해보자.

모범 답안
WSASend 함수가 SOCKET_ERROR를 반환한 상태에서, 이어서 WSAGetLastError 함수를 호출했는데
WSA_IO_PENDING을 반환한 경우.

 

 

05. 쓰레드의 alertable wait 상태는 어떠한 상태를 의미하는가? 그리고 쓰레드를 이 상태가 되도록 하는 함수들 중 두 가지만 말해보자.

쓰레드의 alertable wait 상태는 쓰레드가 대기 상태에 있으면서 다른 쓰레드나 시스템에서 해당 쓰레드에 알림을 보낼 수 있는 상태를 의미한다.

이 상태에서는 쓰레드가 대기 중인 동안 일종의 알림 신호를 받을 수 있어 특정 이벤트에 대한 응답이 가능해진다.

 

1. SleepEx

이 함수는 쓰레드를 지정된 시간 동안 대기 상태로 만든다.

SleepEx 함수를 사용할 때 마지막 매개변수로 TRUE를 전달하면 쓰레드가 alertable wait 상태가 된다.

 

2. WaitForSingleObjectEx

이 함수는 특정 개체(이벤트, 뮤텍스 등)의 신호를 기다리는 동안 쓰레드를 대기 상태로 만든다.

WaitForSingleObjectEx 함수를 사용할 때 마지막 매개변수로 TRUE를 전달하면 쓰레드가 alertable wait 상태가 된다.

 

모범 답안

'alertable wait 상태'라는 것은 운영체제가 전달하는 메시지의 수신을 대기하는 상태를 뜻하며,

다음 함수가 호출된 상황에서 쓰레드는 alertable wait 상태가 된다.

- WaitForSingleObjectEx

- WaitForMultipleObjectEx

- WSAWaitForMultipleEvents

- SleepEx 

 

 

 

 

---

출처 : [윤성우의 열혈 TCP / IP 소켓 프로그래밍] / 윤성우 저 / 오렌지 미디어

https://cafe.naver.com/cstudyjava

윤성우의 프로그래밍 스터디그룹 [C/... : 네이버 카페