Roasting old chestnuts
Robert de Bath
Sun Jul 6 14:26:01 2003
Please don't run away, I do seem to have a new slant on this can of wormy
The label on the can is "file transfers".
What I propose is that the file transfer that _already_exists_ in VNC is
used. This means there would be NO CHANGES NEEDED to any PROTOCOL.
Just use the http server on port 5800+
You see many people don't realise that bare http is a bi-directional
protocol; everybody knows of the http GET command but there is also
a http PUT command that's used to send a file to the server.
Details, Server end.
The server on port 5800+ would be extended to allow http file transfers
both to and from a specific directory. On the windows server the directory
should be accessable from the systray icon. On all servers it should be
a user specified directory with a disable.
Details, Client end.
File transfer _could_ be integrated into the normal client but this
isn't required. A separate file transfer client could just as easily
be invoked from a command menu, it's job would be to:
1) GET and display a file with the current directory list.
The file could be _very_ simple html, eg an Apache directory list.
2) GET any file on that list and store it locally.
3) PUT a local file onto the server into that list.
All using dumb http to port 5800+
The invocation from the VNC client would just be:
or when/if https is added.
Some form of authentication is _required_, you really don't want any
old AFLWer sending you files.
Basic http authentication would do the trick, but it would need the
user to re-enter their password, and the password is sent repeatedly
A better method would be to get a 'security cookie' from the server
this could be a HTTP cookie or something else. It would be really
nice if this cookie was requested from the server via the RFB
connection so the user doesn't have to re-enter their password,
but that would involve a change to the RFB protocol.
The cookie should timeout eventually so basic auth would still be
With a little bit of scripting MSIE can do http put commands but it's
very bad at it (no resume, no progress indication) so a dedicated
client would be _much_ better. There are some very good command line
utilities for this (eg: http://curl.sourceforge.net/ ), however I haven't
yet found a nice Win32 GUI one.
People using ssh, zebedee or firewalls would need to add the 5800+
port to their tunnels in addition to the 5900+ port. All connections
are initiated from the client end which makes it easy, unlike ftp.
Assuming a dedicated Win32 transfer client is written it should use
completely standard protocols so it can interect with (eg) Apache's
put,get and directory index. Also I would imagine there are lots of
useful features it could be given; jobs queues, bandwidth limiting,
DELETE command, HTTP server, etc etc. But as it's a separate client
that's not VNC bloat is it :)
Finally: Yes I've heard of ultravnc, but it's windows only.
Rob. (Robert de Bath <robert$ @ debath.co.uk>)
Google Homepage: http://www.google.com/search?btnI&q=Robert+de+Bath