버드님의 "MSN bot으로 빌드하기" 포스트를 보고 감동받은 바가 있어, 몇일동안 조사를 좀 해보았습니다. python은 까막눈이어서 PERL버전으로 말이죠.

여기저기를 뒤져본 결과 세 개의 오픈소스 프로젝트가 나오더군요.

1) Net::Msmgr (CPAN)
  • 버전 0.16이고, 2003년을 끝으로 더이상 maintain되고있지 않습니다.
  • MSNP8을 구현하고는 있는데 완전하지가 않네요. 로그인 안됩니다.
2) POE::Component::Client::MSN (CPAN)
  • 버전은 0.03밖에 안되지만 POE라는 훌륭한 이벤트처리용 애플리케이션 프레임웤에 기반하고 있어서 많은 공부가 되었습니다. 방대한 POE 모듈을 설치해야하지만, 꼭 돌려보시기를 권유드립니다.
  • 다만, 모듈화된 부분과 작성해주어야하는 부분 사이의 역할구분이 다소 애매하긴 하더군요. 동작가능한 샘플스크립트도 같이 있는데, 좀 깁니다.
  • MSNP9를 구현하고 있는데, NOT 메시지를 처리해주는 로직만 약간 추가해주면 잘 돌아갑니다.
  • 샘플스크립트가 아주 예쁩니다. curses 라이브러리를 이용해서 칼라가 번쩍번쩍
3) MSN.pm (http://bot-depot.com)
  • CPAN에 등록된 모듈이 아니어서 찾는데 조금 애먹었지만, 완성도는 셋중에서 가장 높습니다.
  • MSNP11도 지원하며, 2006년 4월에 나온 버전 2.1.2가 마지막입니다. 2008년 1월 현재 신버전 업데이트를 진행중이라고 하니, 2월중에는 MSNP8부터 MSNP11까지를 모두 지원하는 버전이 공개될 것 같습니다.
  • 다른 라이브러리에 대한 의존성이 약해서 설치가 간단하며, 첨부된 샘플 역시 수정 없이 잘 동작합니다.
  • MSNP11을 지원하므로 rath님이나 깜쏘님처럼 돈안들이고 MO(Mobile Oriented - 휴대폰에서 보낸 SMS를 휴대폰이 아닌 다른 시스템에서 받는 형태의 서비스) 서비스를 만들 수 있습니다. 휴대폰 연동을 해놓은 경우 IPG 메시지가 날아오더군요.
MSN 프로토콜에 관심있으신 분들은 MSNPiki 페이지를 참조하시면 많은 도움을 받으실 수 있습니다. 많은 분들이 보시는 hypothetic보다 내용도 더 풍부하고 정리도 깔끔합니다.

문제는 이 봇을 갖고 무얼 하느냐인데, 그건 따로 한번 포스팅하겠습니다. 지금 당장 생각나는 건 다들 너무 원초적인 것들 뿐이라... :-)
신고
  1. 2010.10.04 10:53 댓글주소 | 수정 | 삭제 | 댓글

    비밀댓글입니다


집에서 사용하고있는 ss5 SOCKS5 프록시 서버가 PERL의 Net::SOCKS 모듈과 호환되지 않는 문제가 발견되어 태어나서 처음으로 CPAN에 버그리포팅을 했습니다. 과연 이게 말이 되는 영어인지 많이 고민했습니다만, 뭐 마지막 부분에 소스 변경내용까지 넣어뒀으니 어떻게든 되겠죠. (오히려, Net::SOCKS가 활발하게 maintain되지 않는 모듈인게 문제인듯합니다)

리포팅한 버그: http://rt.cpan.org/Public/Bug/Display.html?id=32492

이 문제를 알아내느라 SOCKS5 RFC도 다 읽고 Wireshark로 패킷도 다 떠봤는데, SOCKS 프로토콜... 조금 원시적이라는 느낌은 들지만 생각보다 깔끔하더군요. 맨 처음 negotiation하는 부분만 끝나고나면 client는 이게 proxy를 거쳐서 서버로 가는 소켓인지 서버에 직접 연결된 소켓인지 전혀 신경을 쓰지 않아도 되는 구조입니다. 의외로 다른 프로토콜에 붙이기 어렵지 않을 것 같네요.
신고


사용자 삽입 이미지사용자 삽입 이미지

그동안 별 신경 안쓰고 넘겼던 부분인데, 오늘 알아보니 두 기술이 많이 다르더군요. (request 건당 fork를 하게 되어있는 CGI 스펙의 단점을 보완하기 위해 태어났다는 공통점은 있습니다만)

FastCGI
  • 웹서버와 별도의 process로 동작. 단, 이 별도의 process를 웹서버가 뜰때 같이 띄우고 죽을때 같이 죽는 등의 컨트롤은 옵셔널하게 가능함.
  • 웹서버와 이 컨테이너는 소켓을 통해 통신
  • 컨테이너 프로세스는 언어에 독립적 (perl, php, ruby, python, 심지어 java도 가능)
mod_* (mod_perl, mod_php, mod_python...)
  • 언어엔진을 웹서버(apache)의 내부에 embed시킴.
  • 따라서 웹서버 프로세스의 크기가 증가함. (그래도 실제로는 공유되는 비율 높음)
결국, 서블릿 컨테이너 모델이 FastCGI와 같은 거였군요. 이런 모델 하에서는 이렇게되면 정적 컨텐츠를 처리하는 웹서버와 동적 컨텐츠를 처리하는 웹서버가 굳이 같은 기계 안에 있을 필요가 없으니 아키텍처상의 이점도 얻을 수 있겠네요. (물론, 컨테이너의 안정성이 확보되어야죠!!)

뱀발)

위 내용을 찾아보다가, 그동안 몰랐던 새로운 사실을 알게 됐습니다.

최근 몇년간 PHP 기반의 애플리케이션들을 작성해오면서(apache2 + mod_prefork + mod_php 썼습니다), 24시간 365일을 돌려도 웹서버를 내렸다 올려줘야 하는 일이 별로 없다는 안정성에 매우 감탄하고 있었습니다만 - 아니 이놈의 애플리케이션은 memory leak도 없나? 슬슬 죽을 때가 됐는데 뭘 이렇게 오래살지?! - 그럼 그렇지, 아파치가 관리해주는 거였군요.

http://httpd.apache.org/docs/2.0/mod/mpm_common.html#maxrequestsperchild

아파치 설정항목 가운데 MaxRequestsPerChild에 그 비밀이 있습니다. 이 항목을 100으로 설정해두면, 100개의 request를 처리한 프로세스는 무조건 죽여버리고 새 프로세스를 띄워서 우발적 memory leak을 방지하게 돼있더라는..
신고


회사에서 서버 모니터링을 위해 MRTG를 사용하고 있습니다. 개발하는 입장에서 실시간으로 서버트래픽을 확인하고 싶을때가 많이 있는데, 이럴때 아주 훌륭하더군요.


커스터마이즈하기도 그다지 복잡하지 않아서, 저같은 경우는 위에서 보시듯이 분당 쿼리수(Query per minute)를 출력해주는 스크립트 하나 짠 뒤에 MRTG와 붙여서 DB서버의 부하를 측정하는 용도로 사용하고 있습니다.

지금까지는 apache + php가 올라가있는 서버에서 돌리고 있었는데, 몇몇 프로그램에서 .html도 PHP로 인식하도록 handler 설정을 변경하게 될 일이 생겼는데요, 하필이면 그때부터 MRTG가 PHP 파싱 에러를 내더군요!!

왜 이런 에러가 나는지 봤더니 MRTG가 만들어낸 html 아웃풋 앞쪽에 다음과 같은 XML 헤더가 붙어있더군요.
<?xml version="1.0" encoding="iso-8859-1" ?>

이놈의 헤더가 <? ~ ?> 안쪽에 있는 xml 헤더를 php 스크립트인것처럼 인식하게 만든거죠.

해당 부분을 주석처리하려고 mrtg 소스 디렉토리에서 *.c와 *.h를 대상으로 'xml'을 검색해보니.. 세상에 아무것도 안나오더군요.

혹시나 해서 mrtg 실행파일을 직접 vi로 열어보니... 털썩... PERL 스크립트였다는...
역시나 텍스트기반의 데이터 처리에는 PERL을 따라갈 자가 없는 것인가봅니다.

ps. xml 헤더 출력부분은 #으로 주석처리해서 끝~
신고
  1. Favicon of http://mwultong.blogspot.com/ BlogIcon mwultong 2006.08.22 15:10 신고 댓글주소 | 수정 | 삭제 | 댓글

    저의 경우에는 텍스트뿐 아니라 거의 모든 작업을 펄로 하고 있습니다. 펄처럼 간편한 언어는 없더군요.

    (∩_∩)





티스토리 툴바