|
|
리눅스에서 캡쳐한 화면입니다. ^^ 아직 별로 볼건 없지만.. 궁금하신분은 보세요. 현재 작업하고 있는 내용을 캡쳐했으므로 v0.0.1과는 약간 틀립니다. 자세히보기... (221 bytes)
첫번째 소스 릴리즈 입니다. 아직 핵심 모듈을 구현중이며 사용자를 위한 릴리즈는 전혀 아닙니다. 개발에 관심 있는분만 받아주시길 바랍니다. 자세히보기... (1 의견, 869 bytes)
openx 프로토콜의 전체적인 설계와 openx를 구성할 모듈 들에 대해 설명한 글입니다.
처음 올리는 글이므로 자세한 내용은 없습니다.
넵스터나 소리바다와 비슷한 기능의 파일 교환 프로그램과 프로토콜을 만드는 프로젝트입니다. 넵스터/소리바다 프로그램들이 독자적인 프로토콜을 공개하지 않고 자체 개발 프로그램만을 사용하도록 해서, 유닉스 계열에서는 이런 프로그램 사용이 어렵습니다. 넵스터는 해커들에 의해서 프로토콜이 공개되서 여러 클론들이 존재합니다만, 소리바다 프로토콜에 대한 정보는 없더군요. 처음에는 소리바다 클론으로 프로젝트를 진행하려고 하다가 프로토콜에 대한 정보 부족과 소리바다 측의 입장을 듣고는 생각을 바꾸게 되었습니다. 소리바다 측에서는 프로토콜을 공개할 생각이 없고, 클론이 생기는 것에 대해서도 반대하는 의견이더군요. 공개된 프로토콜을 만드는 것이 장기적으로 좋다고 생각해서, 현재 사용중인 여러 P2P 프로토콜을 검토해서 새로운 프로토콜을 정의할 생각입니다. 현재는 전체적인 프로토콜 구조만 설정했고 세세한 내용은 프로그램 개발과 동시에 진행시킬 예정입니다. openx는 Open eXchange의 약자로 예쁜 이름을 못찾아서 프로젝트 명을 이렇게 정했습니다. 좋은 이름이 있다면 바꾸고 싶군요. openx의 프로토콜은 Napster와 Gnutella와 소리바다의 여러 프로토콜을 바탕으로 각각의 장점과 단점을 참고해서 설계했습니다. Napster는 반드시 서버에 접속해서 자신의 정보(다운로드,파일리스트 등)가 서버에서 관리되고, Gnutella는 완전히 분산형으로 설계됐지만 너무 많은 패킷이 생성되어 네트웍 속도를 저하시키는 단점이 있고, 사용해보면 상당히 느립니다. 소리바다는 이 둘의 중간형태입니다. 서버에 접속해서는 클라이언트(노드)들에 대한 정보만을 받는 듯하고 검색등은 클라이언트간 이루어집니다. 하지만 방화벽에 대한 고려가 부족하므로 방화벽 뒤에 있는 사용자가 제공하는 정보는 받기 힘든 단점이 있습니다.
openx 프로토콜 설계에서 중점을 두는 것은 다음과 같습니다:
서버의 역할은 클라이언트들의 주소를 제공하는 것으로, 클라이언트간 자체적으로 주소들을 교환하도록 해서, 별도의 서버에 접속이 필요없이 openx 사용이 가능하도록 할것입니다. 다른 클라이언트에 대한 정보가 없는 상황에서는 서버에 접속해서 리스트를 받을수 있도록 할 것입니다. 파일 전송 프로토콜은 Gnutella와 마찬가지로 HTTP를 사용할 것이며, 따라서 사용자의 취향에 맞는 다운로더나 브라우저를 사용하는 것이 가능합니다. openx는 모듈별로 개발될 것이며, 모듈 설계에 대한 문서는 정리가 되는데로 올릴 예정입니다.
openx 구현:
python에서 서버/UI 프로그램에 관심있는 분의 도움이 있었으면 좋겠네요. 또한 프로토콜 설계상의 문제점 등의 지적도 듣고 싶습니다. 아직은 설계 및 초기 구현 단계입니다. |
공지사항
