In this work, modifications are made to original VNC programs (Windows version) to limit user input and frame update to selected windows and VNC service on Bluetooth wireless network is implemented and performance test are conducted.
No modification is made to the VNC client program (vncviewer) in order to support the “selected window” feature, so the same VNC client program can be used to access both “single-window” and original VNC desktop. The only modification is made to VNC server program (winvnc), where only client inputs to selected windows are accepted and only updates to selected windows are sent to clients also.
In this modified VNC, limiting client inputs and updates to a selected window will expose only the resources of the selected window to remote clients; in contrast, the resources of whole desktop are exposed in original VNC. This enable us to let users with less privileges to access the VNC server. A good side-effect is less screen updates need to be handled.
On VNC server side, in order for the VNC client to discovery a VNC server, a service record is inserted into the Bluetooth database on the VNC server when VNC server program is started and the service record is deleted when VNC server program is stopped. A hook is added for the selected window to intercept “close” and “minimize” message after the VNC server is running lest that a client might close or minimize the window by accident.
On VNC client side, device discovery is performed first in order to get addresses of all Bluetooth devices in the radio proximity; then service discovery is performed on each Bluetooth address to get VNC services with matched service class GUID. In addition, we can choose only to present the VNC services which have matched service name and/or service description.
Performance tests are also conducted for VNC service on Bluetooth wireless network. The primary concern is the response time which is the time difference between the moment a client gives an input and the moment the corresponding update from server is received by the client.
VNC service is by nature asymmetric. Even though the messages from VNC client to VNC server are usually small in size (in the range of some Kbytes to some tens Kbytes), the messages of screen update from server to message can have size up to hundreds Kbytes.
If the whole bandwidth is used for motion picture, meaning 24 fames in one second, and the ideal bit rate of Bluetooth is 700 KBits/second, a frame can have maximum size of about 26 KBits. If a pixel is represented with 16 bits, a frame can have no more than 2000 pixels, which is far less than the size of an ordinary multimedia clip. The conclusion is that Bluetooth VNC is not suitable for real-time video clip, at least with raw encoding.
But the bandwidth of Bluetooth is sufficient for ordinary GUI operation such as top- level menu selection, pop-up dialog, etc. and small animated GIF images. With hextile encoding and 16-bit color depth, the response times of the above operations are well below 1000 millisecond. Also, the response time increases as the size of bits transfer involved increases. The raw encoding is not suitable as it greatly increase the bytes received and the response time, so more advanced hextile encoding must be used.
The “single-window” VNC server works to reduce the initial load time but does not improve the following response times since the response time is only determined by the size of changed region on the desktop. The added feature of “single-window” does not bring noticeable overhead.
Future Work
The software developing tool used in the work is Microsoft Visual Studio 6.0 and the executable is compatible with operating system Windows 2000, Windows NT 4.0 and Windows 98. Also the performance tests are conducted with laptops running Windows 2000. Effort is taken in programming so that libraries and functions chosen are compatible with
Windows CE. The future work could be to migrate it to Windows CE and test it with hand held PCs.
In other operating systems, a lower color depth may be used and the choice of encoding method could impact differently on overall performance, which needs further investigation.
The role of slave or master played by each Bluetooth device may have effect on overall performance when multiple clients are connected to a server in the same time. More work could be done to determine how to assign the role of each Bluetooth device for optimization.
Reference
1. Behzad Razavi, RF Microelectronics, Prentice Hall PTR, 1998
2. Jim Geier, Wireless LANs, 2nd Edition, Sams Publishing, Indiana, 2002
3. Gregory B. White, Kevin T. Archer, James Core, Chuck Cothren, Roger L. Davis, David J. DiCenso, Travis J. Good, Dwayne E. Williams, Voice and Data Security, Sams
Publishing, Indiana, 2001
4. Bluetooth Specification Version 1.1, Bluetooth SIG, 2001 5. Bluetooth Software Suite SDK Version 1.0, Digianswer, 2000 6. Tristan Richardson, Kenneth R. Wood, The RFB Protocol, 1998
7. Making VNC More Secure Using SSH, http://www.uk.research.att.com/vnc/sshvnc.html 8. Bluetooth Assigned Numbers, http://www.bluetoothsig.org/assigned-numbers/
9. Bluetooth Security White Paper, Bluetooth SIG Security Expert Group, 2002
10. Jun-Zhao Sun, Douglas Howie, Antti koivisto, Jaakko Sauvola, Design, Implementation, and Evaluation of Bluetooth Security, University of Oulu, Finland, 2001
Vita
Rui Xia graduated from University of Science and Technology of China in 1996 with a B.S. in Materials Physics. From Jan. 1999 to Dec. 2000, he studied at Auburn University in Auburn, Alabama. After he received a M.S. in Physics from Auburn University, he went to University of New Orleans for his second master degree in Computer Science. With the accomplishment of this thesis, he will graduate in August 2003.