라이언(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 함수 기반

Generic(제너릭)

사전적 정의 : 일반적인, 포괄적인, 통칭의, 범용

screwdriver set as a generic tool

※ (드라이버 꼭지)를 바꿈으로서 다양하게 사용할 수 있다.

※ Professional .NET 2.0 Generics이라는 책이 존재할 정도로 방대한 분야.

장점

Type checking, boxing, casting 등의 작업 불필요 => 성능 향상

사용 용도

Custom List, Collection 등을 쉽게 구현

object List 정의

public class List

{

    private object[] elements;

    private int count;

    public void Add(object element){ ... }

    public object this[int index]{ get... set... }

    public int Count { get... }

}

object List 사용 예시

List intList = new List();

intList.Add(1);           // boxing 실행됨.

intList.Add(2);

intList.Add("Three");  // 이후에 Runtime시 잠재적 에러 가능성. (배열 형태기 때문에)

int i = (int)intList[0];   // 형 변환 필요.

요소의 타입이 object인 List 클래스

Type Casting 필요

에러 발생시 run-time 에러

값 형식이 저장되면

boxing/unboxing 호출됨 -> 성능 저하

※ 범용적으로 사용될 수 있으나 최선의 방법은 아니다.

C# 1.0 해결책

Strong Typed List 생성

 - intList, stringList, myClassList

문제점 

각각의 타입마다 코드생성 -> 관리의 어려움

각각의 코드는 상당히 유사함

C# 2.0 해결책

코드상 generic

정의(define) : 특정 logic을 구현하는 것. 함수 정의, 클래스 정의 등.

코드의 사용(reference) : 구현된 로직을 사용.

List, Collection, Queue, Stack 등의 모든 자료 구조에 적용가능.

Generic type 정의

public class List<T>

{

    private T[] elements;

    private int count

    public void Add(T element){ ... }

    public T this[int index] { ... }

    public int Count{ ... }

}

Generic type 사용

List<int> intList = new List<int>();

intList.Add(1);               // boxing 발생하지 않음.

intList.Add(2);

intList.Add("Three");      // 컴파일 에러 발생

int i = intList[0];            // 형변환 필요없음.

※ int가 type parameter에 대입되는 효과를 가진다.

T = type parameter

T는 타입 자리에 들어간다. 

클래스 부분에 <T>라고 써 준다.

※ Generic으로 만들어진 코드는 사용하면서(reference) 완성된다.

예시)

void swap<T>(ref T a, ref T b)

{

    T c;

    c = a;

    a = b;

    b = c;

}

type parameter에 대해 constraint 적용이 가능하다.

예시)

void swap<T>(ref T a, ref T b) where T:struct

object에 대해 적용 안되며 일반 타입에 대해서만 적용되는 함수를 만든다.

정의

코드의 특정부분을 구체적으로 정의(define)하지 않고 사용(reference)하는 것

적용 코드 부분 : class, interfaces, method

특정부분(정의하지 않는 부분)

<T> : Type Parameter

코드 정의 : type은 <T>와 같이 일반적(Generic)으로 정의

코드 사용 : 명시적 <T>를 정의

Framework에 정의되어 있는 Generic 코드

Collection classes

List<T>, Dictionary<TKey, TValue>, SortedDictionary<TKey, TValue>, Stack<T>, Queue<T>, LinkedList<T>

Collection interfaces

IList<T>, IDictionary<TKey, TValue>, ICollection<T>, IEnumerable<T>, IEnumerator<T>, IComparable<T>, IComparer<T>

Collection base classes

Collection<T>, KeyedCollection<T>, ReadOnlyCollection<T>

Utility classes

Nullable<T>, Comparer<T>

Reflection

장점

타입 안정적(=strong typed) : No more object~ 

성능향상 

Object안에 Integer를 넣었을 때 Generic이 3배 빠름.

Object안에 String를 넣었을 때 Generic이 20% 빠름.

효율적인 코드관리

코드 재사용 

polymorphism : interface, class override, delegate, generic

IDE Tools 지원

실제 코드의 완성은 사용(refererence)하면서 됨.

CLR 기능

runtime시 동작

VB.NET, C++.NET등의 언어에서도 지원

C++의 탬플릿과 개념은 유사하나 기능상으로 많이 다름.

자바의 Generic은 Boxing/Unboxing이 항상 수행된다는 점에서 .NET버젼이 더 우수하다.

Partial classes

하나의 클래스 -> 두 개 이상의 파일에 분리되어 존재가능

public partial class Customer

{

}

소스 컨트롤 : 파일 단위로 checkin, checkout함.

하나의 클래스를 여러 명이 작업해야 한다면?

하나의 클래스를 개발자수만큼 분리 후 컨트롤.

Code Generation : 툴이 생성한 코드와 개발자 코드의 분리.

예시)

Form1.cs과 Form1.Designer.cs partial 형태 두개로 나누어 놓았음

예시) 개발자 코드가 추가되면 안되는 코드

디자이너 코드

웹서비스 프록시 코드

Typed DataSet(xsd)

Partial classes 특징

CLR 수준이 아닌 C# compiler 수준의 기능.

실제 컴파일시에는 하나의 클래스로 인식.

단일 코드로 취합되므로 모든 제약사항은 이에 준함.

 - Base class : 모든 patrial 클래스는 같은 상위 클래스를 상속받아야 함.

 - Attribute, Interface 등도 동일한 개념.

binary 수준에서 partial이 허용되지 않는다. 소스코드 수준에서 partial 가능.

Patrial classes 용도

소스 컨트롤

Tool이 생성한 코드에 사용자 코드 추가.

무분별한 partial 클래스의 사용

코드의 관리를 어렵게 할 수 있다.

하나의 클래스 -> n개의 소스 파일

클래스뷰의 적절한 사용

partial의 유무와 관계없이 일관된 클래스 정보 표시.

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 커널 오브젝트 : 리턴이 되어도 커널 오브젝트는 자동으로 상태가 변경되지 않음.