openx 디자인 문서 v0.1
개발자 노트 Posted by 1009 on Sunday November 05, @11:43PM

openx 프로토콜의 전체적인 설계와 openx를 구성할 모듈 들에 대해 설명한 글입니다.

처음 올리는 글이므로 자세한 내용은 없습니다.


openx는 클라이언트 노드 간 화일을 교환 할수 있는 프로토콜로 별도의 서버 접속없이 클라이언트 간 접속해서 실시간으로 검색하며, 다운로드가 가능하도록 설계한다.

다음은 전체적인 구조도이다

클라이언트는 크게 Backend(노드) 모듈과 Frontend(UI) 모듈로 나뉜다. 검색, 화일 제공 서버, 호스트(노드) 관리 등 핵심적인 부분은 모두 backend에서 담당하며 Frontend 모듈에서는 사용자 인터페이스를 제공한다. backend와 frontend는 각각 다른 프로세스로 실행되게 되며, TCP 소켓을 이용해 연결해서 frontend에서 검색등의 요구를 backend에 보내면 backend에서 모든 처리를 한후에 결과값만 frontend로 돌려주어 출력하도록 한다. 또한 frontend에서는 다운로드 기능이 포함될수 있지만 파일 교환 프로토콜은 기본적으로 HTTP를 사용하기 때문에 HTTP를 지원하는 임의의 다운로드 프로그램을 사용할수 있다.

다음은 각각의 모듈의 역할이다: (구현에 관련된 사항은 모두 제외했다)

  • Backend - Query/Response Module :
    다른 backend와 화일에 대한 정보를 교환한다. 다른 backend에서 들어오는 검색 요구에 대해서 Local Database에서 검색해서 결과를 돌려준다. 사용자의 요구가 있을때 다른 노드들에 검색요구를 하며 검색결과를 받는다. 검색 이외에 호스트가 살아있는지 체크할수 있고, 다른 호스트가 갖고 있는 노드 정보를 요구할수 있다. Query/Response는 UDP(User Datagram Protocol)로 구현하며 검색의 경우 결과가 없을때 응답을 보내지 않는다.
  • Backend - Host Manager :
    다른 노드들을 관리하는 역할을 한다. 노드에 대한 정보가 없을때는 Host list 서버에 연결하여 노드에 대한 정보를 받으며, 응답이 없는 노드에 대해서는 호스트 Database에서 제거한다.
  • Backend - Local Index Database :
    자신이 가지고 있는 화일들에 대한 정보를 관리한다.
  • Backend - Content Handler :
    화일의 종류(mp3, avi...)에 따라서 콘텐트의 정보를 정의하며, 화일에서 정보를 추출할수 있는 모듈을 포함한다. 추후에 화일 포맷을 추가 가능하다. 예를들어, mp3 화일의 정보는 가수, 곡명, 시간, 앨범, 장르 등이 포함되며, 검색의 경우 가수,곡명,앨범으로 검색이 가능하도록 정의할 수 있다.
  • Backend - File Server :
    파일을 제공하는 서버로써 HTTP 프로토콜을 사용한다.

  • Frontend - UI interface :
    TCP socket을 이용해 backend에 연결하여 검색등의 명령을 내려서 결과를 받는다.
  • Frontend - UI :
    사용자 유저 인터페이스를 제공한다.
  • Frontend - Download module :
    파일 다운로드 하는 모듈로 HTTP 프로토콜을 사용한다.

    openx에서 사용되는 프로토콜은 크게 4 종류이다:

    1. 파일 교환 - HTTP 프로토콜
    2. 노드간 query/response - UDP 프로토콜
    3. node-UI간 인터페이스 - TCP 프로토콜
    4. host list 다운로드 - ?
    호스트 정보 교환시 아직 어떠한 프로토콜을 사용할지 정하지 못했다. 이를 2번에 모두 포함시킬지 아니면 HTTP에 넣을지 아니면, 아예 다른 TCP 프로토콜을 사용할지 고민중이다...

    backend와 frontend를 분리해서 설계한 이유는 여러가지 있다:

    1. 먼저 backend와 frontend를 같이 구현하면 구현시 어려운점이 많다. http 서버를 구현할때 forking이나 threading을 이용해야 할텐데 이럴 경우 UI 코드가 섞여 있으면 많은 문제가 발생할 소지가 있다. (특히 forking 시) Threading 이용시 직접 실험해 본 결과 Tk를 사용할때는 크게 문제가 없었지만, Gtk를 사용했을때는 원하는 동작을 하지 않을 경우가 생겼다. 쓰레드는 가능하면 문제시 안되도록 설계하는게 나중에 디버깅에 유리하리라 생각한다.
    2. 분리를 하면 플렛폼에 최적화된 UI를 따로 설계가 가능하며 UI를 Python에 의존할 필요도 없어진다.
    3. 원격에서 접속해서 서비스를 이용할수 있다. 방화벽 안에 있는 사용자는 일반적으로 UDP 패킷을 받을수 없는 경우가 많다. 따라서 다른 사용자의 backend로 연결하여 검색을 하고, 다운로드는 직접 하면 backend를 제공하는 이에게 그리 큰 부담 없이 방화벽 뒤의 사용자도 서비스를 이용할수 있을것이다. 프록시(대리자)를 따로 만들어서 이런 서비스를 제공할수도 있을 것이다.

    아직 해결하지 못한 문제는 방화벽 뒤에서 제공하는 화일의 다운로드 방법이다. 넵스터에서는 푸쉬를 이용하며, 이럴 경우 방화벽 뒤의 사용자는 항상 방화벽 밖의 호스트와 TCP 연결을 맺고 있어야 한다. TCP 연결을 맺고 있어야 밖에서 요구가 가능하기 때문이다. 아직 이에 대해서는 더 생각해봐야할듯하다.


    여기까지 생각한 것들을 대략적으로 정리해봤습니다.. 좋은 의견 있으면 언제나 환영입니다 *^^*

    <  openx v0.0.1 소스 | openx 프로젝트 시작!  >

     

    		•
    ( Reply )