[카테고리:] Daily Log

Boost 1.35: 주목할만한 새로운 라이브러리!

  1. asio: Portable networking, including sockets, timers, hostname resolution and socket iostreams, from Chris Kohlhoff.
  2. Function Types: Boost.FunctionTypes provides functionality to classify, decompose and synthesize function, function pointer, function reference and pointer to member types. From Tobias Schwinger.
  3. Fusion: Library for working with tuples, including various containers, algorithms, etc. From Joel de Guzman, Dan Marsden and Tobias Schwinger.
  4. Interprocess: Shared memory, memory mapped files, process-shared mutexes, condition variables, containers and allocators, from Ion Gaztañaga.
  5. Intrusive: Intrusive containers and algorithms, from Ion Gaztañaga.
  6. MPI: Message Passing Interface library, for use in distributed-memory parallel application programming, from Douglas Gregor and Matthias Troyer.
  7. System: Operating system support, including the diagnostics support that will be part of the C++0x standard library, from Beman Dawes.

하나씩 뜯어보고 리뷰를 해야겠군요. 아싸. (포스팅거리가 생겼다)

Flowcut!: Orthogonal Code Injection for C++

C++ Native AOP의 가능성에서는 Aspected Oriented Programming이란 용어를 사용하였고, 크게 문제될게 없다고 생각했지만, AOP에 대해 고찰을 해보니 AOP라고 (좁은 의미에서) 부르기에는 약한 것이 사실이었다.

그래서 생각해낸 말이 직교적(수직적?) 코드 삽입orthogonal code injection이다. 뭐 기존에 존재하는 말일수도 있지만… 말 그대로 “기본 뼈대가 되는 기존 로직에 수직적인 코드삽입을 해야할 때 쓰면 좋지 않을까?” 라는 생각으로 만든 Flowcut!이란 이야기 되겠습니다.

더 보기 “Flowcut!: Orthogonal Code Injection for C++”

idea: Distributed wiki

요즘 학교에 다니는지라, 이런저런 문서를 작업할 일이 많다. 뭐 회사다닐때도 많긴 했지만, 학교의 무선랜 환경이 그다지 좋지 않기 때문에 위키나 스프링노트에 문서작업을 하는 요즘에는 애로사항이 좀 많다. (다행히도 왠만한 강의실에서 무선랜이 다 되기 때문에 큰 문제는 없지만… 그래도 불안한건 사실이다! 간간히 넷이 끊겨 주시는데 정서 불안..)

이래서 생각난 것이 Mercurial과 유사한 형태의 저장 메커니즘을 가진 위키 시스템이다. 쉽게 말하면, 로컬에 위키 솔루션을 설치하고 원격에 있는 위키의 내용을 당겨(pull)와서 로컬에서 편집 및 저장을 자유롭게 하고, 네트워크가 사용 가능한 시점에 원격에 있는 위키에 밀어(push)넣는 방식이다. 중앙집중식 저장 메커니즘과는 달리 remote가 특정 서버가 아닌 설치된 위키 솔루션이라면 그 어느 것이든 상관이 없다는게 다른 점이랄까?

여기서 더 나아가, 데이터 뿐만이 아니라 위키 솔루션의 구현에 필요한 코드/이미지/데이터 역시 동일한 방식으로 관리할 수 있다. 즉, 집에 있는 위키솔루션을 업그레이드 하고 나서, 변경된 내용을 홈페이지에 있는 위키솔루션에 push를 하면 홈페이지에 있는 위키 솔루션이 업데이트가 되는거다. (물론 변경된 위키데이터들도 업데이트가 된다.) 그리고, 랩탑에 있는 위키솔루션에서 홈페이지에 있는 위키솔루션을 pull해오면 랩탑도 업데이트되는 거다.

이 정도로 생각을 해보니, 지금 사용하고 있는 Dokuwiki(혹은 RDB를 사용하지 않는 그 어떤 위키라도)에서 충분히 가능한 내용인듯 하다. 일단 각 노드에 php를 구동할 수 있는 웹서버를 설치해두고 위키 솔루션 전체를 Mercurial로 관리하는 거다. 그리고, 이런 작업을 위해 약간의 유틸리티 작업만 해주면 충분히 가능할 것 같다. (해보다가 뭣하면 이런 용도로 하나 만들지 뭐.)

음. 내친김에 Dokuwiki+hg로 한번 해볼까.

C++ Web Server: Concept #1

1차분 Concept

  1. J2EE에서 등장했던 Filter개념으로 모든 플러그인들을 해결한다.
  2. Filter들의 Chain이 기본이다. Chain의 끝에는 Static 파일 Service가 들어간다.
  3. 각각의 Filter들은 Request와 결합하여 하나의 Task를 생성한다
  4. 특정 Request에 연관된 Task들은 Task Chain이라고 부른다.
  5. Task Chain은 내포한 Task들이 종료될때마다 다른 쓰레드로 이동이 가능해야 한다.
  6. Network IO는 전담 Multiplexer쓰레드에서 처리한다
  7. 스크립트 확장은 특정 스크립트 파일을 Filter로 만들어주는 ScriptingEngine에서 처리하도록 한다.
  8. Request/Response의 Body부분은 std::iostream의 shared_ptr로 관리한다

2차분

  1. Filter는 Request Filtering과 Response Creation을 담당하는 process_request operation과 Response Filtering을 담당하는 filt_response operation 으로 이루어진다.
  2. response::shared_type process_request(request::shared_type)
  3. void filt_response(response::shared_type)
  4. process_request에서 response를 생성하고 나면, 그때부터 filt_response를 process_request를 실행한 역순으로 실행한다. 즉, Stack이란 이야기
  5. 웹서버 쪽에서는 Mime parsing(폼변수 분석)에 대한 책임을 지지 않는다. HTTP Header까지만 책임을 지고 그 뒤는 각 모듈에게 맡긴다. (이래야 대용량 전송시 커스터마이징이 쉬워진다.)
  6. Mime Parsing에 대한 책임을 지지 않는 대신에 Mime Parsing을 위한 라이브러리를 별도로 제공한다. ScriptingEngine에서 이를 활용할 것인지는 별도로 고려한다.

C++ Web Server: Concept#0

C++로 웹서버를 만들 생각을 왜했는지는 이미 기억이 가물가물. @_@

  1. J2EE에서 등장했던 Filter개념으로 모든 플러그인들을 해결한다.
  2. Filter들의 Chain이 기본이다. Chain의 끝에는 Static 파일 Service가 들어간다.
  3. 각각의 Filter들은 Request와 결합하여 하나의 Task를 생성한다
  4. 특정 Request에 연관된 Task들은 Task Chain이라고 부른다.
  5. Task Chain은 내포한 Task들이 종료될때마다 다른 쓰레드로 이동이 가능해야 한다.
  6. Network IO는 전담 Multiplexer쓰레드에서 처리한다
  7. 스크립트 확장은 특정 스크립트 파일을 Filter로 만들어주는 ScriptingEngine에서 처리하도록 한다.
  8. Request/Response의 Body부분은 std::iostream의 shared_ptr로 관리한다

비동기적 고찰

회사에서 이번주까지 작업한 건 poller라는 간단한 클래스 템플릿이었다. (따지고보면 그리 간단치도 않다)

request-complete모델을 기반으로 비동기적 IO를 처리하는 프레임워크인데 request메소드를 통해 여러타입의 io작업을 요청하고 poll메소드를 통해 요청했던 io의 인스턴스를 되돌려 받음으로써 완료를 통지받는 형태의 작업으로 network io + C10K문제(1만의 동시접속자를 처리하는 문제)를 해결하기 위해 kqueue/iocp/epoll등의 OS지원을 단일 인터페이스로 사용하기 위한 코드다.

1.
이 코드를 작업하다 보니, 기존에 만들어 쓰던 Socket Wrapper가 전혀 의미가 없다는 사실을 깨달았다. 어차피 Socket에서 사용하는 작업들은 connect/listen/bind/send/recv/close 정도 인데다 굳이 복잡하게 소켓 API를 만들 필요가 없는거다. 그냥 Request & Forget형태로 상황에 맞는 코드, event-driven형식을 강요하면 문제가 해결된다.

게다가, 어차피 iocp지원을 위해서는 표준적인 send/recv가 아닌 Winsock에만 존재하는 WSASend/Recv를 써야하고 결국은 각 시스템에 맞는 별도의 코드를 구현해야 한다. 이건 DriverT라는 템플릿 매개변수로 빼두었기 때문에 그다지 큰 문제가 될 것 같지는 않다.

2.
io작업이 아닌 XML Pull Parser나 asynchronous task같은 서비스도 이런 형태로 구현이 가능하다.

3.
생각해보니 결국은 event-driven programming. 하지만 해볼 가치는 있는듯. 그나저나 철학이든 뭐든 죄다 난 늦게 깨닫는단 말이야. 쳇.

4.
자 이제 취미로 놀면 되는거다.

어머나. 소스코드를 복사하다니! 다음 vs. 네이버

뒷북을 울려라~ 이히~ 둥둥둥~

하드코어모드로 끝간데 없이 달리는 회사일정에 때맞추어 열린 World of warcraft: Burning Crusade의 흥미진진한 새로운 세상에다가 활동을 재개한 밴드일정으로 정신이 하나도 없는 까막군에게 심심함을 덜어주는 포스팅거리가 생겼으니 뒷북을 울려라~!

사건의 요지는 다음에서 만든 자바스크립트 소스를 네이버에서 홀랑 베껴다 써먹었다는 훈훈한 이야기입니다. 출처는 스마트플레이스. 덕분에 읽을만한 블로그를 찾았군요. (처음에 어디서 봤는지는 기억이 -_- ZDNet이었나..)

여하튼, C++을 이용해 패키지를 만드는 업체에 근무하는 저로서는 상상하기 힘든 일입니다. 저희팀에선 External Copy & Paste가 드물거든요. (회사 내부코드에선 간간히 있지만..)

일단은 스펙(프로토콜 문서 혹은 인코딩 문서)이 공개되어있는 경우에는 스펙보고 코드를 만들면 그만이고, 스펙이 안나와있으면, 코드도 없기 마련인지라.. 하핫. 외부 코드를 가져와서 사용할때는 라이센스를 면밀히 살피죠. 나중에 문제될까봐. (그래서 남은건 boost, ACE, STLPort 정도이군요..)

심지어는 C++ 개발자들이 많이 보는 Code Guru같은 사이트에 올라온 코드들도 무용지물인 경우가 많습니다. MFC를 배제하는게 기본 원칙인데 MFC코드가 많거든요. MFC코드를 배제하더라도 네이밍규칙같은 것에 위배되는게 많아서 고쳐쓰려면 결국 코드를 다시 작성하는거나 다름 없답니다. (고쳐쓰느니 그냥 짜고 말죠.) 그리고, 이해하지 못하면 유지보수가 불가능한데 이해를 하다보면 그냥 짜는게 깔끔한 코드를 만드는 지름길인지라..

서비스를 만드는 환경과 패키지를 만드는 환경의 차이일까요?

어느쪽이나 시간압박은 비슷하고, 주어지는 외부 압력도 유사합니다. (큰 차이는 모르겠군요.) 아마 개발자 자신의 자세가 문제였을거란 생각이 드네요. 소프트웨어 프로그래밍을 예술로 생각하고, 장인정신이 없는 코딩은 스스로 만족하지 못해 몸을 빌빌 꼬는 제 입장에서 볼 때 말입니다. (모로가도 돌아가기만 하면 된다. 오픈만 빨리하면 된다. 라고 생각하시는 일부 혹은 대다수의 어떤분들과는 매우 사이가 안좋아질 가능성이 농후한거죠.)

자신의 코드에 애착을 갖고, 자신의 작업 결과물에 자부심을 느끼며, 그 성과물로 인정을 받는 정직한 소프트웨어 엔지니어가 많아지기를 기도하며, 뒷북울리기를 그만 할랍니다. (5분 쉬었으니 이제 다시 일하러.. ;ㅁ;)

ps. clearable_pool이라는 쓸만한 템플릿을 완성한지라 조만간 포스팅할지도 모르겠습니다아.

ps2. 아 편집하다 날아간 내용이 있어서.. Daum과 Naver양사 모두 CCL을 위반한 케이스가 됩니다만(문제의 라이브러리), 문제가 되는 flexInput은 Naver가 Daum코드를 가져다 쓴게 맞는듯 합니다. 냐앙.

BabelFish놀이.

알타비스타의 번역 서비스인 바벨피쉬 를 이용해 문장을 돌려 번역해보면 재밌는 문구가 나옵니다. 한국어 -> 영어 -> 네덜란드어 -> 영어 -> 독일어 -> 프랑스어 -> 영어 -> 일본어 -> 한국어.. 대충 이런식으로 돌려서 번역해 보는 거지요.

원래 언어로 돌아와보면 참 재밌는 결과가 나옵니다. 간만에 생각나서 해봤습니다. ㅋ

더 보기 “BabelFish놀이.”