반응형
반응형
이전 포스팅에서 IOCP 서버 스켈레톤 코드를 작성해 보았습니다. 이번 포스팅에서는 IOCP 서버를 위한 스레드풀 초기화 코드를 살펴보겠습니다. 1. IOCP 서버 실행 결과 실행결과 먼저 살펴보겠습니다. 실행환경은 8 코어 16 스레드 CPU입니다. IOCP Worker Thread 16개, IOCP RIL Thread 16개씩 생성하였고 동시실행 가능 스레드 수는 각 8개씩 설정하였습니다. 스레드는 실행중 I/O 나 기타 사유로 Pending 상태에 빠질 수 있기 때문에 동시 실행 가능한 숫자보다 많은 수의 스레드를 생성하여 스레드풀에 등록해 둡니다. 2. 초기화 코드 호출 구조 및 예제 코드 RilInit 함수에서 서버를 초기화합니다. 작업 스레드풀을 생성하고 작업 스레드들을 대기시킵니다. 송신 스..
윈도 환경에서 다중 클라이언트의 접속을 처리하는 네트워크 서버를 구현하기 위해서는 IOCP 사용이 필수라고 생각합니다. 에코 서버를 IOCP 기반으로 구현한 예제는 많지만 실제 현업에서 다중 클라이언트 접속을 처리하기 위한 아키텍처를 어떤 방식으로 접근하면 좋을지 고민해 보는 차원에서 IOCP 기반 다중 접속 처리 및 데이터 처리 프로토타입 구상을 위해 이번 포스팅을 작성합니다. 1. 리눅스 epoll 대비 IOCP(I/O Completion Port) 장점 대부분의 유명한 게임서버는 Windows Server 기반이라는 사실을 알고 계신가요? 그 이유는 리눅스에서 다중 접속을 처리하기 위해 사용가능한 epoll 보다 Windows의 IOCP가 더 나은 장점이 있기 때문입니다. 윈도 표준 API로 윈도 ..
스레드 간 동기화를 위해서는 락 메커니즘을 활용합니다. 락을 획득한 상태에서 예외가 발생하면 락을 반환해야 하는데 예외 케이스가 다양할 경우 각 예외 구문마다 락 반환코드를 넣는 것은 번거롭습니다. 이번 포스팅에서는 지역변수의 스코프 내 유효 특성을 이용하여 함수 종료 시 획득한 락도 자동으로 반환되는 일명 Autolock class에 대해 예제기반으로 설명합니다. 1. 커널모드, 유저모드 락은 크게 커널모드 동작방식, 유저모드 동작방식으로 구분되며 커널모드의 대표적인 락은 뮤텍스이며 중첩락을 허용하는 특징이 있습니다. 유저모드의 대표적인 락은 크리티컬섹션입니다. 현업에서 뮤텍스, 크리티컬섹션의 사용 사례를 다양하게 접했지만 뮤텍스의 중첩을 활용하는 경우는 거의 보지 못하였습니다. 또한 Lock/Unlo..
이번 포스팅에서는 윈도 MFC 환경에서 사용가능한 두 가지 타입의 스레드에 대해 알아보고 생성/동기화/종료 방법을 예제를 통해 알아보겠습니다. 리눅스 환경에서 thread를 사용해 보신 분들은 pthread_create와 같은 POSIX Thread 함수에 익숙하실 텐데요.윈도 MFC 환경에서는 두 가지 타입의 스레드가 존재하며 사용 목적과 프로그램 성격에 따라 타입을구분하여 사용할 수 있습니다. 1. 스레드를 사용하는 이유프로그램 실행 시 프로그램의 진입점인 main 함수를 실행하는 한 개의 메인 스레드가 생성됩니다.메인 스레드만 사용하여 프로그램을 개발하려고 하면 다음과 같은 문제점들이 있습니다.특정 작업을 백그라운드화 하지 못해 작업 끝날 때까지 사용자와 상호작용 불가능(화면 멈춤)싱글 코어 사용으..
INI(Initialization) 파일 포맷은 설정 파일에 대한 사실상 표준이다. 다른 포맷으로 xml, json, yaml도 있지만 windows 환경에서는 ini에 대한 WIN API가 제공되므로 간단한 내용이면 ini를 사용하면 된다. 1. 요구사항 설정 파일 경로에 설정파일이 없으면 프로그램에 내장된 기본값으로 설정파일을 생성할 것(손상시 복구기능 포함) 프로그램 구동중에도 동적으로 변경된 설정파일의 내용을 적용할 수 있을 것 설정값의 추가/삭제에도 관련 코드 수정이 최소화 되도록 인터페이스화 할 것 2. ini 파일 포맷 및 관련 WIN API ini 파일은 SECTION, KEY NAME, KEY VALUE로 구분된다. 샘플 파일에서 [SERVER], [PATH], [TASK_OHLCV]는 ..
이번 포스팅에서는 서버에 다수의 클라이언트가 접속했을 때의 패킷 처리 고려사항에 대해 알아보겠습니다. 다중 클라이언트 패킷 처리는 어떻게 해야 하나? Multiplexing으로 검색하면 TCP/IP Transport Layer의 내용이 나오거나 다중 클라이언트 접속처리 예제 코드만 나오고. 응용프로그램 레벨에서의 다중 클라이언트 패킷 처리 관련 내용을 못 찾겠네요. 그래서 직접 설계해 보려고 합니다. 서버와 클라이언트 관계가 1:1이면 앞선 글의 제목처럼 bridged 그 자체이므로 multiplexing에 대해 별다른 고려가 필요 없이 서버는 마치 내가 클라이언트인 것처럼 패킷을 주고받으면 그만입니다. 그런데 위 그림처럼 다수의 클라이언트가 접속하게 되면 추가적인 고려사항은 무엇있까요? 일상 속의 휴대..
Network bridge 방식으로 증권사 API 활용하기-2-Memory Pool Implemantation 이전 글에서 언급한 내용은 아래와 같습니다. 증권사 API 가 32비트로 제공되는데 따른 프로그램 개발 제약사항 Network bridge 방식으로 트레이딩프로그램과 API커넥터 두 개의 프로그램 개발 필요성 두 프로그램 간 데이터 통신용 패킷관리를 위한 메모리풀 구조 스케치 이번 글에서는 이전 글에서 언급한 메모리풀을 실제 코드로 구현하고 동작까지 확인하겠습니다. In the previous article, we mentioned the following: Program development constraints due to the 32-bit provision of the stock API ..
증권사에서 제공하는 COM, OCX, DLL 포맷의 API 라이브러리는 32비트로 개발되어 있습니다. 그래서 개발 프로그램에는 가상 메모리 공간 4GB 크기의 제약이 있고 64비트 기반의 최신 라이브러리와 연동하기 어려운 점이 있습니다. 그래서 API 라이브러리는 증권사 서버와의 커넥터 역할만 하도록 하고 별도의 로직 프로그램을 64비트로 개발하여 커넥터와 로직 프로그램을 연결하고 있습니다. PC에 설치되어 있는 HTS의 OCX 모듈과 연계하는 방식이 아닌 DLL 연계 방식의 API는 커넥터를 여러 개 실행하여 다계정으로 API를 사용할 수 있게 되어 보다 고도화된 프로그램 로직 구현이 가능합니다. Network bridge 방식으로 증권사 API 활용하기-1-Overview 증권사에서 제공하는 API는..