작품설명서

1. 작품명

국문: 효과적인 동기식 협업을 지원하는 CoVNC 서버와 클라이언트

영문: CoVNC Server and Client Supporting Effective Synchronous Collaboration

2. 작품개요

Virtual Network Computing(이하 VNC)은 원격 제어 프로그램으로서 다른 지역에 위치한 시스템의 자원을 제어할 수 있는 기능을 제공한다. VNC는 Remote FrameBuffer(이하 RFB) 프로토콜을 사용하여 GUI(Graphic User Interface)를 통하여 원격 시스템의 자원을 효과적으로 제어할 수 있는 환경을 제공하며, 원격 시스템에 설치하는 서버와, 로컬 시스템에 설치하여 서버에 접속할 수 있도록 해주는 클라이언트로 구성된다.

1999년 VNC가 AT&T에서 개발되어 소스 내용이 공개된 이래, Real VNC, Tight VNC, Vine Server, Ultra VNC 등의 여러 버전이 공개되었다. 또한 이와 비슷한 Windows 플랫폼기반의 원격 제어 프로그램으로 Microsoft Windows XP, 2003등에 내장된 Remote Desktop 프로그램과 시만텍의 PcAnywhere 프로그램 등이 있다. 이러한 프로그램들은 Windows 플랫폼 간, 혹은 LINUX 플랫폼에서 사용가능한 버전이 존재하고 있으나, 다양한 플랫폼 간에 원격 제어를 하는데 있어서는 제약을 가지고 있다. 그러나 VNC 프로그램은 Mac OS 플랫폼에서 사용가능한 버전, PDA에서 원격시스템을 제어하는 것이 가능한 버전 등이 이미 배포되어 있으므로 다양한 플랫폼에서 사용할 수 있다. 그리고 VNC는 RFB 프로토콜을 사용하므로, 서버와 클라이언트가 주고받는 메시지는 플랫폼과 무관하다. 또한 VNC 프로그램의 한 종류인 UltraVNC의 경우, 서버 자체에 Java Applet Viewer를 내장하고 있어, 클라이언트가 웹 브라우저를 사용해 서버에 접속 할 경우, 별다른 클라이언트 프로그램을 설치하지 않아도 Applet Client를 사용해 서버를 제어하는 것이 가능하다.

현재 많은 사람들이 사용하고 있는 Windows XP 운영체제의 Remote Desktop 프로그램은 멀티세션을 지원하지 않아, 서버 시스템을 동시에 원격제어 할 수 있는 클라이언트는 하나로 제한되지만, VNC의 경우 멀티세션 기술과 상관없이 동작하므로 여러 클라이언트가 하나의 서버를 동시 제어 할 수 있다.

이러한 VNC의 특징은 효과적인 동기식 협업을 지원할 수 있는 장점이 된다. 따라서 VNC에서 사용하는 RFB 프로토콜을 확장하고, Ultra VNC를 확장하여 CoVNC 서버와 클라이언트를 설계하고 구현하였다.

3. 개발 배경 및 목적

컴퓨팅 환경에 있어서 점점 네트워크 환경의 발달로 인하여, 이와 관련된 원격 소프트웨어의 수요가 증가하고 있다. 또한, 원격 소프트웨어들을 이용해 언제 어디서든지, 네트워크 접속이 가능 해지고 있는 추세이다. VNC(Virtual Network Computing)는 이런 원격 소프트웨어에서 중요한 연구 테마 중 하나이다. 가장 오래되고 많이 사용되는 GUI 원격관리 시스템 중에 하나인 VNC는 공개 원격 관리 툴의 대명사라 할 수 있다. 이러한 VNC가 인기를 모으는 가장 큰 비결은 바로 다른 원격 관리 솔루션들이 주로 Win32 플랫폼에 국한된 기능을 구현하는데 반해, 무엇보다도 현존하는 거의 대부분의 플랫폼에 적용이 가능한 하드웨어에 독립적인 소스코드를 제공한다는 점이다. 즉 Win32플랫폼을 비롯해 솔라리스, 리눅스 등 다양한 종류의 유닉스 운영체제와 매킨토시, 윈도우CE 등의 사용자도 자신의 환경에 맞게 소스를 변경하거나 실행 환경에 맞게 컴파일 하여 사용할 수 있다는 것이다.

이러한 VNC는 기존의 전 세계의 정보를 자신의 PC로 끌어오는데 초점을 둔 타 Application과는 반대의 개념인 언제, 어디서든 자신의 PC(home environment)를 원격 제어할 수 있는데 초점을 맞춘 시스템이다. 현재 많은 곳에서 기존의 VNC 프로그램에 새로운 기능을 덧붙이고, 보안을 강화하고 있으며, 전문가가 아닌 사람들이 사용하기 쉬운 프로그램으로 VNC 프로그램을 발전시키고 있다. 이런 흐름에 발맞추어 단순히 서버 컴퓨터에 입력을 하고 입력 결과를 클라이언트 Viewer로 확인하는 것에 그치지 않고, VNC 프로그램을 확장하여 분산 협업 환경에 적용함으로서 새로운 부가가치를 창출하는 도구를 개발하도록 하였다. 이는 비단 VNC가 제시하는 Virtual Network Computing 환경을 이해하는 것뿐만 아니라, 향후 우리가 나아가야 할 컴퓨팅 환경이 어떤지, 어떠해야 하는지에 관한 안목을 넓혀 줄 것이라 생각한다.

실제 기존의 VNC에서 ‘XML을 이용한 서버 설정 저장 파일’ 기능은 서버의 다양한 설정이(인증 암호, 접속 포트, 접속할 Display 세션의 수, 클라이언트의 입력을 무시하는 등) 사용자들에게 VNC를 사용할 때 어렵다고 느껴질 것이라고 예측하고, 이에 다양한 서버 환경을 제공해야 할 때 마다 서버 설정을 일일이 바꾸어 주어야 작업이 사용자에게 무리가 있다고 판단하여 이러한 서버 설정을 저장하여 사용자들의 편리와 어려움을 줄이려는 목적으로 구현하게 되었다.

또한 'XML을 이용한 One Click 접속' 기능은 클라이언트가 단 한 번의 프로그램 실행으로 원하는 서버에 바로 접속 할 수 있도록 하기 위한 목적으로 서버 측에서 만든 서버설정(Preset)파일만 있으면 쉽게 접속을 할 수 있는 기능이다. 이 기능은 윈도우 Remote Desktop의 자주 접속하는 서버의 접속 환경 정보와 로그인 정보를 특정형식의 파일에 저장 하여 이 파일을 클릭하면 쉽게 접속하는 기능을 참고한 것이다.

‘Java Viewer를 수정하여 번거로운 클립보드 공유 기능의 간소화’ 기능과 ‘RFB 프로토콜의 확장을 통해, 서버와 클라이언트간의 클립보드 공유기능을 확장한 클립보드 이미지 공유’ 기능은 기존의 VNC에서 Clipboard가 Window Remote Desktop에서처럼 투명하게 처리되지 않고 중간에 매개역할을 하는 작은 창은 통해서 Client와 Server간의 공유가 가능하다는 점을 파악하고, 이 점이 Client의 Clipboard의 내용을 Server가 모르는 문제점으로 판단하였으며, 또한 일반적으로 사용자들이 익숙하게 사용해온 Clipboard(예를 들면 워드프로세스에서 사용하는 Clipboard)와 다르다고 느껴지는 것이 사용자들에게 사용을 꺼리게 할 것이라고 생각하였다. 이러한 점을 종합하여 클립보드를 윈도우 Remote Desktop 수준으로 개선하고 문자만 공유가 가능한 점을 이미지 데이터까지 공유가 가능하도록 하는 것을 목적으로 하였다.

다음으로 ‘서버 제어 권한별 클라이언트 구분 및 접속’ 기능과 ‘RFB 프로토콜의 확장을 통해, 클라이언트를 효과적으로 관리’ 기능은 VNC Server에 접속한 Client를 효율적으로 관리하기 위함과 VNC를 이용한 실시간 분산 협업시 그룹 구성원들 간의 원활한 작업은 물론이고 보안을 강화하기 위한 목적이다. 예를 들어 특정 목적으로 작업을 할 시 함께 하는 구성원들 이외의 Client가 접속하였을 때 작업에 문제를 일으키는 일이 발생할 수 있는 문제점을 방지하기 위한 목적이라 할 수 있다.

4. 주요 개발 내용

◯ XML을 이용한 서버 설정 저장 파일

◯ XML을 이용한 One Click 접속

◯ Java Viewer를 수정하여 번거로운 클립보드 공유 기능의 간소화

◯ RFB 프로토콜의 확장을 통해, 서버와 클라이언트간의 클립보드 공유기능을 확장한 클립보드 이미지 공유

◯ 서버 제어 권한별 클라이언트 구분 및 접속

◯ RFB 프로토콜의 확장을 통해, 클라이언트를 효과적으로 관리

4-1. 프로그램의 기능

◯ XML을 이용한 서버 설정 저장 파일

VNC 서버는 인증 암호, 접속 포트, 접속할 Display 세션의 수, 클라이언트의 입력을 무시하는 등의 기본적인 설정을 포함하여, 서버의 바탕화면에 설정된 배경그림을 배제하거나, 파일 전송 기능 가능하게 하거나 하는 등의 다양한 설정을 할 수 있다. 이러한 서버 설정은Registry를 사용하여 저장한다. 그런데 VNC 서버의 다양한 설정 메뉴들이 VNC를 자주 접해보지 못한 사용자들이 VNC를 활용할 때 어려운 점으로 작용할 수 있고, 다양한 서버 환경을 제공해야 할 때 매번 서버 설정을 일일이 바꾸어 주어야 하므로 사용자로 하여금 번거로운 작업이 될 수 있다. 따라서 이러한 서버 설정을 저장하여 누구든지 언제든 서버 설정 파일을 불러오는 것만으로 서버 설정을 할 수 있고, 다양한 서버 설정 저장파일을 불러올 수 있도록 함으로써, 좀 더 다양한 VNC 서버를 실행 할 수 있도록 구현하였다.

VNC의 윈도우 구현은 Win32 Application Programming Interface를 사용하여 작성되었다. WinVNC클래스에는 윈도우 프로그램의 메인함수인 WinMain()이 있고 vncMenu클래스에는 윈도우 정보를 저장하는 WNDClass structure, 윈도우를 생성하는 CreatWindow(), 윈도우 메시지를 처리하는 WndProc()가 있으며, VNCPropertise클래스에는 설정 윈도우를 구현하고 이벤트를 처리하는 DialogProc()로 구성되어 있다.

[그림 ] VNC에 구현된 윈도우 구조

실행은 WinMain()을 기반으로 각 정보가 저장되어진 structure를 CreatWindow()함수로 불러들이고, 그 후 WndProc() 함수가 메시지 처리를 한다. VNC는 트레이 아이콘 형태의 윈도우 프로그램으로 실행이 된다. 이 트레이 아이콘을 더블클릭해서 실행되는  VNCPropertise클래스는 DialogProc() 함수가 창을 실행시키고 각종 이벤트를 처리한다. 따라서 서버의 설정 내용을 저장하고 불러오는 인터페이스를 구현하기 위해서는 VNCPropertise클래스를 다루어야 한다.

VNCPropertise dialog에 'SAVE' 및 ‘LOAD' 버튼을 추가하여 각 버튼을 클릭했을 때 이벤트를 처리하도록 추가 구현하였다. VNCPropertise클래스의 이벤트 처리 함수인 DialogProc() 함수에서 처리한다. 'SAVE'버튼을 클릭했을 때, File Dialog에서 XML문서를 이름을 지정하도록 하고, VNCPropertise클래스에서 각 컴포넌트의 설정된 값을 읽어 들이고, 읽어 들인 값을 XML 문서로 저장한다. 단, VNC서버에 접속에 필요한 암호는 저장하지 않는다.

[그림 ] SAVE 버튼과 이벤트 처리 추가

저장된 파일의 확장자는 클라이언트가 서버 설정파일을 이용해 원클릭 접속이 가능하도록, 'xml'이 아닌 'pslvnc'으로 하였다. 저장하여 생성된 XML 문서의 각 Element의 이름은 VNCPropertise클래스에 배치된 컴포넌트 ID가 되고, 컴포넌트의 값은 Element의 Text 요소에 저장하도록 하였다.

'LOAD'버튼을 클릭했을 때, File Dialog에서 XML문서를 선택하도록 하고, 선택한 XML문서를 MSXML parser를 사용하여 불러들이도록 구현하였다. MSXML parser의 DOM API를 사용해 XML문서를 분석하여 트리구조를 만들고, 각 Element 이름에 해당하는 VNCPropertise클래스 컴포넌트 ID를 찾는다. 그리고 Win32 API의 SendDlgItemMessage()함수를 사용하여 Element의 Text 요소에 저장된 값을 컴포넌트에 설정한다.

◯ XML을 이용한 One Click 접속

1) Preset 파일 선택 할 수 있게 구현

기존의 VNC Java viewer는 Application 모드에서 main()메소드의 파라미터가 없을경우 Exception 객체를 생성하여 사용자에 Exception 내용을 알린 후 프로그램을 자동 종료 시킨다. 우리는 이를 개선하여 main() 메서드 파라미터가 없을 경우 자동으로 Preset XML 파일을 선택할 수 있게 프로그램 구조를 변경하였다. 다음 [그림3]은 변경한 프로그램 구조이다.

[그림 3] VNC Viewer의 실행 흐름

서버에서 배포된 여러 Preset 파일을 사용자가 직접 선택 할 수 있게 하기 위해서 javax.swing.JFileChooser를 사용하였다. JFileChooser를 통해서 사용자가 Preset 파일을 선택하면 그 파일 정보를 XML 파서로 넘겨주는 방식이다.

XML 파서는 DOM과 SAX 두 가지 방법이 있는데 Preset의 경우 XML 문서 구조 자체가 관심 사항이 아니기 때문에 처리 속도가 빠른 SAX 파서를 사용하였다. JAXP에서 SAX 프로그래밍 구현 절차는 다음 [그림 4]와  같다.

[그림 4] SAXParser를 이용한 XML문서 Parsing

여기서 XMLReader클래스 setContentHandler 메서드의 파라미터로 이벤트 핸들러가 구현된 객체를 넣어 주면 해당 이벤트 핸들러가 구현된 된다. 이벤트 핸들러는 XML문서를 처리하는데 기본적으로 필요한 대부분의 이벤트를 제공하는 ContentHandler 인터페이스를 사용하였다.

이렇게 파싱된 정보는 서버 접속을 위해 쓰이며 사용자는 Client viewer 프로그램 실행 시 매번 연결정보를 입력하던 번거로움 없이 미리 설정된 Preset 파일을 통해서 쉽게 VNC 서버에 접속 할 수 있다.

2) MS Remote Desktop의 rdp(Remote Desktop Protocol)파일처럼 구현하기

다음 [그림 5]의 코드는 CoVncViewer 클래스의 main(String args[]) 메서드를 수정한 것이다.

[그림 5] CoVncViewer 클래스의 main(String args[]) 메서드의 수정

위[그림 5]를 보면 mainArgs 배열의 길이가 0보다 큰지 비교 한다. 즉 main()의 인자가 있는지 확인하는 것이다. 그리고 인자의 개수가 하나인지 비교하는데 이는 인자가 하나일 경우 인자의 이름이 preset 파일 이름으로 처리 하라는 것이다. else문은 main() 메서드의 여러 인자가 서버 접속 정보일 때 처리하라는 구현이다.

다음으로 Java Application을 윈도우에서 바로 실행 가능한 exe 확장자의 파일로 만들어야 한다. 이 작업은 볼랜드 사의 JBuilder를 사용하여 쉽게 구현할 수 있다. 다음으로 아래 [그림 6]처럼 pslvnc 파일의 속성 창을 열어 연결 프로그램을 등록해 준다. 이렇게 하면 rdp 파일처럼 더블클릭만으로도 서버에 쉽게 접속할 수 있다.

[그림 6] pslvnc 파일의 속성

◯ Java Viewer를 수정하여 번거로운 클립보드 공유 기능의 간소화

클립보드 자동화를 위해서는 클라이언트의 클립보드 내용 변경사항을 감지하는 리스너가 필요하다. 하지만 현재 java.awt.datatransfer 패키지에는 클립보드데이터 타입의 변경만을 감지하는 리스너뿐이다. 그래서 WindowsListener의 window Activated()를 사용하여 이 문제를 해결하였다. 즉 사용자가 Ctrl + C 은 사용해 클라이언트의 클립보드 내용을 복사하고 다시 VNC viewer로 돌아올 때 window Activated(WindowEvente)가 호출되는 원리를 사용한 것이다.

다음 [그림 7]은 새로 설계해서 추가한 AutoClipboard 클래스이며 UML은 다음과 같다.

[그림 7] AutoClipboard 클래스의 UML

setCutTest2Server()는 클라이언트의 클립보드 내용을 서버로 전송하는 메서드이고 setCutText2Client(Stringtext)는 서버로 부터 받은 클립보드 내용을 클라이언트로 전송해 주는 메서드이다.

◯ RFB 프로토콜의 확장을 통해, 서버와 클라이언트간의 클립보드 공유기능을 확장한 클립보드 이미지 공유

Ultra VNC를 비롯한 여러 VNC 프로그램과 Remote Desktop 프로그램은 로컬 시스템과 원격 시스템 서로간의 클립보드 내용을 공유할 수 있는 기능을 제공하고 있다. 클립보드는 사용자가 임의로 선택한 데이터를 잠시 복사해두는 임시 기억공간을 말하며, 사용자는 클립보드에 복사한 데이터를 필요에 따라 클립보드에서 꺼내어 사용할 수 있다. 따라서 클립보드를 사용하면 컴퓨터를 이용한 다양한 작업에서 데이터를 입력하고 수정하는 일을 효율적으로 진행해 나갈 수 있다. Remote Desktop의 경우 원격 시스템과 로컬 시스템간의 클립보드를 공유하여 문자뿐만 아니라 이미지, Windows 오브젝트와 같은 다양한 형태의 데이터를 공유하여 사용할 수 있다. 여러 가지 형태로 공개된 VNC 프로그램 역시, 클립보드 공유가 가능하지만, Remote Desktop와는 달리 유니코드 문자만 공유가 가능하다. 때문에 VNC를 활용하여 서버와 클라이언트 간에 이미지 데이터를 공유할 수 없다.

RFB 프로토콜은 서버와 클라이언트가 클립보드에 저장된 문자열 내용을 서로 주고받을 수 있도록 정의하고 있다. 그리고 이미지의 데이터는 BITMAP이라는 플랫폼에 독립적인 형식으로 다룰 수 있다. 따라서 BITMAP 형식으로 저장된 이미지 데이터를, 서버와 클라이언트가 클립보드에 저장된 BITMAP 내용을 서로 주고받을 수 있도록 확장하여, 서버와 클라이언트가 클립보드 이미지를 공유가능 하도록 구현하였다.

모든 RFB 프로토콜 메시지는 메시지 유형(message-type)을 나타내는 헤더로 시작되며 메시지의 내용이 담긴 데이터(message-specific data)가 뒤 따른다. 따라서 클립보드 이미지 전송을 위해서는 먼저 message-type에 사용할 value를 정해야한다. 또한 이미지 전송을 위한 프로토콜은 서버에서 클라이언트로 전송하는 프로토콜과 클라이언트에서 서버로 전송하는 프로토콜을 각각 정의해야 한다. RFB Protocol Version 3.6버전에서는 클라이언트에서 서버로 전송할 때 사용하는 프로토콜 message-type의 경우, unsigned byte 형식으로 0~6, 255를 제외한 값을 사용할 수 있고 서버에서 클라이언트로 전송할 때 사용하는 프로토콜 message-type의 경우, unsigned byte 형식으로 0~3,255를 제외한 값을 사용할 수 있다. 다음 [표 1]은 클립보드 이미지를 전송할 때 사용하는 프로토콜을 정의 한 것이다. message-type의 경우, value를 100으로 정했으며, 서버에서 클라이언트 전송 할 때와 클라이언트에서 서버로 전송할 때 사용되는 구조는 동일하도록 정의하였다.

확장한 RFB 프로토콜을 바탕으로 서버에서 클라이언트로 클립보드 이미지를 전송하는 것과 클라이언트에서 서버로 클립보드 이미지를 전송하도록 하여, 클립보드 이미지 공유를 구현하였다.

[표 1] 클립보드 이미지 전송을 위해 사용할 프로토콜의 구조

No. of bytes	Type [Value]	Description
1	U8 100	message-type
3		padding
4	U32	length
length	U8 array	image

서버에서 클라이언트로 클립보드 이미지를 전송을 구현하기위해 먼저 서버 운영체제의 클립보드에 저장된 이미지를 추출하였다. 서버가 실행되는 플랫폼인 Windows의 클립보드 이미지는 DDB(Device Dependent Bitmap) 형식으로 존재 하므로 다른 플랫폼의 클라이언트에게 전달하기 위해서 DIB(Device Independent Bitmap)으로 변환하는 과정이 필요하다. 또한 기존 RFB 프로토콜에 추가한 ServerCutImage 프로토콜은 이미지 데이터를 바이트 배열로 형식으로 전송하므로, DIB으로 변환한 이미지를 바이트 배열의 형식으로 만든다.

ServerCutImage 프로토콜을 전송받은 Java 클라이언트 프로그램은 바이트 배열 형식의 이미지 데이터를 java.image형태로 바꾸고, Java Virtual Machine 클립보드에서 사용가능한 java.awt.datatransfer.Transferable 형태로 만들어 클라이언트의 시스템이 가진 클립보드에 적용하도록 한다.

클라이언트에서 서버로 클립보드 이미지를 전송을 위해 JVM을 이용해 클라이언트 운영체제의 클립보드에서 이미지를 추출해낸다. Java 클라이언트가 활성화 될 때, 클라이언트 시스템의 클립보드의 내용을 분석하여, 클립보드의 내용이 이미지일 경우 java.awt.datatransfer.Transferable 형태로 이미지 내용을 얻는다. java.awt.datatransfer.Transferable형태의 이미지를 다시 java.awt.image.BufferedImage 형태로 변환하고 이것을 ClientCutImage 프로토콜을 사용해 서버로 전송하기 위해 ByteArrayOutputStream형태로 변환하여 서버로 전송한다. 이때 전송되는 이미지 형태는 DIB 형태이다. 서버는 클라이언트로부터 전달받은 ClientCutImage 프로토콜에서 바이트 배열 형식으로 전달된 내용을 추출하여 다음 [그림 8]과 같은 DIB Memory Block을 만들고 원격 시스템의 클립보드에 적용한다.

[그림 8] 바이트 배열에 저장된 이미지 내용을 DIB Memory Block에 적재

[그림 9]

LINUX (Client) <-> Windows XP (Server) 클립보드 이미지 전송의 예

[그림 10]

Windows XP (Client) <-> Windows XP (Server) 클립보드 이미지 전송의 예

◯ 서버 제어 권한별 클라이언트 구분 및 접속

동기식 실시간 협업을 살펴보면 진행 과정마다 모든 클라이언트가 참여해야하는 것은 아니다. 특정 클라이언트가 업무 과정을 완료하면, 다음 업무 과정을 처리할 클라이언트가 업무를 처리하는 협업이 있을 수 있다. 이때 다음 업무 과정을 처리할 클라이언트는 이전 과정을 지켜보는 것으로, 비동기식 협업시 문제가 되는, 진행상황을 분석시간을 줄일 수 있다.

서버 자원을 제어할 수 있는 클라이언트와 입력을 하지 않고, 진행과정을 모니터하는 클라이언트를 나누면, 현재 진행 과정에 참여하는 클라이언트를 확실하게 구분할 수 있으며, 진행 과정에 참여하지 않는 클라이언트의 불필요한 제어를 무시할 수 있어 효율적이다.

기존의 VNC에는 서버 자원을 제어할 수 있는 접속 환경과, "View Only"라고 하는 서버 자원을 제어할 수 없으며, 서버에서 일어나는 일을 지켜보기만 하는 접속환경을 제공하고 있다. 그러나 이러한 접속환경은 모두 클라이언트 사용자의 선택에 의해서 작동하며, 서버에서는 이런 클라이언트들을 별도로 구분하지 않는다. 그리고 별도의 작업 진행자가 존재하지 않고, 클라이언트 사용자의 선택에 의해 협업 진행자가 결정되므로 이것만으로 효과적인 협업 작업을 수행하기에는 무리가 있다.

효과적인 동기식 협업이 이루어 질 수 있도록, 접속 환경이라는 개념을 제어 권한의 개념으로 변경하고, 서버에서 클라이언트의 제어 권한을 관리 할 수 있도록 구현하였다. 새로이 구현한 제어 권한의 내용은 다음 [표 2]와 같다.

[표 2] 제어 권한

세부사항 권한명	암호 및 서버 설정 변경	접속한 클라이언트 관리	서버 자원 제어	서버 모니터링
Admin	◯	◯	◯	◯
Full Access	X	X	◯	◯
View Only	X	X	X	◯

기존 VNC의 경우 접속을 위해 별다른 ID없이 하나의 암호를 사용했지만, 새롭게 세 가지 제어 권한을 나누었으므로 기존의 암호를 Admin 권한으로 접속하기 위한 암호로 사용하고, Full Access 권한으로 접속하기 위한 암호와, View Only 권한으로 접속하기 위한 암호를 추가하여 세 개의 암호가 존재하도록 하였다. CoVNC 서버의 암호는 Windows Registry에 저장하므로 Registry에 새로운 두 암호를 저장할 키를 생성한다. 그리고 CoVNC 설정 Dialog에 Full Access의 암호와 View Only의 암호를 입력 받을 수 있는 Edit Box를 추가한다. 기존 VNC 접속을 위해 사용하는 암호는 Admin의 암호로써 사용하도록 구현했다. 그리고 입력한 암호들이 서로 같은지, 현재 서버에서 사용하고 있는지를 검사한다.

[그림 11] Full Access와 View Only 권한으로 접속하기 위해 필요한 암호를 설정하는 부분

Registry에서 저장된 세 가지 암호는, CoVNC Server가 실행될 때 생성되는 vncserver 클래스 객체의 멤버변수에 저장된다. vncserver클래스는 CoVNC에서 클라이언트의 접속을 관리하며, 클라이언트가 접속하면 해당하는 클라이언트를 관리하는 vncclient 클래스의 객체를 만들어 vncclientList 클래스에 vncclient를 추가한다. 클라이언트에 대한 제어가 필요할 때 vncclientList에서 vncclient객체를 찾아내고, 객체에 대한 적절한 제어를 함으로써 관리한다. 또한 vncserver클래스는 vncproperties 클래스에 설정된 서버 설정 내용을 바탕으로 서버를 구동한다. 따라서 CoVNC 서버가 한 시스템에서 작동한다면 하나의 vncserver 객체가 생성되어있는 것이다.

클라이언트가 서버의 IP와 사용하는 PORT를 입력하여 서버에 접속을 하면 우선 m_unauthclients라는 vncclientList 객체에 추가되어 관리되고, 클라이언트가 암호를 입력하고 암호화해서, 서버에 전송하면 다음 그림과 같은 절차를 거쳐 인증을 받고, 인증이 완료되면 m_unahthclients에서 제거되고 m_authclient 객체에 등록된다.

[그림 12] 서버가 요청한 암호에 대한 클라이언트의 Response(클라이언트가 입력한 암호)를

바탕으로 한 인증과정

서버가 클라이언트에게, 클라이언트가 입력한 암호에 해당하는 제어권한을 할당하면, 서버는 클라이언트에게 스스로의 제어권한을 저장하도록 하고, 서버는 그것을 참조하여  앞으로 클라이언트가 서버에게 전달하는 제어 내용이 제어권한에 합당한지 알 수 있도록 해야 한다. 그리고 클라이언트에게 할당한 제어권한을 전송해주도록 하였다. 그래서 vncclient 클래스에 제어권한을 저장하는 멤버변수를 추가 하였으며, RFB 프로토콜의 AuthResponse 정의 부분을 확장하였다. vncclient에 추가한 맴버변수에도 할당한 제어권한에 따라 AuthResponse 정의 부분을 확장한 값을 저장하도록 구현하였다. 다음 [표 3]은 AuthResponse 정의를 확장한 내용과 인증에 따라 vncclient 제어권한을 저장하는 m_authmode변수에 저장되는 값의 내용이다.

[표 3] AuthResponse의 확장 정의

define	value	비고
VncAuthOk	0	Admin 인증
VncAuthFailed	1	인증 실패
VncAuthTooMany	2	인증 실패가 너무 많이 일어남
VncAuthFullAcc	3	Full Access 인증(추가)
VncAuthViewOnly	4	View Only 인증(추가)

View Only 권한을 구현하기 위해 클라이언트의 포인트 입력(마우스 입력)과 키보드 입력을 무시하거나 허용하는 것을 설정 할 수 있는 vncclient 클래스 맴버 함수인 EnablePointer() , EnableKeyboard() 함수에 boolean false를 전달함으로써 구현할 수 있다. 그리고 VncAuthOk를 전달받은 클라이언트는, Disable 되어있던 클라이언트를 제어할 수 있는 기능을 Enable 시킨다.

Full Access 권한의 클라이언트는 서버 설정에 관여할 수 없다. 따라서 서버 설정창을 띄우거나 서버를 종료하기전에 Admin 권한의 암호를 묻는 부분을 추가하였으며, 서버 설정 중에는 Full Access 권한의 클라이언트가 전송하는 입력을 무시하도록 구현 하였다. 서버 설정 중에 입력이 무시된 Full Access 클라이언트는 서버 설정이 끝나면 다시 입력을 허용하도록 하였다.

[그림 13] 서버 설정을 하기 전, 암호를 입력받는 Dialog

◯ RFB 프로토콜의 확장을 통해, 클라이언트를 효과적으로 관리

팀원이 아닌 클라이언트가 접속했을 때 그 클라이언트의 접속을 끊거나, 작업의 진행에 있어서 투입될 클라이언트를 분류해야 할 때가 있다. 클라이언트의 서버에 대한 제어권한을 서버가 검색 할 수 있도록 VNC 서버를 확장한 기능을 이용하여, 클라이언트를 관리하는 Admin 제어 권한의 클라이언트가 전송할 때 사용할 메시지를, RFB 프로토콜에 새롭게 정의 하였다.

1. RFB 프로토콜의 확장

Admin 클라이언트가 클라이언트를 관리하는데에 필요로 하는 기능을 먼저 생각해보자면, 접속한 클라이언트들의 정보를 알 수 있도록 하는 기능, 그러한 정보를 이용하여 클라이언트의 접속을 해제하거나 Full Access 클라이언트와 View Only 클라이언트간의 제어권한을 변경 할 수 있는 기능을 생각했다. 이러한 기능 구현을 위해 서버가 Admin 클라이언트에게 메시지를 전송할 때 사용할 새로운 RFB 프로토콜의 내용을 정의 했다. 다음 [그림 14]는 서버가 Admin 클라이언트에게 클라이언트 목록을 전송 할 때 사용할 RFB 프로토콜의 정의다.

[그림 14] 클라이언트 목록 전송을 위한 ClientList 메시지 정의

첫 1바이트는 전송하고자 하는 메시지가 어떤 역할을 하는 지 알 수 있도록, 메시지의 유형을 표시하는데 사용한다. 클라이언트 목록을 전송하는 메시지임을 알리기 위해 101이라는 새로운 값을 정의하였다. 그리고 1바이트의 여유 공간을 둔 후, 클라이언트 목록의 전체 길이를 4바이트 크기로 전송하고, 그 길이만큼의 XML 내용을 바이트 배열에 담아 전송하도록 하였다. 클라이언트의 목록은 XML 형식은 Type과 IP라는 Attribute에, 접속한 클라이언트의 정보를 저장하여 바이트 배열의 형식으로 전송한다.

[그림 15] XML으로 만들어진 클라이언트 목록의 예

다음 [그림 16]은 Full Access 에서 View Only 혹은 View Only에서 Full Access 권한으로 변경할 때 쓰이는 RFB 프로토콜의 rfbAdminRequest정의를 보여주고 있다. 이 RFB 메시지는 클라이언트에서 서버로 전달된다. 첫 1바이트는 전송하고자 하는 메시지가 어떤 역할을 하는 지 알 수 있도록, 메시지의 유형을 표시하는데 사용한다. 클라이언트의 변경하는 메시지임을 알리기 위해 150이라는 새로운 값을 정의하였다. 그리고 3바이트의 여유 공간을 둔 후, 클라이언트 목록의 전체 길이를 32바이트 크기로 전송하고, 그 길이만큼의 XML 내용을 바이트 배열에 담아 전송하도록 하였다. 변경하는 클라이언트의 목록은 XML 형식으로 하며, Type에는 새롭게 할당할 제어 권한, IP는 할당할 클라이언트로 Attribute로 설정하여 바이트 배열 형식으로 전송한다.

[그림 16] 권한 변경을 요청할 때 쓰이는 rfbAdminRequest정의

2. 서버 구현

CoVNC 서버에 접속한 클라이언트하나하나 마다 vncclient 클래스의 객체가 생성되어, 그 객체를 통해 하나의 클라이언트에서 전송하는 명령을 읽어 들이고, 명령에 따른 결과를 전송하도록한다. vncclient 객체는 vncclient의 내부 클래스인 vncclientThread를 이용해 이런 과정을 수행하며, vncclientThread 클래스는 omnithread를 상속하여 구현 되어있다.

vncserver 클래스는 앞에서 언급한대로 vnclientList 객체를 이용해 vncclient 객체를 얻어 서버에 연결된 클라이언트를 검색하고 제어할 수 있다. 얻어낸 vncclient 객체에서 클라이언트의 제어권한과, IP를 얻어 XML형식 목록을 만든다. 그리고 vncclientList에 연결된 vncclient 객체 중에 Admin 제어권한인 클라이언트를 찾아내어, 만들어둔 XML을 해당 클라이언트의 vncclient 객체를 이용해 새롭게 정의한 ClientList RFB 프로토콜을 이용해 전송하도록 한다.

[그림 17] Admin 클라이언트를 찾아 클라이언트 목록을 전송하는 과정

클라이언트로부터 rfbAdminRequest 메시지를 전송받은 서버는 전송된 XML을 MSXML Parser를 이용하여 변경하고자 하는 클라이언트의 IP와 권한 내역을 얻어낸다. IP를 이용해 vncclient 객체를 추출해내고 m_authmode 맴버변수의 값을 변경함으로써 제어권한을 변경한다. 이때 View Only로 권한을 변경할 경우 EnablePointer() , EnableKeyboard() 함수에 false를 전달하고, Full Access로 권한을 변경할 경우 EnablePointer() , EnableKeyboard() 함수에 true를 전달한다. 그리고 새로운 클라이언트 목록을 만들어 Admin 클라이언트에게 전달한다.

클라이언트의 접속을 끊는 요청에서는 vncclient 클래스의 Kill() 함수를 사용한다. vncclient 클래스 객체는 객체에 물려있는 클라이언트가 접속을 해제 했을 때 스스로를 소멸 시킬 수 있는 함수가 두 가지 존재하는데, Remove()와 Kill()함수가 그것이다. Remove()함수는 스스로 소멸을 요청할 때 쓰이며, Kill()함수는 다른 객체가 소멸을 요청할 때 쓰인다. 클라이언트의 접속을 끊으면 새로운 클라이언트 목록을 만들어 Admin 클라이언트에게 전송한다. 또한 새로운 클라이언트가 접속을 하고 세 가지 권한 중의 하나를 획득해 m_authClients에 등록되면 새로운 클라이언트 목록을 Admin 클라이언트에게 전송해 주어야 한다.

3. 클라이언트 구현

Java viewer 실행후 Admin 패스워드로 접속하면 아래와 같은 User Control 프레임 창을 실행 할 수 있다.

[그림 18] User Control 프레임

User Control Frame은 현재 접속된 User type과 IP 리스트를 서버로부터 받아 JTable에 보여주며 접속된 다른 사용자를 선택 후 접근 권한과 접근제한을 할 수 있다. 서버와 클라이언트는 RFB 프로토콜에 XML 타입의 요청자료를 교환하며 클라이언트가 서버로부터 클라이언트 리스트를 받아 처리하는 내용은 아래 [그림 19]의 readClientListXml()메서드가 처리한다.

[그림 19] readClientListXml() 메서드

반대로 클라이언트가 서버에게 요청할 때는 아래의 [그림 20]의 writeAdminClientRequest() 메서드가  처리한다. 요청 XML의 경우 그 내용이 단순하기 때문에 JAXP를 사용하지 않고 String에 XML문을 미리 넣고 Attribute 값만 추가하여 구현 하였다.

[그림 20] writeAdminClientRequest() 메서드

권한변경 요청의 경우 변경할 대상의 클라이언트 IP와 변경 후 접속권한을 XML에 담아 서버에게 요청하며 접속 해제 요청의 경우 해당 클라이언트 IP와 "Drop" 값을 담아 서버에게 요청한다.

4-2. 시스템 구성

1) 하드웨어 구성(구성도 포함)

서버 : IBM 호환 Intel Xeon Server System

클라이언트 : IBM 호환 Intel Pentium 4 Personal Computer System X 2

LCD 모니터

키보드, 마우스

2) 소프트웨어 구성(구성도 포함)

서버 :

○ Microsoft Windows NT/XP Family 운영체제
(Windows 2003 Server Standard Edition Service Pack 1)

○ Microsoft Visual C++ 6.0 Intergrated Developement Environment & Compiler
○ Microsoft MSXML parser 6.0

○ Ulsan Univ. Programing System Lab. CoVNC Server

클라이언트 :

○ Microsoft Windows NT/XP Family 운영체제
(Windows XP Professional Edition Service Pack 2)

○ Cent OS (Redhat Linux 호환 운영체제)
KDE X-window System

○ Java Development Kit Standard Edition 1.4 이상

○ JBuilder IDE & Eclipse IDE

○ Microsoft Internet Explorer 6.0 & Mozila Firefox 2 웹브라우저

○ Ulsan Univ. Programing System Lab. CoVNC Client

3) 주요 흐름도

1) 서버 설정 저장 및 불러오기

저장

불러오기

2) 클립보드 이미지 전송

서버 -> 클라이언트

클라이언트 -> 서버

3) 암호 중복 검사

4) 클라이언트의 접속

5) 클라이언트 권한 변경

6) 클라이언트 목록 재전송

클라이언트 추가 접속 시

클라이언트의 접속 해제 시

5. 제작 일정

(제작기간 : 2006. 9. ～ 2007. 6.)											담당학생
제작내용	월 별
	9월	10월	11월	12월	1월	2월	3월	4월	5월	6월
서버 설정 파일 저장 및 열기											이태호
서버 설정 파일을 이용한 원클릭 접속											김정현
클립보드 텍스트 자동 전송											김정현, 김성은
클립보드 이미지 전송											이태호
애플릿 클라이언트											이태호, 김정현
사용자 제어 권한 나누기											이태호
사용자 목록 전송											이태호, 김정현, 김성은
사용자 제어 권한 변경 및 접속 관리											이태호, 김정현

6. 향후 기대효과

VNC는 무엇보다 다양한 플랫폼을 지원하는 점 때문에 그 어느 원격관리 소프트웨어 보다 활용도가 높다고 할 수 있다.  또한 다른 원격접속에 비해 용량이 작고 무료로 사용이 가능한 프리웨어라서 누구나 쉽게 사용 및 설치가 가능한 장점이 사용자에게 큰 매력으로 작용하고 있다.

PC가 널리 보급되어 여러 영역에서 사용되어 지고 있는 오늘 날에  장소에 구애 받지 않고  VNC를 이용하면 컴퓨터를 자유자재로 다룰 수 있다. 이는 시간 절약을 비롯한 경제적으로는 컴퓨터를 유지, 보수, 관리하는데 있어서도 큰 기여를 할 것이라 기대 된다.

또한 교육용으로도 활용이 가능하여 원격으로 강의를 진행하면 오늘날 많이 접하고 있는 동영상 강의보다 나은 교육도구로 활용이 가능할 것으로 기대된다.

실제로 컴퓨터의 상황을 모니터 하기 위해서 인천의 한 도서관에서 원격관리에 사용되어지고 있는 VNC는 앞으로 기업, 공공시설, 관공서, 학교 등 에서도 무궁무진하게 활용되어질 것이라고 예상된다.

기존의 VNC보다 개선된 CoVNC는 단순히 원격관리를 위한 것이 아닌 활발히 연구되고 있는 동기식 분산 협업 시스템에 새로운 패러다임을 제시 할 수 있을 것이다. CoVNC는 기존의 VNC를 보다 사용자들이 쉽게 사용할 수 있도록 하기위해서 Server의 다양한 설정을 저장하고, One Click 기능을 사용하여서 VNC 접근을 용이하게 하였으며, 기능을 개선 및 추가한 Clipboard기능을 사용해 효율적인 자원공유가 가능하도록 하였으며, 특정 목적을 위한 그룹의 구성원들 간에 능동적인 작업 및 회의 등을 진행할 수 있고 보안을 강화할 수 있는 새로운 기능인 ‘서버 제어 권한별 클라이언트 구분 및 접속’ 기능과 ‘RFB 프로토콜의 확장을 통해, 클라이언트를 효과적으로 관리’ 기능으로 한 층 더 효율적인 동기식 협업에 도움이 될 것으로 기대된다.

졸업작품

최종 보고서

효과적인 동기식 협업을 지원하는 CoVNC 서버와 클라이언트

CoVNC Server and Client Supporting Effective Synchronous Collaboration

제출일 : 2007년 6월 24일

소속 : 울산대학교 컴퓨터정보통신공학부

지도교수:이명준

담당 : 이태호(20002296), 김정현(20001783), 김성은(20022157)