본문 바로가기

프로그래밍

(38)
서버 개발자가 알아야하는 정보들.. 오랜 시간동안 서버개발자 라는 타이틀을 가지고 지금까지 활동을 하고 있습니다. 여러가지의 프로젝트를 진행하였고, 지금은 게임 개발자로서 활동을 하고 있습니다. 어찌 보면, 좀더 편한 형태의 개발을 할수 있는 기회가 많았으나 어찌된건지 자꾸 게임에 기웃거리게 됩니다. 이제, 다양한 프로젝트를 하면서 얻는 다양한 경험들을 공유해 볼까 합니다. 개발자들 중에 이러한 정보를 잘 정리하는 분들도 계시겠지만, 저 같은 경우는 상당한 귀차니즘이 있어서 잘 정리를 하지 못하였지만, 이번기회에 이러한 귀차니즘을 좀 바꿔볼까 합니다. 초급 개발자 분들에게는 미리 극한 직업을 체험해 볼수 있는 기회가 될수도 있겠고, 이제 개발에 재미 붙이신 분들에게는 유용한 정보가 되지 않을까 조심스럽게 생각해 봅니다. 이 포스팅은 계속 ..
TIP. fork() 시 callback 처리 LINUX에서 fork() 함수를 사용하는 경우, fork 전후의 처리를 해야하는 상황이 있다. 일반적으로는 pid_t pid; if ((pid = fork()) 0) { // parent } 와 같은 형태로 처리해도 되지만, pthread_atfork()를 사용하면 좀더 효율적인 처리가 가능하다. void fork_ready() { fprintf(stderr, "fork() 전\n"); } void fork_child() { fprintf(stderr, "fork() 이후 - CHILD\n"); } void fork_parent() { fprintf(stderr, "fork() 이후 - PA..
TIP. EPOLLONESHOT 사용 이슈 LINUX에서 네트워크 이벤트를 처리하기 위해 사용하는 방식으로 epoll을 많이 사용한다. 장점이 많은데 epoll의 장점 중 하나가 EPOLLONESHOT이라는 플레그가 있다. EPOLLONESHOT의 용도는 이벤트가 발생될때 한번만 발생되고, 대기상태로 진입하게 하는 특성을 가진다. 그런데, 문제가 하나 있다. - 이벤트가 발생된 이후에, 이벤트를 재 설정(epoll_ctl(EPOLL_CTL_MOD)) 하면서 발생하게 된다. - 설정 이후에, 소켓의 이벤트가 발생되지 않는 문제가 바로 그것이다. 이는 최근 커널에서 EPOLLWAKEUP 으로 해결이 되었는데, 지원하지 않은 경우는 다음 방식을 사용하면 된다. ioctl(fd, FIONREAD, &nread); 단, 소켓에서만 해당 syscall을 사..
대량의 데이터 처리를 위한 프로세싱 모델 서버 개발자들이 한번쯤 고민하게 되는 모델이다. 그런데, 이 모델의 고민은 IOCP기반의 개발자 보다는 UNIX기반 개발자들이 더 많은 고민을 하게 되는 모델이기도 하다. 나는 가끔 윈도우 기반으로 개발하는 것은 참으로 축복이라고 생각한다. 많은 개발자 들이 MS를 욕하지만, 내가 보기에는 MS가 개발자들의 고민을 아주 많이 해소해 주는 존재 임은 분명해 보인다. 그럼 이제 옆의 구조의 의미를 말해보자. LINUX에서는 대량의 데이터 통신을 위해 Edge Triggered기반의 epoll을 제공하고 있다. 그런데, epoll이 IOCP처럼 많은 것을 해주지는 못한다. 그러다 보니, 그 만큼 많은 처리가 개발자의 몫이 된다. 개발자 라면 이런 고민을 할것이다. "클라이언트의 연결이 많은 상태에서 어떻게 데..
함수 invoke~ 예전에도 몇번 올린 내용이지만, 처음 만들게 된 계기는 바로 coroutine을 구현 하면서 였다.. 함수에 대한 주소만 가지고 함수를 호출해야 하는 상황이 되는데, 문제는 기존의 방식으로는 제한된 함수의 인자만을 가질수 있다는 것이다. 즉, 다양한 인자를 갖는 함수를 다룰수가 없다는 문제가 있다. 기본의 방식은.. DWORD (*CALLBACK)( LPVOID args) = &CALLBACK_FUNC; 와 같이 접근해 처리해 주어야 한다는 것이었다. 얼마 지나지 않아, coroutine에 적재되는 함수의 형태에 따라 다양한 인자를 유동적으로 주고 싶어 졌다. 그래서 만든것이 invoke 함수이다. 이 함수는 기존방식 처럼 함수의 주소를 기반으로 접근을 하게 되지만, N개의 인자를 함수별로 별도로 줄수 ..
x86 호출 방식에 대한... 요즘 함수의 call 방식에 대한 여러 자료를 보고 있다. 엄밀히 말하면, x86_64에 대한 지원을 하기 위해서이다. 일전에 게시한 게시물 중에 함수 invoke에 대한 자료의 연장이라고 할수 있다. 이는, x86에서는 함수의 인자를 모두 stack에 저장하여 호출하는 방식이라, 보다 간편하게 구현이 가능 하였으나, x86_64에서는 이 부분이 많이 바뀌어 이를 구현하는데 만만치 않음을 실감하고 있다. 일반적인 상황이라면 클라이언트가 x86 기반으로 운영되는 상황이라, 서버도 x86으로 구현하는 상황에서는 문제가 되지 않지만 개발자의 욕심이라는게 또 그렇지만은 않은지라.. 더 더욱, 나는 x86_64 기반의 리눅스를 사용하고 있어 x86으로만 구현된 함수의 찜찜함 때문이랄까~ 정리하자면, x86은 모든..
(remote) function dispatch~ 전에 관련 글을 쓰고 나서 오랜만에 그에 대한 글을 추가합니다. 이제 테스트를 마쳤습니다~ 간단한 자료형(point가 포함되지 않은)인 경우가 아닌, point 가 포함된 데이터를 넘겨서 처리하게 하려고 하니 파생적으로 여러가지 모듈이 추가로 개발되었네요.. 이제 IDL로 이러한 루틴을 Simple하게 만들 방법을 궁리해 봐야겠습니다~ struct sub_arg { int a; char *b; }; // 실행할 함수 int invoke_test( struct stat *fs, char *name, struct sub_arg *sub) { fprintf( stderr, " invoke: '%s'\n", name); fprintf( stderr, "\t fs.st_size: %ld\n", fs->st_siz..
IDL 컴파일러... IDL을 사용해 보려고, 우선 컴파일러 부터 찾아 보았습니다. 그중에 XPIDL이라는 컴파일러가 상당히 마음에 들었습니다. Mozilla 프로젝트의 XPCOM에 포함되어 있는 컴파일러 이면서, Gnome의 libIDL기반으로 개발이 되어 약간의 수정 만으로 원하는 컴파일러의 output을 만들수 있다는 장점이 있어 좋네요~ http://developer.mozilla.org/en/docs/XPIDL 제가 원하는 접근 방식과는 약간의 차이가 있지만, IDL이라는 interface가 살짝 마음에 드네요~ ^^~ 참, Windows Live Writer을 사용해 처음으로 BLOG글을 작성해 봤습니다~