python으로 만든 dhcp daemon

Posted at 2012/01/30 03:00// Posted in 잡생각
오늘 기분전환겸, bearcat을 재작성할 마음을 꺼내었다. 전부터 python으로 다시 만들어볼 생각이었으므로, 첫번째 구성품인 dhcp daemon부터 알아보았고, 간만에 bootp 프로토콜좀 보다가 대략 client의 packet을 분석할 수준으로 깨작거려봤다. experimental 디렉토리에 몇줄 커밋하고 정지.

이 다음은 언제 또 이어서 할지는 미지수... 뭐 머리가 좀 아프고, 신경을 돌려야할 일이 생기면 이어서 하든가 하겠지요.

작업은 Mac mini에서 하고, client는 Windows PC에서 virtual pc를 돌려서 PXE boot를 시도하면서 테스트하면 간단한 테스트 환경이 됩니다.

크리에이티브 커먼즈 라이센스
Creative Commons License
2012/01/30 03:00 2012/01/30 03:00
Tag , ,

IPSec over TCP

Posted at 2011/06/08 00:18// Posted in 잡생각
Cisco 의 VPN은 대개 IPSec으로 구성된다. 보통 VPN은 LAN to LAN이거나 PC to LAN 을 지원하는데, 아마 관리자가 아닌바에야 PC to LAN 환경을 접하리라고 본다.

이런 경우에 관리자들에게 가이드 하나 제시하려고 한다.

Default 구성의 경우 UDP를 사용하며 port 500을 이용하는데, 이왕이면, TCP를 이용하게 해달라.


왜냐면, UDP로 구성하는 경우에 PC의 환경이 공유기를 사용해야하는 상황에서 둘 이상이 접속해야하는 상황이 된다거나, 개인이 사용하더라도, Virtual Machine을 이용하여 들어가려한다거나 하는 상황이 되면, PC 한대에서밖에는 접속이 안되는 상황이 발생한다.

왠만하면, TCP로 접속하게 해주는 것이 다양한 환경을 지원할 수 있으니... 생각해주시면 고맙겠다.
크리에이티브 커먼즈 라이센스
Creative Commons License
2011/06/08 00:18 2011/06/08 00:18

AMF의 정수 시리얼라이즈

Posted at 2010/09/22 00:06// Posted in 잡생각

플래시 기반의 오브젝트들을 네트웍으로 전달하는 포맷에 대한 Action Message Format의 스펙을 보면, 앞 부분에 정수형에 대한 encoding이 나옵니다.

0x00000000 - 0x0000007F: 0xxxxxxx
0x00000080 - 0x00003FFF: 1xxxxxxx 0xxxxxxx
0x00004000 - 0x001FFFFF: 1xxxxxxx 1xxxxxxx 0xxxxxxx
0x00200000 - 0x3FFFFFFF: 1xxxxxxx 1xxxxxxx 1xxxxxxx xxxxxxxx
0x40000000 - 0xFFFFFFFF: throw range exception



와 같은 표를 볼 수 있는데요. 흥미로운 것은 UTF8과 비슷한 방식으로 값에 따라 인코딩 결과가 1 바이트에서 4바이트를 취한다는 것이고요. 일정한 검증 규칙으로서 최상위 비트가 1로 진행하다 0으로 종료하는 형태를 띈다는 것입니다. 그렇게 함으로써,
  • tiny int 영역인 0x7f까지의 7 bit 사이즈는 1 byte로 전송이 되고,
  • 16K 이하의 값을 나타내는 0x4000 미만은 2 byte로 전송되며,
  • 2MB 정도를 나타내는 21bit 사이즈는 3 byte로 전송되고
  • 그 이상 29bit 정수까지는 4바이트로 전송된다는 것입니다.
  • 그리고, 30, 31, 32 bit 정수는 아예 취급을 안하겠다는 것인지 exception을 내는군요.
아이디어가 좋습니다. 그리고, 이 포맷이 1 byte를 아껴야하는 상황까지 고려한 설계라는 것이 훌륭합니다. AMF 를 이용한 Client/Server 프로그래밍에서 정말 Server/Client 들이 저런 수준의 설계를 받쳐 줄만한 상위 설계를 하는지는 모르겠지만, 이런 사실을 알고 졸라 메는 정신으로 Flash 및 Server Side Script들을 설계하면 좋겠다는 생각이 드네요.
크리에이티브 커먼즈 라이센스
Creative Commons License
2010/09/22 00:06 2010/09/22 00:06

Four Square 짧은 생각

Posted at 2010/08/21 10:39// Posted in 잡생각
Four Square라는 아이폰용 어플리케이션이 있다. 물론 안드로이드용으로도 있고, 윈도우 모바일용으로도 있을 것이다. 간단히 소개하자면, 내가 현재 있는 장소의 이름을 위치 기반으로 검색하고, 내가 거기 있음을 "CHECK IN"하는 행동을 기반으로 하는 어플리케이션이다. (장소가 검색되지 않으면, 내가 추가할 수 있다.) 장소는 음식점 이름이나 학교 이름 심지어 벤치에다가도 이름을 줄 수 있고, 어떤 장소는 이름이 여럿인 경우도 있다.

정확한 기간은 모르겠지만, 대략 한달정도 총 CHECK IN 수 대비 한 사람의 CHECK IN 수가 일정 비율(20%?) 이상을 넘으면 "Mayor"라는 타이틀(Mayorship)을 준다.

현재 나는 19 곳의 "Mayor"다. 어제까지만해도 20곳이었는데, 아마도 한 곳을 잃은 것 같다. 그리고 며칠전에는 내가 다른 이의 Mayor 타이틀을 뺏기도 했다. 아직까지는 왠만한 곳은 대략 일주일만 꾸준히 CHECK IN 해주면 Mayor 를 얻어오는 것은 가능할 것 같다.

얼마전엔 강동구청역 Mayorship을 얻었는데, 이는 거의 두달이상을 매일 아침저녁으로 CHECKIN하여 얻은 것이었다. 원래 Mayorship을 가진 사람에겐 미안하지만, 나름 FourSquare에 대한 생각을 깊게하게 된, 하나의 사건이었다. 두 달 동안  목적을 가지고 꾸준히 뭔가를 하는게 쉬운것인가? FourSquare는 정확히 며칠을 더 CHECKIN하면 너한테 Mayorship이 돌아간다고 말하지 않는다. 그냥 최근 한달사이에 너가 몇번 체크인 했는지만 느낌표찍어주면서 말해줄 뿐이다.

강아지 오줌싸기. 땅따먹기. 위치기반 서비스 중에 이런 게임을 며칠을 걸쳐서 느리게 진행되는 서비스라니...

몇달동안 CHECKIN해서 Mayor를 얻어내는 작업... 한 번쯤 해보시라.
크리에이티브 커먼즈 라이센스
Creative Commons License
2010/08/21 10:39 2010/08/21 10:39

F, V 에 대한 옛 한글 표기

Posted at 2010/05/13 17:52// Posted in 잡생각
http://ko.wikipedia.org/wiki/%e1%85%84 ··· 585%258b

위 내용을 보니, 개화기 이후 외래어 표기에 대한 시도를 ㅇㅂ, ㅇㅍ을 붙여 쓰는 자음으로 제안하였었군요. 익숙함의 문제겠지만, 우리도 한글의 다양한 표현을 최대한 간편하게 줄여 사용하는 것 같습니다. 아마 외국 발음을 한글로 표현한다면, 저렇게 자유도 높은 결합을 최대한 이용하는 방향으로 나가는게 맞고, 그런 한글을 본다면 술술 읽힐 것 같진 않네요.
크리에이티브 커먼즈 라이센스
Creative Commons License
2010/05/13 17:52 2010/05/13 17:52

Theodore 표기.

Posted at 2010/03/25 15:27// Posted in 잡생각
찾은게 아까워서 기록. (뭔짓이야!)

(15:22:45) Hojin: 시어도어 119000 개
(15:22:58) Hojin: 데오도르 17800 개
(15:23:10) Hojin: 시어도르 62300 개
(15:23:22) Hojin: 데어도어 57500 개
(15:23:38) Hojin: 씨어도어 3540개
(15:23:47) Hojin: 씨어도르 1240개
크리에이티브 커먼즈 라이센스
Creative Commons License
2010/03/25 15:27 2010/03/25 15:27

오픈소스와 설계

Posted at 2010/03/15 02:22// Posted in 잡생각
오픈소스는 개발자 그룹에게 많은 도움을 주는 것임에는 틀림없다. 어떤 프로젝트의 메인에 위치할 수도 주변 모듈에 위치할 수도 있으니까. 오픈 소스를 가져다가 잘 배치하는 것만으로도 프로젝트의 상당 모듈에 대한 설계를 쉽게 넘어갈 수 있지 않은가?

뭐 때론 납품을 해야하거나 메인 프로그램이 이미 공개된 소프트웨어 소스의 대부분을 사용하여 해결해야하는 경우도 있을 수 있다. 이 경우 라이센스문제만 허용한다면 문제될 것도 없다. 납품을 기대하는 당사자가 소스를 보는 것이 아니면 무슨 문제가 있으랴. 또한 서비스로 제공하는 부분에 대하여 소스 제공의 의무가 없는 것을 알고 있다면 이것 또한 문제가 아닐 수 있다.

오픈소스에 대해 잘 알고, 라이센스 문제도 없다. 그런데도 오픈소스를 가져다쓰는 양심상 문제가 생기는 것은 무엇일까? 그것은 내 이름을 걸고 어떤 문제가 해결되었을 때, 검증 절차를 따지는 후배들에 의해 내 결과물을 어떻게 판단할까를 고민할 때는 문제가 조금 달라지는 것 같다.

내 실력이라하는 것이 어디에 나타나는가. 그 사람의 역할이 그 문제를 해결함에 있어서 어느 정도의 기여를 했느냐가 판가름나는 순간을 생각한다면, 오픈소스는 사실 최선의 선택이라 할 수 없다.

사업의 시급함이 문제이냐 내 작업 결과물에 대한 판단이 문제냐하는 것에 있어서, 나는 과연 내 자존심을 살짝 내려 놓을 수 있는 각오가 되어 있나?

-- 끝 --
크리에이티브 커먼즈 라이센스
Creative Commons License
2010/03/15 02:22 2010/03/15 02:22

Web page를 RPM으로?

Posted at 2009/11/15 23:24// Posted in 잡생각
웹서비스를 개발할때, 흔히 하듯 소스를 SVN에서 태깅후 java 컴파일 혹은 php 소스를 그대로 실서버에 반영하도록 하는 스크립트를 작성하는 대신, 올릴 내용을 RPM으로 묶고, 적절한 rpm dependency를 걸어서 설치/업그레이드하는 방식을 생각해보았습니다.

RPM으로 배포를 하게되니, 새로운 웹서버를 구성할 때, 의존성에 따라서 필요한 서버 모듈들을 알아서 설치하게 되는 이점이 있더군요. 예를 들어 웹페이지 rpm에 필요한 꼭 설치해야하는 php 모듈들을 명시해 놓으면, 웹서버 설치시 빼먹을 수 있는 모듈들이 알아서 설치되는 것이 괜찮았습니다.

또한 DB 접속 파일등은 configuration 처리되므로, 굳이 스크립트에서 조심스럽게 하지 않아도 되는 점이 있습니다.

그리고, root 권한으로 설치하므로, 웹서비스를 새로 시작한다든지, 웹서버 문서 트리 외에 /etc 파일을 직접 수정해야하는 부분도 post install 스크립트에 넣을 수 있어서 좋은 것 같습니다.

S/W를 설치한다는 개념으로 관리하는 것 서비스라 할지라도, 혹은 다른 어떤 형식으로 하더래도, 많은 도움이 되는 생각임을 확인하게 되었습니다.

자체 Repository를 운영하여 패키지 관리하시는 서버 관리자 분들께서 관련하여 웹서비스를 패키지로 릴리즈한다면 어떤 도움이 있으실지 의견을 들어보면 좋겠습니다.
크리에이티브 커먼즈 라이센스
Creative Commons License
2009/11/15 23:24 2009/11/15 23:24

웹페이지의 글꼴

Posted at 2009/06/16 23:23// Posted in 잡생각
다른 것은 모두 심정적으로는 결론이 나겠지만, 전 글꼴 문제만큼은 선택을 할 수 없는 분야인것 같습니다.

웹페이지를 디자인할 때, 글꼴을 설정해야하는것일까요...?

집에서 쓰는 크롬 브라우저는 나눔글꼴들을 쓰고 있는데, 이 상태로 위키피디어를 보면, 그 글꼴들이 살아납니다. 물론, 제 블로그에서도 그 글꼴을 그대로 보기 위해서 폰트 설정을 CSS에서 모두 지운상태입니다.

글꼴은 어떤 것을 사용하는지에 따라 디자인에 큰 영향을 미칩니다. 그런데, 모든 PC에 원하는 글꼴이 설치되어 있지도 않습니다.

따라서, 디자이너들은 원하는 폰트의 글씨를 그림으로 만들기 마련입니다. 오랫동안 좋은 폰트가 한국어용 MS Windows에 들어오지 못한 탓도 있겠지만, 좋은 폰트들이 많이 있었어도, 디자이너의 선택은 쉽지 않았을 것입니다.

그렇다면, 정말 훌륭한 디자이너라면, 어떤 폰트를 쓰더라도 예쁘게 나올 수 있는 디자인을 해야하는 것일까요?
크리에이티브 커먼즈 라이센스
Creative Commons License
2009/06/16 23:23 2009/06/16 23:23
Tag

VIM, EMACS 어렵다는 사람들...

Posted at 2009/06/02 14:43// Posted in 잡생각
Vim , Emacs가 어렵다는 사람들에게 결여된 생각 중 가장 근본적인 것은, 입력과 출력이 스트림, 즉 문자열의 연속이라는 환경을 극복하면서 만들어졌다는 것을 모른다는 것에 있다.

키보드로 입력한것과, 그것의 결과로 화면에 뿌려지는 것이 문자열의 연속인 세상에서 만들어진 것이 GUI에 적응해서 나온 에디터이기 때문에 그렇게 어렵게 느껴지는 것일뿐이다.
크리에이티브 커먼즈 라이센스
Creative Commons License
2009/06/02 14:43 2009/06/02 14:43
1 2 3 4 5 ... 10