라이언(Ryan)의 블로그

※ 일반적인 쓰레드기반 다중 서버...

서버쪽 쓰레드 하나가 하나의 소켓을 전담한다.

서버쪽 쓰레드가 계속해서 일하는 것이기 아니기 때문에 소켓과 쓰레드가 1:1 대응되는 것은 서버에 부담이 된다. 

1. 리소스 부담... 

2. context switching이 빈번하게 발생하기 때문...

※ 소켓의 수는 줄일 수 없다.

하지만, 하나의 쓰레드가 3개의 소켓을 한꺼번에 담당한다면 리소스 부담 감소, context switching 감소...

22-1. Completion Port 입출력 기본 원리

IOCP란?

1. 기본적으로 비동기 입출력 모델이다. Overlapped IO

2. 제한된 쓰레드의 수를 통해서 여러 소켓의 입출력을 담당하게 한다.

3. 컨텍스트 스위칭에 소비되는 시간을 줄이는 모델이다.

4. Overlapped 입출력 모델의 특징과 비동기 Notification 입출력 모델의 특징을 동시에 지닌다.

원래 비동기 Notification 입출력 모델 : 먼저 확인 후 그 다음 입출력한다.

IOCP모델 : 먼저 입출력 한 후 확인을 나중에 한다.

IOCP 구현모델

Completion Port 내부에 큐가 생성된다. 

연결된 소켓이 입출력이 완료되면 Completion Packet을 만든다.

Completion Packet에는 입출력이 완료한 소켓 정보등에 대한 데이터 묶음이다.

이 packet을 Completion Queue에 집어 넣는다.

쓰레드는 큐에서 packet을 꺼내 내용을 처리한다.

IOCP에서 적절한 쓰레드의 수

Response Session : 서버가 클라이언트로 온 요청을 처리하고 전송하기 직전까지 준비과정.

Response Session이 짧은 경우(간단한 연산 결과를 돌려줌) : CPU의 개수를 초과하지 않는다.

Response Session이 긴 경우 : CPU의 개수를 적절히 초과하여 클라이언트의 평균 만족도를 높인다.

※ 실험적으로 판단하여 평가해야 한다.

일반적인 경우 : CPU의 개수를 초과하지 않는다.

22-2. Completion Port 입출력을 위한 기본 단계

1. Completion Port 오브젝트의 생성

HANDLE CreateIoCompletionPort(

HANDLE FileHandle, // 연결 시킬 소켓 핸들

HANDLE ExistingCompletionPort, // 연결시킬 completion port 핸들

ULONG_PTR CompletionKey, // completion key

DWORD NumberOfConcurrentThreads // 동시 실행 가능한 쓰레드의 수

);

실행예)

HANDLE hCompletionPort = CreateIoCompletionPort(INVALID_HANDLE_VALUE, NULL, 0, 0);

※ NumberOfConcurrentThreads가 0이면 CPU의 수만큼 허용

2. Completion Port 오브젝트와 소켓의 연결

completionKey : 입출력이 완료되었을 때 Completion Packet에 저장하는 추가적인 데이터

실행예)

CreateIoCompletionPort(소켓핸들, hCompletionPort, (DWORD)PerHandleData, 0);

3. Completion Queue에 들어 있는 패킷 정보 확인

BOOL GetQueuedCompletionStatus(

HANDLE CompletionPort,  // completion port 핸들

LPDWORD lpNumberOfBytes, // 전송된 바이트수

PULONG_PTR lpCompletionKey, // file completion key

LPOVERLAPPED *lpOverlapped, // buffer

DWORD dwMilliseconds // 선택적인 timeout 값

);

2,3,4 인자를 통해 completion packet의 내용을 얻어온다.

22-3 Completion Port 입출력 기반의 서버구현

CreateCompletionPort의 키 : 완료된 소켓의 정보

Completion Port : 완료감지, completion packet 생성 : key, overlapped, 전송 바이트 수로 구성.

WSARecv의 6번째 인자인 LPWSAOVERLAPPED에서 hEvent를 이용한다. ->

수신된 데이터가 존재하는 버퍼 정보를 담음. overlapped 구조체 뿐만 아니라 다른 구조체도 추가 가능. 

21-1. Overlapped 입출력의 의미

비중첩 데이터 입출력 모델

중첩된 데이터 입출력 모델

하나의 쓰레드 내에서 여러 개의 입출력이 진행되는 것

21-2. Overlapped 입출력을 위한 기본 단계

1. Overlapped 소켓의 생성

SOCKET WSASocket(

  __in  int af,

  __in  int type,

  __in  int protocol,

  __in  LPWSAPROTOCOL_INFO lpProtocolInfo,

  __in  GROUP g,

  __in  DWORD dwFlags

);

af : address family

type : 소켓 형태

protocol : 사용된 프로토콜(여기까지 socket과 동일)

lpProtocolInfo : 생성될 소켓의 성경을 정의하는 wSAPROTOCOL_INFO 포인터

g : 예약됨.

dwFlags : 소켓 속성을 지정하는 플래그

WSASocket(PF_INET, SOCK_STREAM, 0, NULL, 0, WSA_FLAG_OVERLAPPED);

WSA_FLAG_OVERLAPPED는 Overlapped 입출력이 가능하도록 하는 플래그.

2. 데이터 송수신

※ 다음 함수들은 버퍼에 존재하는 데이터를 모아서 한 번에 전송하고(Gather) 수신된 데이터를 여러 버퍼에 나누어 저장(Scatter)하는 Gather/Scatter 입출력을 한다.

int WSASend(

    SOCKET s,                  // 소켓 핸들

    LPWSABUF lpBuffers,    // WSABUF 구조체 배열의 포인터

    DWORD dwBufferCount, // lpBuffers가 가리키는 배열의 크기

    LPDWORD lpNumberOfBytesSent, // 전송된 바이트 수를 저장하기 위한 포인터

    DWORD dwFlags,

    LPWSAOVERLAPPED lpOverlapped,

    LPWSAOVERLAPPED_COMPLETION_ROUTING lpCompletionRoutine

);

리턴 : 성공시 0, 실패시 SOCKET_ERROR

typedef struct __WSABUF{

    u_long len;

    char FAR *buf;

}WSABUF, FAR* LPWSABUF;

int WSARecv(

    SOCKET s,                  // 소켓 핸들

    LPWSABUF lpBuffers,    // 수신 버퍼 정보를 지니는WSABUF 구조체 배열의 포인터

    DWORD dwBufferCount, // lpBuffers가 가리키는 배열의 크기

    LPDWORD lpNumberOfBytesRecvd, // 전송된 바이트 수를 저장하기 위한 포인터

    DWORD dwFlags,

    LPWSAOVERLAPPED lpOverlapped,

    LPWSAOVERLAPPED_COMPLETION_ROUTING lpCompletionRoutine

);

리턴 : 성공시 0, 실패시 SOCKET_ERROR

lpOverlapped : 중첩된 입출력을 하기 위해 사용.

3. 데이터 송수신 완료 확인

이벤트 커널 오브젝트 기반

CALLBACK 함수 기반

1. 비동기 Notification의 의미

동기화된 입력 및 출력 함수의 호출

동기화 : 함수의 호출과 행위의 시작, 함수의 리턴과 행위의 종료가 일치함.

데이터 전송 종료 :  Application -> TCP계층으로 데이터를 다 보낸 상황. send함수를 호출하면 출력버퍼로 보내고자 하는 데이터가 다 들어갔을 때의 상황. 

데이터 수신 종료 : TCP -> Application으로 데이터를 다 읽은 상황.

동기화된 데이터 입출력 과정상의 문제점

※ Host B의 버퍼가 꽉 찼을 경우에 (패킷 전송 일시 정지 요청에 의해) Host A는 패킷 전송을 하지 않고 blocking상태에 있게 된다.

※ send함수에서 패킷을 다 보냈을 경우 send함수가 리턴되어 종료된다.

비동기화 Notification

동기화 Notification

1. select 함수를 기반으로 한 서버의 구현

2. 핸들에 변화가 발생해야 리턴한다. select 함수의 리턴 시기와 핸들 변화 시기가 일치(동기)

비동기화 Notification

1. WSAEventSelect 함수를 기반으로 한 서버의 구현

2. 함수의 호출과 동시에 리턴한다. 따라서 핸들의 변화를 확인하기 위한 별도의 과정이 필요하다.

20.2 WSAEventSelect 모델 기반 서버 구현을 위한 API

구현순서

※ 소켓과 소켓을 위한 Event Object(소켓의 상태를 반영)가 쌍을 이룬다. 소켓의 변화가 다양하기 때문에 Event 객체가 따로 필요하다.

1. WSACreateEvent : Event를 편하게 이용할 수 있도록 돕는다.

2. WSAEventSelect

select함수 : 관심을 두고자 하는 핸들을 설정(설정) + 소켓의 변화(알림), 동기화 알림 함수.

WSAEventSelect : 관심을 두고자 하는 하나의 핸들을 설정만 할 수 있음.

3. WSAWaitForMultipleEvents : 소켓의 변화를 확인. nonsignaled에서 signaled로 변화할 때 리턴됨.

4. WSAEnumNetworkEvents : 소켓이 변화된 이유를 확인.

필요한 함수

WSAEVENT WSACreateEvent(void);

리턴 : manual-reset 모드, non-signaled 상태의 이벤트

int WSAEventSelect(

    SOCKET s,                       // 감시 대상이 되는 소켓

    WSAEVENT hEventObject, // 소켓의 변화를 확인하기 위한 이벤트 오브젝트의 핸들.

    long lNetowrkEvents         // 감시하고자 하는 이벤트 종류를 Bit-wise OR(|)로 묶어서 전달

);

리턴 : 성공시 0, 실패시 SOCKET_ERROR

감시하고자 하는 이벤트 종류

DWORD WSAWaitForMultipleEvents(

    DWORD cEvents,                           // 검사 대상의 핸들 수     

    const WSAEVENT FAR *lphEvents, // 검사 대상의 배열

    BOOL fWaitAll,                              // FALSE일 경우 하나의 배열만 변화가 있어도 리턴. TRUE면 모든 배열의 변화가 있어야 함.

    DWORD dwTimeout,                     // 타임아웃.

    BOOL fAlertable

);

여러 개의 이벤트 핸들(포인터로 배열 전달)이 signaled 상태가 되었는지 감시하는 함수.

리턴 : 실패시 WAIT_FAILED 리턴, 성공시 이벤트 발생 오브젝트 정보 리턴

int WSAEnumNetworkEvents(

    SOCKET s,                                                   // 소켓

    WSAEVENT hEventObject,                             // 이벤트가 발생한 소켓과 연결되어 있는 이벤트 오브젝트 핸들

    LPWSANETWORKEVENTS lpNetworkEvents    // 발생한 이벤트 정보와 오류 정보로 채워진 WSANETWORKEVENTS 구조체 포인터

);

이벤트 핸들이 발생한 이유를 알아내는 데 사용한다. signaled 상태의 이벤트 핸들을 nonsignaled상태로 바꿔주는 기능도 수행한다.

리턴 : 성공시 0, 실패시 SOCKET_ERROR 리턴

발생한 이벤트 정보와 오류 정보로 채워진 WSANETWORKEVENTS 구조체

typedef struct _WSANETWORKEVENTS{

    long lNetworkEvents;

    int    iErrorCode[FD_MAX_EVENTS];

} WSANETWORKEVENTS, *LPWSANETWORKEVENTS;

※ bind와 listen 사이의 소켓에 대해 이벤트를 만든다.

index = WSAWaitForMultipleEvents(sockTotal, hEventArray, FALSE, WSA_INFINITE, FALSE);

index = index - WSA_WAIT_EVENT_0;

여러 개의 소켓에서 변화가 일어났는 지 확인하고 소켓의 index값을 얻는다. 리턴된 index값은 가장 작은 소켓 인덱스 값이다. 

변화가 일어난 소켓이 여러개일 수 있기 때문에 각각을 for문을 통해 확인한다.

18-1 커널 오브젝트(Kernel Objects)

커널 오브젝트 

시스템 리소스의 정보를 담고 있는 데이터 블록(윈도우즈 기반에서만)

시스템(운영체제)이 관리한다.

18-2. 윈도우즈 기반의 쓰레드 생성

#include<process.h>

unsigned long _beginthreadex(

    void *security,

    unsigned stack_size,

    unsigned (*start_address)(void*),

    void *arglist,

    unsigned initflag,

    unsigned *thrdaddr

);

security : 보안에 관련된 설정

stack_size : 쓰레드 생성시 요구되는 스택의 크기. 0이면 default

start_address : 쓰레드에 의해 호출되는 함수의 포인터

arglist : start_address가 가리키는 함수 호출시, 전달할 인자를 지정해 준다.

initflag : 바로 실행상태(0)가 되느냐, 아니면 대기 상태로 들어가느냐 결정하는 요소. 

thrdaddr : 쓰레드 생성시 쓰레드 ID

쓰레드 생성을 위한 라이브러리 설정

※ 윈도우즈도 main thread가 먼저 끝나면 다른 thread들이 실행중이라도 프로그램이 종료가 된다.

※ 윈도우즈는 기본 실행 단위가 thread다. 프로그램을 만들면 main thread(main함수 실행하는 용도)가 생성된다.

커널 오브젝트, 리소스, 핸들과의 관계

※ 프로그램은 파일을 직접 조작하는 것이 아니라 커널 오브젝트에게 원하는 조작을 요청하고 시스템이 파일을 조작하게 된다.

18-3. Signaled & Non-Signaled 커널 오브젝트

커널 오브젝트의 상태

쓰레드 커널 오브젝트의 상태

생성시 : non-signaled 상태로 초기화.

종료시 : signaled 상태로 변경.

커널 오브젝트 상태 확인 함수

#include<windows.h>

DWORD WaitForSingleObject(HANDLE hHandle, DWORD dwMilliseconds);

리턴 : signaled 상태가 되어 리턴하는 경우 WAIT_OBJECT_0, 타임아웃에서 리턴될 경우 WAIT_TIMEOUT. 오류시 WAIT_FAILED.

hHandle : 상태를 확인할 커널 오브젝트의 핸들을 전달.

dwMilliseconds : 타임아웃을 1/1000초 단위로 설정한다. INFINITE를 전달할 경우 signaled 상태가 되기 전에 절대 리턴하지 않는다.

※ signaled 상태가 될 때까지 main thread가 기다려주면 된다. 리눅스의 JOIN과 비슷한 효과.

커널 오브젝트의 종류

auto-reset mode 커널 오브젝트 : 리턴이 되면서 커널 오브젝트가 non-signaled 상태가 됨.

manual-reset mode 커널 오브젝트 : 리턴이 되어도 커널 오브젝트는 자동으로 상태가 변경되지 않음.

16-1. 스트림의 분리

입출력 스트림의 분리 

입력을 위한 파일포인터와 출력을 위한 파일 포인터를 독립적으로 유지.

스트림을 분리하는 이유

프로그래밍을 단순하게 한다.

입출력 겸용 스트림의 경우 입출력 작업 전환시 버퍼를 비워야 한다.

일반적인 프로그래밍 방식.

주의할 사항

출력 스트림 종료시 EOF 전송이 된다.

문제점 : fclose함수를 통해 출력 스트림 뿐만 아니라 입력 스트림까지 완전 종료가 발생할 수 있다.

발생 상황 : 디스크립터가 하나고 그걸 통해 입출력(2개)용 FILE포인터를 만들 때 발생.

16-2. 파일 디스트립터의 복사와 스트림의 분리

파일 포인터(FILE*)를 이용한 소켓의 종료과정

fclose 함수의 호출은 파일 디스크립터의 종료로 이어지고, 이는 소켓의 완전종료를 의미한다.

※ 하나의 파일 디스크립터를 기반으로 입출력 파일 포인터 생성시 하나의 파일 포인터만 종료되어도 완전 종료된다.

※ 시스템 리소스(여기서는 소켓)는 가리키는 포인터(여기서는 파일 디스크립터)가 없을 때 종료된다.

하나의 파일 디스크립터를 기반으로 하나의 파일포인터만 생성

파일 디스크립터가 두 개일 경우에는 두 개의 파일 디스크립터가 종료되어야 완전 종료된다.

파일 디스크립터 복사

하나의 파일(혹은 소켓)에 접근할 수 있는 파일 디스크립터를 하나 더 만들어 내는 것.

#include<unistd.h>

int dup(int fildes);

int dup2(int fildes, int fildes2);

리턴 : 성공시 복사된 파일 디스크립터(번호), 실패시 -1

fildes : 복사하고자 원하는 파일 디스크립터

fildes2 : 복사되는 파일 디스크립터의 값을 명시적으로 지정하고 싶을 때 사용.

15-1. 표준 입출력 함수의 장점

표준 입출력 함수의 장점

이식성이 좋아진다.

 - 모든 시스템은 ANSI 표준 C를 지원한다.

효율성을 높일 수 있다.

 - 표준 입출력 함수에 의한 버퍼를 제공받는다. (표준 입출력버퍼, 소켓 버퍼)

 - 소켓 생성 버퍼 목적 :  프로토콜의 완성을 위한 것.

 - 표준 입출력 버퍼 목적 : 성능 향상

파일 포인터와 파일 디스크립터

파일 포인터

 - 표준 입출력 함수 호출을 위해서 필요한 파일 포인터. = FILE 구조체의 포인터.

파일 디스크립터를 이용한 시스템 입출력

 - 시스템 입출력 함수 사용 시 필요

 - 정수값이다.

※ 소켓 기반의 표준 입출력 함수 사용을 위해 파일 디스크립터를 기반으로 파일 포인터를 생성.

15-2. 표준 입출력 함수의 사용

파일 디스크립터 -> 파일 포인터

#include<stdio.h>

FILE * fdopen(int files, const char *mode);

리턴 : 성공시 FILE 포인터, 실패시 NULL

fdopen 후 파일 디스크립터와 파일 포인터 상태

※ 표준 입출력 함수를 사용할 경우 : 파일 버퍼 -> 소켓 버퍼 -> 실제 전송 혹은 수신.

파일 포인터 -> 파일 디스크립터

#include<stdio.h>

int fileno(FILE *stream);

리턴 : 파일 포인터가 가리키는 파일의 디스크립터 리턴.

stream : 파일 포인터. 파일 디스크립터는 파일 모드와는 상관이 없다.

15-3. 소켓 기반의 표준 입출력 함수의 사용

파일에 버퍼가 필요한 이유

CPU가 직접 I/O를 하면 비효율적이기 때문에 버퍼에 그 내용을 저장했다가 파일로 전송한다.

flag를 두어 CPU가 여유 있을 때 system call을 통해 버퍼 내용을 파일로 보낸다.

system call을 이용하면 모아서 입출력 하는 것이 힘들다.

하지만 파일 버퍼를 이용하면 데이터를 모아서 입출력하는 데 좋아진다.

유선 : 고객에게 서비스를 제공. 멀티캐스트 방식(가입이 필요)

안테나 방송 : 서비스를 지정된 채널로 제공. 브로드캐스트 방식(가입 필요 없음)

14-1. 멀티캐스트(Multicast)

멀티캐스트 전송 방식.

UDP를 기반으로 하는 전송 방식. 

멀티캐스트 그룹(클래스 D에 속하는 IP주소)을 기반으로 멀티캐스트 패킷을 주고 받음.

하나의 멀티캐스트 패킷은 라우터를 통해서 다수의 호스트에 전송.

(한 번만 방송하면 가입자 모두 시청 가능.)

(정보를 단방향으로 제공할 때 주로 사용.)

라우팅(Routing)과 TTL(Time To Live)

라우팅 : 라우터에 의해서 패킷이 경로를 찾는 과정

TTL 

거쳐갈 수 있는 라우터의 수(홉)를 의미. 

이 값이 0이 되면 패킷은 더 이상 전달되지 못하고 소멸된다.

멀티캐스트 Sender와 Receiver

Sender : 멀티캐스트 그룹에 데이터를 전송하는 호스트

Receiver : 멀티캐스트 그룹으로부터 데이터를 수신하는 호스트

※ Sender는 서버(제공자), Receiver는 클라이언트로 구분 지을 수 있지만 요청하는 부분과는 관련이 적다.

멀티캐스트 Sender와 Receiver

Sender TTL 설정

state = setsockopt(send_sock, IPPROTO_IP, IP_MULTICAST_TTL, (void*)&multi_TTL, sizeof(multi_TTL));

Receiver 멀티캐스트 그룹 지정.

struct ip_mreq

{

    struct in_addr imr_multiaddr;    // 가입하고자 원하는 D 클래스 ip주소

    struct in_addr imr_interface;     // 나의 ip 주소. htonl(IN_ADDR);을 써주면 된다.

};

※ 서로 포트는 일치 해야 한다.

14-2. 브로드캐스트(Broadcast)

브로드캐스트 전송방식

UDP를 기반으로 하는 전송 방식(=멀티캐스트와 같다.)

일반적으로 UDP 패킷과의 차이점은 전송 목적지 ip주소 뿐이다.

(멀티캐스트와의 차이점)

동일 네트워크에 속하는 모든 호스트에 동시 전송

인터넷 상에서 지역 네트워크 내에서만 브로드캐스를 허용한다. (네트워크 부하를 고려)

주소선택에 따른 브로드캐스트 방식 구분

지정된 브로드캐스트

예 : 192.12.31.255 -> 자신이 속한 IP주소만 설정 가능. (지역적 브로드캐스트를 더 많이 사용.)

지역적 브로드캐스트 

예 : 255.255.255.255 -> 알아서 현재 네트워크(LAN)에 브로드캐스트.

13-1. recv & send 입출력 함수

read & write 함수와 달리 데이터 입출력 방법에 있어서 옵션 부여.

#include<sys/types.h>

#include<sys/socket.h>

int recv(int sock, void *buf, int len, unsigned int flags);

int send(int sock, const void * buf, int len, unsigned int flags);

옵션의 종류와 의미

 - MSG_DONTROUTE (send 함수 호출시에만 사용하는 옵션)

    데이터 전송 시 라우팅 테이블(라우터에 있음)을 참조하지 않음.

    => Local network 내에서만 패킷을 전송하겠다는 뜻.

 - MSG_DONTWAIT (send, recv 함수 모두에 사용하는 옵션)

    not blocking 입출력 기능

 - MSG_OOB (send, recv 함수 모두에 사용하는 옵션)

    데이터 전송 시, 긴급 데이터(Out-of-band data) 전송

    ※ Out-of-band : 도로 상의 갓길을 생각하면 좋음.

 - MSG_PEEK (recv 함수 호출시에만 사용하는 옵션)

    버퍼에 데이터 유무 확인.

긴급한 데이터의 전송

전송 프로그램 예시

write(sock, "123", 3);

send(sock, "4", 1, MSG_OOB);

write(sock, "567", 3);

send(sock, "890", 3, MSG_OOB);

수신 프로그램 예시

① fcntl(send_sock, F_SETOWN, getpid());

파일 디스크립터를 제어하는 함수.

send_sock : 소켓의 파일 디스크립터

F_SETOWN 소유자를 설정.

getpid(); : 현재 프로세스의 ID

② state = sigaction(SIGURG, &act, 0);

SIGURG : 긴급 데이터(out-of-band)를 받을 때 발생하는 시그널.

긴급 데이터 전송 시 생성되는 패킷

recv함수를 호출할 때 urgent point-1 위치부터 1바이트만 읽어들인다.

긴급 데이터 전송의 특징

- 버퍼 상황에 관계 없이 데이터 전송 ( 버퍼가 비어지길 기다리지 않고 바로 전송)

- Nagle 알고리즘 무시

입력버퍼 검사하기

sleep 함수 사용 이유 : 패킷을 온전히 다 받기 위해 사용.

MSG_PEEK : 메세지를 읽어도 소켓의 수신 버퍼에 데이터 내용을 지우지 않는다.

MSG_DONTWAIT : 버퍼가 비어 있지 않아도 바로 리턴 받기 위해서...

※ 두 개의 옵션을 같이 사용한다.

13-2. readv & writev 입출력 함수

데이터를 모아서 전송(writev) : 한 번 호출하여 한 번에 보낸다.

#include<sys/io.h>

int writev(int fd, const struct iovec *vector, int count);

리턴 : 성공시 전송한 바이트 수, 실패시 -1

데이터 여러 개(count개)를 모아서 전송한다.

fd : 데이터 전송의 목적지를 나타내는 소켓의 파일 디스크립터

vector : iovec 구조체 이름을 인자로 전달. 전송하고자 하는 데이터에 대한 정보가 담겨진다. 

count : iovec 구조체 변수의 개수.

데이터를 분산 수신(readv) : 한번 호출하여 나누어진 버퍼에 저장한다.

#include<sys/io.h>

int readv(int fd, const struct iovec *vector, int count);

리턴 : 성공시 수신한 바이트 수, 실패시 -1

fd : 데이터를 수신할 파일 디스크립터

vector : iovec 구조체 이름을 인자로 전달. 어디에 얼마칸큼 데이터를 수신할 것인지 정보를 전달.

count : iovec 구조체 변수의 개수.

배열을 정의하기 위한 구조체의 선언

struct iovec{

    ptr_t iov_base;    // 보내고자 하는 데이터의 시작주소

    size_t iov_len;    // 보내고자 하는 데이터의 크기

};

readv&writev 함수의 적절한 사용

1. 함수호출 회수가 적으면 효율적임.

2. nagle알고리즘을 적용하지 않는 경우 다음과 같은 장점을 가진다.

일반 write 3번 호출 : 3개의 패킷을 생성하여 전송

nagle알고리즘을 적용한 경우

writev 호출 : 1개의 패킷을 생성하여 전송.

3. 큰 배열을 생성하여 하드코딩해서 보내는 것보다 한번의 함수로 모아서 보내는 게 편리하다.

13-3. 윈도우즈 기반으로 구현하기

윈도우즈 기반 OOB 데이터 송수신

1. 윈도우즈 기반에서는 'signal 핸들링' 이라는 개념이 존재하지 않는다.

2. select 함수는 소켓을 통해서 예외 상황(OOB 데이터 수신)이 발생하였는지 확인 가능하다.

예시)

FD_ZERO(&except);

FD_SET(hSendSock,&except);

exceptCopy = except;

select(?, ?, ?, &exceptCopy, ?);