Kimberley

Kimberley: 고정된 infrastructure를 일시적으로 모바일 기기가 사용할 수 있게 해주는 목적의 시스템.

주소: cmusatyalab / kimberley

Kimberley는 kimberlize와 display control manager(KCM)을 사용하여 mobile device가 큰 화면에서 application을 실행할 수 있도록 해준다.

 

System Usage    

 

전형적인 Kimberley system의 사용방법:

1. 관리자는 base VM과 하나 이상의 kimberlize patch를 제작하기 위해 kimberlize tool을 사용한다.
2. 관리자는 몇 개의 display를 설치하고 display에 base VM을 배분한다. 그 machine들 위에 서 Kimberley service를 broadcast 하기 위하여 the Display Launcher를 실행한다.
3. 관리자는 사용자에게 Kimberlize patch들을 제공한다. patch들은 관리자가 사용자에게 보내주어 mobile device에 직접 저장하거나 혹은 이용할 수 있는 patch의 URL 주소를 기록한다.
4. Mobile setting중인 사용자는 application을 실행한 듯한 화면을 마주 친다.
5. 사용자는 사용하려는 Kimberlize patch의 파일이름이나 URL, 그리고 적용할 VM의 이름을 제공하여 the Mobile Launcher application을 실행한다. 추가적으로, 사용자가 또한 floppy disk image 같은 파일을 공급하려고 한다면, 사용자가 만드는 어떠한 데이터들은 시스템의 사용을 넘어서도 유지 해야 한다.
6. The Mobile Launcher는 local에서 Display Launcher services를 검색하려고 실행중인 KCM에 접속한다. 이것은 local TCP/IP 연결을 KCM에 설립한다.
7. Mobile host와 display host KCM processes간의 성공적인 접속 설립 시, the Mobile Display application은 계속해서 하기 전에 client의 인증을 요구 한다.
8. The launcher program들은 application을 실행하는데 요구되는 정보들을 통신한다. 그리고 display에 접근하는 경량화 client VNC 를 제공한다. 만약 mobile device와 display 간의 latency가 나쁘다면, 사용자는 USB cable을 데이터 전송의 추가적인 용도로 한다.
9. 사용자가 application과 얼마의 시간 동안 상호작용한다.
10. 사용자가 display와의 상호작용을 끝냈을 때, mobile device의 VNC client를 종료하고, 사용이 끝났음을 신호로 보낸다. The Kimberlize patch는 display에서 지워지고 제거되며, virtual machine은 기본 상태로 돌아간다. 만약 floppy disk 가 제공됐다면, 생성된 새로운 상태의 binary difference patch를 mobile device에 전송하고 원본 floppy disk image에 적용한다.

이 시나리오에서, the Mobile Launcher와 Display Launcher는 공동으로 mobile device 인증, Kimberlize patch를 display로 전송 하는 것, application을 조작하기 위한 thin-client 연결의 생성, 그리고 사용자가 상호작용을 끝냈다는 것에 대한 신호를 생성하는 책임이 있다. 이런 작용의 아래를 보면, 우리는 관리자가 display를 처음 설정할 때의 상호작용, 그리고 둘째로 사용자와 display간의 상호작용이 어떻게 일어나는지를 볼 수 있다.

Command Syntax

 

두 launcher 명령어의 문법:

mobile_launcher [-d floppy_disk_image] <-f file | -i URL> <vm_name>

display_launcher

 

The display launcher는 display's service가 KCM에서 알려질 문장을 하나의 option으로 수행한다. 만약 option이 주어지지 않으면 기본 string으로 실행된다. The Display launcher가 VM의 runtime을 분석하고 실행될 patch에 대해서는 알지 못할때, 추가적인 parameter를 요구하지 않는다.

The mobile launcher는 filename이나 kimberlize patch가 존재하는 곳을 나타내는 URL, kimberlize patch가 적용될 VM의 이름, 그리고 추가적으로 display의 이름이다. 만약 지역에 다수의 display를 가지고 있다면 연결을 명확하게 하기 위하여 The display 이름이 물리적으로 display에 적혀있을 것이다.

 

Technial Walkthrough of Administrative Setup

 

1. 관리자는 machine에 display를 붙이는 것과 kimberley를 설치하는 것을 설정한다.
   1. 어떠한 SASL(Simple Authentication and Security Layer) 권한 설정이 필요한 것은 어떠한 custom 플러그 인을 설치하는 것을 포함하여 관리자에 의해 수행된다.
   2. 만약 관리자가 USB networking 지원을 원한다면, 아마 Linux kernel에서 활성화 할 필요가 있을 것이고 적절한 USB network 인터페이스가 추가되고 설정되어야 한다. 이것을 어떻게 해야 하는지에 대한 예제는 여기서 찾을 수 있다.
2. 관리자는 the Display Launcher를 실행한다.
3. The Display Launcher는 즉시 앞으로의 연결을 다루기 위해 사용하는 Sun RPC server를 실행하는 새로운 thread를 생성한다. The Sun RPC server는 임의의 port로 bind 하고 local 연결을 listen 한다.
4. The Display Launcher는 KCM안에 D-Bus call을 생성하는데, 어떠한 이용할 수 있는 발견 mechanism의 publishing services인 side-effect로 아마도 KCM이 실행될 것이다. Sun RPC Server가 listen중인 port가 제공되어야 한다.
5. System은 들어오는 연결 요청을 기다린다.

Technical Walkthrough of Usage

 

다음으로, system은 전형적인 mobile 사용 중에는 다음의 단계를 실행한다.

1. 사용자가 mobile 설정으로 실행시킨 application의 화면을 본다..
2. 사용자는 mobile_launcher를 실행하고 virtual machine의 이름과 kimberlize patch의 위치, 추가적으로 사용할 floppy disk image의 파일이름을 나타내는 paramete를 넘겨준다.
3. The Mobile Launcher는 기본이나 혹은 추가적으로 제공된 이름의 display service를 탐색하는 D-BUS call을 KCM에 만든다.(side-effect로 KCM이 실행될 수도 있다.)
4. KCM은 display를 탐색하거나, 연결하거나 연결의 암호화 하는 일을 수행한다. 그리고 local TCP 연결을 나타내는 port integer value를 만들어서 반환한다.
5. The Mobile Launcher는 port를 받고 local TCP 연결을 생성한다. Display의 DCM(아마 KCM을 말하는 듯?)은 the Display Launcher's Sun RPC server에 local TCP 연결을 생성한다.
6. The Mobile Launcher 연결된 socket에 Sun RPC client를 불러오고 초기화 시킨다.
7. The Mobile Launcher는 Display Launcher를 부르는 RPC 의 형식에 0 이상의 인증 단계를 실행한다. Parameter와 결과는 실행중인 system이 알 수 없는 opaque strings of bytes 이다.
8. The Mobile Launcher는 연속된 null RPC pings을 연결의 latency를 측정하기 위하여 the Display Launcher에게 내보낸다.
   1. 만약 latency가 확실한 threshold에 있다면, the Mobile Launcher는 사용자가 추가적으로 USB cable을 display로 dedicated network link로 사용하는 것을 격려한다. 이것은 바쁜 지역에서 wireless link의 높은 latency에 의한 thin client의 기능의 둔함을 극복하게 한다.
   2. 만약 사용자가 받아들이고 cable로 접속한다면, USB networking interface는 mobile device와 display 사이에 접속되고 설립된다.
9. The Mobile Launcher는 Display Launcher에게 dekimberlize 단계 도중에 필요한 파일들을 두 RPC를 구성하는 작은 파일 전송 protocol을 이용하여 보낸다.

       typedef opaque data<>;
   

       int send_file(string filename<1024>, int size);
   

       int send_file_partial(data part);
   

    

   send_file의 호출은 들어오는 파일과 그 사이즈의 구체화를 처음으로 만든다. 그리고, the Mobile Launcher는 충분한 send_file_partial(1MB per call maximum) 호출을 파일을 전송하기 위해 실행한다. 이 파일들은 아마 VM overlay와 floppy disk image를 포함할 것이다. 파일들은 namespace인 display rooted /tmp/Kimberley/ 에 모일 것이고, 각각 주어진 파일 이름의 basename으로 저장될 것이다. 파일들의 의도되는 실제 사용방법은 나중 RPC에 의해 구체화 된다. 추가적으로, 만약 사용자가 floppy disk image를 보냈다면, local namespace에 있는 그 파일 이름은 다음 RPC에 의해 정의된다:

    int use_persistent_state(string filename<1024>);
					

1. The Mobile Launcher는 the Display Launcher에게 나타내고 가능하면 Kimberlize의 상태를 전송하기 위해 두 RPC call중 하나를 만든다:

       int use_kimberlize_file(string vm_name<128>, string patch_file<2048>);
   

       int use_kimberlize_URL(string vm_name<128>, string patch_URL<2048>);
   							

 

1. Kimberlize patch가 the Display Launcher에게 전송되면, 짧은 script를 실행한다. Script는 mobile device에서 건네받은 parameter와 함께 dekimberlize를 실행하고 또 x11vnc server를 X display ":0.0"에 초기화 시킨다. The Display Launcher는 port를 x11vnc server가 listen중인 곳에 display의 KCM과 함께 등록한다. 병행하여, the Mobile Launcher는 display가 내보내는 VNC services를 반복적으로 KCM을 호출하여 탐색한다. KCM은 몇몇 조금의 시도 이후에 새로운 thin client service를 해결하고 publish 한다.
2. The mobile launcher는 thin-client 접속으로 vncviewer를 실행하고, KCM에 의해 local로 반환되는 port에 접속하거나 직접적으로 USB networking이 활성화 중일 때의 display USB IP address로 접속한다.
3. Dekimberlize는 그 후에 지속해서 실행하고 잠시 VM을 다시 시작한다. 한 번 다시 시작한 후에는, 사용자는 application과 mobile device의 UI controls를 사용하여 상호작용한다.
4. 사용자가 상호작용을 끝내면, vncviewer application을 종료한다. The Mobile Launcher는 application이 종료됐다는 신호를 받고, Deisplay Launcher에게 사용의 끝을 알리는 마지막 RPC를 전송한다. 추가적으로 floppy disk delta가 검색됐는지 확인한다. The Display Launcher는 RPC를 block하고 /tmp/dekimberlize_finished를 만들고 dekimberlize script에게 사용자의 상호작용이 끝났다는 신호를 보낸다. Dekimberlize script가 일을 끝내면, kimberlize patch를 제거하고 floppy disk의 delta의 계산뿐만 아니라 virtual machine의 상태를 기본 상태로 복구한다. 이것이 끝났을 때, the Display Launcher는 새로 생성된 floppy disk delta의 파일이름(만약 제공되지 않는다면 null)을 RPC로 제공하는데 성공했다고 반환한다. 추가적으로, the Mobile Launcher는 파일 전송과 비슷한 2개의 RPC protocol을 이용하여 floppy disk delta를 검색한다:

typedef opaque data<>;

int     retrieve_file(string filename<1024>);

data    retrieve_partial(void);

The Mobile Launcher는 기존 floppy disk image file과의 binary 차이를 적용하기 위해 xdelta를 실행 한다.

 

1. The Display Launcher는 network 접속을 종료하고 KCM애 Kimberley service를 다시 등록한다.
2. The Mobile Launcher는 쓰기를 통해 persistent state를 저장하고 RPC 호출에 의해 받은 patch를 적용한다. 그리고 완료한다.