specification Android SDK
1. Creating a plug-in module to the program access to a remote computer via VNC and SSH over a secure connection.
This project, therefore, also encompasses the use case of a simple form of collaboration by sharing access to a desktop session.
There are various existing technologies in this area which all work in very similar ways. This project will follow those same basic architectural principals.
The core part of such a system is a protocol by which information about what is happening on the screen of the "host" machine (in this case, the user's machine) is sent to the "client" machine (the sysadmin's machine). The client also needs to be able to relay back key presses and pointer manipulation information to the host.
There are several existing such protocols available - the RFB (Remote FrameBuffer) protocol used by VNC, RDP (Remote Desktop Protocol) used by Window's Remote Desktop and the Sun Ray protocol.
On the host machine a mechanism is needed by which all drawing primitives are proxied via the protocol to the client machine as well as a mechanism by which key / pointer events from the client are passed to the windowing system. Also needed is an authentication mechanism by which access to the host system can be restricted.
On the client machine an application which allows the user to connect to the host machine, authenticate, display the contents of the host display and forward input events to the host is required.
Frequent by Many:
1. View a desktop remotely. (C)
2. Interact with a remote desktop. (C)
3. Browse the network for a machine to connect to. (I)
4. Make the remote desktop occupy the entire local screen ie a fullscreen
Occasional by Many:
1. Open a connection to a user's desktop given only the hostname of the user's machine (C)
2. Open a connection to a user's desktop without having the user be aware of your connection. (I)
3. Receive a remote assitance request and open a connection to that user's desktop. (I)
1. Ability to view a desktop remotely. (C)
2. Ability to interact with a desktop remotely. (C)
3. Ability (for a user with sufficient priviledges) to connect to a given user's
desktop on a given host. (C)
4. Ability to browse the network for hosts which you can then connect to. (I)
5. Ability (for a system administrator) to connect to a given user's desktop without
the user being aware of the connection. (I)
6. Ability to view the remote desktop in fullscreen mode. (NTH)
7. Ability to connect to a desktop given a remote assitance request. (I)
8. Ability to connect to a desktop given some details from the host user. (I)
Monitoring The Local Display
To implement a VNC server you need to know the contents of the local framebuffer in order to pass this information onto the VNC clients.
Currently, as an X client, there is only one way to do this and that is by doing a GetImage on the root window which basically copies the entire framebuffer from the X server to the X client. The main problem with this approach is that without knowing what parts of the framebuffer has actually changed since the last time you updated, you are wasting an enormous amount of resources copying the entire framebuffer each time.
There are a number of possiblities to lessen the inefficiency here. The first is to limit the amount of polling you do per update of the framebuffer. For example, every update you could just check a certain number of scanlines against your local copy of the frame buffer and if parts of the scanline differ, then do a GetImage on a number of tiles which capture those changes to the scanline. This is the approach taken by krfb and x0rfbserver.
Another possibility is an X extension to notify the X client of changes to the framebuffer, thereby negating the need for continually polling the X server. When the client receives the notification it can do a GetImage to update its copy of the framebuffer