GNP 에 대한 개요를 적었다.

GNP 란

Goodbye Network Part 의 약자로서, 본 프로젝트를 수행함으로서 DTV System 상에서 Network 기능에 대해 전문가 수준으로 이해하고, 새로운 일을 찾아 떠나기 위함을 목적으로 한다.

일정

금일(5/16) ~ 6月 限 : 실질적으로는 DV 이벤트가 시작되기 전까지다.

NM 의 문제점

  1. NM API 는 NM 프로세스와 IPC 로 통신한다. NM 은 M/W 로 동작하고, Application 에서 NM API 를 호출한다. 이는 NM API 를 호출하는 횟수가 증가할 수록 NM 프로세스는 Busy 하게 되고, 이는 전체적인 시스템의 성능에 영향을 줄 수 있다.
  2. NM 와 이벤트를 주고 받을 수 있는 것은 오로지 UI 뿐이다. UI Global Event Handler 에서 관장한다. 다시말해 비동기(Async)적인 이벤트를 말한다. 다른 Application 모듈에서 이러한 이벤트를 받기 위해서는 무조건 UI 를 거쳐야 한다.
  3. 유선 및 무선 네트워크 인터페이스 외에 다른 인터페이스의 추가가 어렵다. 처음 NM 설계 당시, 2 개의 인터페이스만 고려했기 때문에 추가를 위해서는 기존의 구조를 변경해야 한다.
  4. Exception 에러 처리가 제대로 되어 있지 않다.
  5. 네트워크 상태를 확인할 수 있는 Debug 메뉴가 부족하다. 양산 모델의 경우, Shell 진입이 어렵기 때문에 네트워크 상태를 파악하기 위해서는 이를 위한 Debug 메뉴가 필요하다.

해결 방안

  1. Shared memory 를 사용하여 Network status 가 변경될 시에만 Shared memory 의 정보를 업데이트한다. Application 들은 모두 read-only 이기 때문에 NM API 호출에 따른 오버헤드는 줄어들 것으로 생각된다.
  2. 다른 모듈에서 이벤트를 받기 위해, 이벤트 핸들러를 등록시킬 필요가 있다.
  3. USB to Ethernet 과 같은 추가적인 인터페이스에 대해 지원이 가능하도록 구조를 변경한다.
  4. IPC, API, NM 프로세스, 네트워크 상황에 대한 세부 오류 정의(Define)이 필요하다.
  5. 굳이 shell 모드에 진입하지 않더라도, 확인이 필요한 것들을 출력할 수 있는 debug 메뉴가 필요하다.
  • computer/lg/gnp_개요.txt
  • Last modified: 3 years ago
  • by likewind