VNC 뷰어 구현

Question

Google 팀에서 Windows에 VNC 뷰어 (= VNC 클라이언트)를 구현 중입니다. 프로토콜 (RFB)은 상태 저장 (stateful)입니다. 즉, 시청자가 1 바이트를 읽고 무엇인지 확인한 다음 3 바이트 또는 10 바이트를 더 읽고 구문을 분석해야합니다.

비동기 소켓과 단일 (UI) 스레드를 사용하기로 결정했습니다. 결과적으로 두 가지 방법이 있습니다 :

1) 상태 머신 - 소켓 읽기시 블록을 얻으면 현재 상태를 기억하고 종료합니다. 나중에 소켓 알림이 도착하고 인터럽트 된 로직이 적절한 단계에서 다시 시작됩니다.

2) 내부 메시지 루프 - 소켓에서 읽기가 차단된다고 판단되면 내부 메시지 루프를 시작하여 필요한 모든 데이터가 최종 수신 될 때까지 회전합니다. 블록의 경우 UI가 이와 같이 동결되지 않습니다.

경험에 따르면 두 번째 방법은 내부 메시지 루프에있는 동안 모든 메시지가 올 수 있으므로 좋지 않습니다. 여기에서 전체 내용을 말할 수는 없지만 단순히 신뢰할 만하지는 않습니다. 충돌과 불규칙.

첫 번째 옵션은 상당히 받아 들여질 수 있지만 이러한 스타일로 프로그래밍하는 것은 쉽지 않습니다. 알고리즘의 상태와 추가 처리에 필요한 모든 로컬 변수의 값을 기억해야합니다.

여러 스레드를 사용할 수는 있지만 프레임 버퍼 액세스 동기화, 멀티 스레딩 문제 등이 훨씬 더 어려울 것으로 생각했습니다. 비동기 소켓을 사용하는 것 또한 필요합니다.

그래서 어떤 점에서 최선이라고 생각하십니까?

문제는 상당히 일반적인 문제입니다. 이것은 상태 저장 프로토콜을 통한 비동기 통신 구성의 문제점입니다.

편집 1 : 우리는 C++과 MFC를 UI 프레임 워크로 사용합니다.

Answer 1

몇 가지 병렬 컴퓨팅 프로젝트를 수행했으며 MPI (Message Passing Interface)가 VNC 프로젝트에 도움이 될 것 같습니다. MPI가 제공하는 병렬 컴퓨팅 성능에 관심이 없을 지 모르지만 네트워크를 통한 비동기 통신을 위해 단순화 된 소켓 형 인터페이스를 사용할 수 있습니다.

http://www.open-mpi.org/

당신은 다른 MPI의 구현과 구글에서 사용 예제의 톤을 찾을 수 있습니다.

Answer 2

CSocket에 신경 쓰지 마십시오. 추가 제어 (중단, 종료 등)로 인해 결국 CAsyncSocket으로 이동하게됩니다. 또한 통신을 관리하기 위해 별도의 스레드를 사용하는 것이 좋습니다. 복잡성이 추가되지만 UI 응답 성을 유지하는 것이 최우선 적이어야합니다.

Answer 3

블로킹 소켓을 처리하기 위해 별도의 스레드를 사용하여 설계가 크게 단순화 될 것입니다.

주된 이유는 돌고 기다릴 필요가 없다는 것입니다. 네트워크 스레드는 아무것도 할 필요가 없을 때 차단하고, 할 일이있을 때 다시 돌아옵니다. 효과적으로 오버 헤드의 상당 부분을 OS로 오프 로딩합니다.

RFB는 많은 국가 정보가 필요하지 않음을 기억하십시오.클라이언트 대 서버 메시지가 짧기 때문에; 다음 포인터 입력을 보내기 전에 프레임 버퍼를받을 필요가 없습니다.

요점은 RFB의 메시지를 혼합 할 수 있다는 것입니다. 서버가 일정대로 작동합니다.

이제 Windows는 사용하기 쉬운 동기화 API를 제공합니다. 항상 가장 효율적인 것은 아니지만 목적에 충분하고 개념 증명을 쉽게 얻을 수 있습니다. Windows Synchronization을 (를)보고 구체적으로 Critical Sections

그냥 2cents, Windows에서 vnc 서버와 클라이언트를 모두 구현했습니다. 이것은 내 인상이었습니다.