from "the RFB Protocol" (http://www.uk.research.att.com/vnc/rfbproto.pdf)
![[WWW]](http://kenial.net/wiki/img/moin-www.gif){kind=small}
http://www.uk.research.att.com/vnc/index.html)가 이 프로토콜에 기반하여 만들어졌다.
RFB는 thin Client 프로토콜이다. 클라이언트는 디스플레이/키보드/포인터(마우스같은)의 사용자 정보를 서버로 보내며, 서버는 Framebuffer의 정보(GUI 시스템, 애플리케이션)를 클라이언트로 전송한다.
RFB의 프로토콜은 다음과 같이 구성된다 ;
Display Protocol
RFB의 디스플레이 부분은 간단한 아이디어에 기반하고 있다 : "픽셀의 사각형 데이타를 주어진 x,y 좌표에 놓는다" 이 아이디어는 일견 많은 UI 컴퍼넌트들을 그리는 데에 비능률적으로 보인다. 그러나, 네트웍 대역폭이나 클라이언트의 디스플레이 능력, 서버의 프로세싱 속도등의 여러가지 요소를 놓고 흥정함에 있어서, 여러가지 방법의 픽셀 데이터에 대한 인코딩은 우리에게 높은 수준의 융통성을 제공했다.
이 사각형의 시퀸스는 framebuffer update를 만든다.
Input Protocol
키보드나 다버튼 포인팅 디바이스의 표준 웍스테이션 모델에 기반한다. 입력 이벤트들은 다른 비표준 입력기기로부터 만들어질 수 있다. (예를 들면, pda의 handwriting 같은)
픽셀 데이터의 표현 ; RFB 클라이언트/서버간의 상호작용은 보내질 픽셀 데이터에 대한 포맷과 인코딩에 대한 협상을 포함한다.
Raw/Copy rectangle/RRE/CoRRE/Hextile Encoding (생략)
프로토콜 메시지
보통 프로토콜 상호작용에 의한 초기 접속 단계를 거친 후 메시지를 주고 받게 된다.
초기 접속 메시지(Initial Handshaking Messages)
ProtocolVersion? ;
초기 접속은 서버가 클라이언트가 ProtocolVersion? 메시지를 전송함으로서 시작된다. 클라이언트로 하여금 서버에 의해 지원되는 가장 최신의 RFB 프로토콜의 버전을 알 수 있게 해준다. 클라이언트/서버가 하위 호환성의 어떤 버전을 제공할 수 있는지를 아는데 그 목적이 있다. 클라이언트는 실제로 사용될 수 있는 프로토콜의 버전 번호를 담은, 비슷한 메시지로 응답한다.
12바이트로 구성되며, 값은 다음과 같다 : "RFB 003.003\n" (Major ver. Minor ver.)
Authentication ;
프로토콜 버전이 정해지면, 서버는 연결에서 사용될 인증 스키마를 나타내는 워드를 전송한다. 4바이트로 구성된다. (CARD32)
0 - Connection Failed ; 실패의 이유를 나타내는 문자열의 길이/문자열 배열이 따라온다.
1 - no Authentication ; 인증 없이 ClientInitialisation? 메시지로 계속된다. 2 - VNC Authentication ; VNC 인증을 사용한다. 16바이트의 challenge가 클라이언트로 전송되고, 클라이언트는 challenge를 이용자에게 제공된 키로 패스워드를 사용해서 DES로 암호화하여 (16바이트로) 응답한다. 그러면 서버는 인증이 성공했는지의 여부를 나타내는 4바이트 워드를 전송한다. (0 OK;1 Failed;2 too-many)
ClientInitialisation? ;
서버/클라이언트가 서로에게 이야기할 상태가 되면, 클라이언트는 ClientInitialisation? 메시지를 전송한다.
1바이트의 Shared-flag로, 서버가 다른 클라이언트들이 작업한 데스크탑을 공유하려 시도하면 True, 다른 클라이언트의 모든 접속을 끊고 배타적인 액세스 권한을 주려고 하면 False이다.
ServerInitialisation? ;
서버는 ClientInitialisation? 메시지를 받으면, ServerInitialisation? 메시지로 응답한다. 이것은 클라이언트에게 프레임버퍼의 크기, 픽셀 포맷, 데스크탑과 관련된 이름을 알려준다.