엘키의 주절 주절

Reactor 패턴- 어떠한 이벤트가 발생하면, 이곳으로 알려달라는 방식.- 윈도우 메시지 핸들러처럼, 특정 이벤트가 발생한다면 통지 받겠다는 방식. Proactor 패턴- 특정 작업을 시키고, 그 작업이 완료되면 알려달라는 방식.- IOCP에서 Completion Port가 이 방식을 취하고 있다. 얼추 비슷한데, 구현에서 차이점이 명확해진다. Proactor는 작업을 시키면서 콜백함수를 직접 넘김으로써 구현되고, Reactor는 디스패쳐를 구현하는 구조가 일반적. Reactor 패턴 사용시에는 디스패쳐를 통함으로써 스팟 포인트가 발생하게 되는 단점이 있다고 보면된다. 이에 비해 Proactor는 명령을 내린 작업에 대해서만 통지를 받게 된다. IOCP의 예를 들면, 내가 물려놓은 소켓에 Recv 이벤..

내 첫 IDE는 MS-DOS용 터보-C 2.0이다. vi 정도는 아니었어도, 윈도우 기반 요즘 IDE와는 비교도 안될만큼 불편했다. 그런 환경에서 Visual Studio 5.0을 썼을때의 환경은 말그대로, 환호가 절로 나왔으며, MFC의 App Wizard는 신이 내린 하사품 같았다. 그렇다보니 GUI환경에 대한 동경은 갈수록 커져만갔을 뿐... 글씨만 줄창 보게되는 CUI (Console User Interface)에 대한 내 이미지는 "직관적이지 않고 어렵다" 였다. 알바 경험, 외주 경험을 다 제끼고 나면 나는 온라인 게임만으로 일해왔다. 내가 상업적인 프로젝트에 외주가 아닌, 직원으로 일한 것은 싸이미디어사의 믹스마스터였다. 당시 서버는 리눅스 서버였는데, 클라이언트 프로그래머였던 나로썬 점검시..

서버의 부하를 줄일 수 있는 부하 조절 정책으로, 블리자드의 디아블로2팀이 조치한 방법이 어떤 방법인지 알아보자. 1. 서버에 요청하는 액션이 일정 횟수 이상 반복되면 Trouble 유저로 판단.* 방 입장/퇴장 반복* 방 생성 후 일정 시간 이내에 빠른 퇴장* 로그인/로그아웃 반복 2. Trouble 유저 (계정)로 판단시 해당 캐릭이 사용된 IP를 차단.* Trouble 유저가 일정 시간내에 다른 IP에서 재사용된다면 그 IP도 차단.* 한번 Trouble 유저로 인식되면 문제가 된 Trouble 사유가 아니더라도 (예: 방생성/퇴장 반복) 로그인만으로도 IP차단. 3. 빠른 방생성 입장/퇴장의 경우 ProcessID도 인식하는 것 같음. (정확하지 않음)* 배틀넷 로그아웃후에 로그인을 통해 방 입장..

1. 개체 단위 lock. 개체 수와 종류가 늘어날 수록 헬. dead-lock 위험성도 매우 크다. 상위 개체 단위로 lock을 잠글 수도 있는데, 이마저도 상호 연관 이벤트가 늘어나면 헬이다. 사실 lock만으로 멀티스레드 로직을 구현한다는 것은 사실상 불가능에 가까운 복잡도를 만들어 낸다는 것을 이미 여러 프로젝트가 증명했다. 2. 데이터 사본 연산 그룹마다 (방 혹은 채널, 존) 스레드를 따로 생성하고 데이터 사본으로 연산 한 후 연산 결과를 이벤트로 다시 던져, 다음 턴 수행 전에 적용하는 방식이다. 기본적으로 턴(프레임이라 불리기도 하는) 단위를 잡고, 해당 단위마다 로직이 돈다는 것을 전제로 삼을 수 있어, 여러가지 계측의 기준점이 되기도 한다. 여러 그룹에서 동시 다발적인 변화가 발생해, ..

1. Through-put 초당 소화 가능 이벤트. 이는 DB나 연결된 기능들과의 교신/처리가 포함된 계측 이어야 한다. 분산 가능한 특정 이벤트들은 지정된 서버와의 교신 (P2P스러운 접근)만으로 처리함으로써, 비용을 분산 시킬 수 있다. 일반적으로 다음 두가지 측정이 이루어지면 된다.- 프레임워크 (네트웍 엔진이라 불리우는) through-put.- 로직 through-put. 2. Through Pipe-line 파이프라인이란 이벤트 처리를 위해 거치게 되는 과정을 표현한 것을 말한다. 구현 별로 다른 어떤 과정에서도 wait-free 방식으로 구현하는 것이 좋다. 어쩔 수 없는 상황이라면 해당 작업 전용 스레드를 할당 받는 것이 좋고. Through Pipe-line은 스레드 디자인과 큰 연관이 ..

예전에 작성했던 글을 다시 보게 됐다. 좋은 프로그래머란 무엇일까? (http://elky.tistory.com/174) 4년이 지난 지금 내가 생각하는 좋은 프로그래머란 무엇일까? (지금은 프로그래머란 표현보다 엔지니어란 표현을 좀 더 즐겨쓴다. 이것도 마인드의 변화겠지?) 우선 무엇보다 부드럽게 이야기하는 법, 대화 자세 이런건도 좋아졌고. 현실과 타협도 많이 한거 같다. 이전에는 책에서 보거나 느낀 최선을 실천하지 못하면 마음이 너무 불안했다. 그런데 그 실천이란 것을 주변 상황을 둘러보지 않고 하다보니, 이 상황에서 중요한 판단들을 놓쳐왔다. 예를 들면 원인 파악보다 중요한게 현재 상황에 대한 대처인 경우가 많다. 또한 패치가 얼마 남지 않은 상황에서 큰 설계상 오류에 대한 대처는 패치를 미루거나..

언젠가 관리자란 주제로 글을 쓰리라 마음 먹었것만, 나를 관리해주시는 관리자도 몇 되지 않으셨었고 (지금도 많진 않지만), 그 분들과 이야기를 나누거나 회고하기에는 재직중인 상황이라 미루다 미루다 이제서야 쓰게 됐다. 사실 좋은 관리자=좋은회사라는 공식이 어느정도 성립한다고 생각이 든다. 그렇게 생각하는 데에는 여러가지 이유가 있다. 1. 소통이 적은 회사 일 수록 직속 상사내지는 관리자와의 대화가 업무 진행에 8할 이상을 차지하기 때문. - 안타깝게도 대부분의 회사가 이렇다는 게 현실 2. 결정권은 관리자에게 있으므로 해당 파트 내지는 팀의 방향성도 관리자에게서 나오기 때문 - 물론 그 보다 위에 계신 분들이 방향성을 잡는 경우도 있지만, 그 마저도 관리자의 역량과 영향이 있다고 볼 수 있음 기본적으로..

출처 : http://www.mcdonaldland.info/2007/11/28/40/