What features do you find usefull for remote support?

[shadowfax]

What features do you find usefull, or useless, for a remote support app? I'm talking about features currently supported by UVNC, not about new features.

Recently I compiled a modified version of UVNC base on 1.0.8.5 for remote support. I took away some features from the original UVNC server as I found them useless and, therefore, adding extra weight to the remote support download.

Some of the things I took away where:

• MSLogon - Cant think of a use for it during remote support, except for reboots... and even in this case if the user doesn't have admin privileges I find it useless.
• All the methods to run serviced, install service, etc... As a remote support application it should probably run as an user application.
• JAVA applets and HTTP support. I don't see the point of those on a reversed connection.
• Socket Connect. Same as above, I don't see the point of a listening socket on a reversed connection.
• "When last client disconnects" (AKA Locks). Just do nothing...
• Log to video has been removed.
• File transfer option. Has been hardcoded to TRUE.
• Disable Viewer Inputs. Has been hardcoded to FALSE.
• Allow Loopback and Loopback only removed or hardcoded.
• Forbid the user to close down WinVNC. Hardcoded to FALSE.
• Removed logging. Maybe I'll bring it back removing console logging.

I recall there where some other tweaks in the code as they got orphaned, but I don't remember exactly where...

When the App runs it will show a TeamViewer based GUI with a ID and a Password. The INI file is downloaded through HTTP and hterefore the IP address of the repeater may be changed on the fly. The ID is assigned by the INI file while the password is randomly generated on the application.

As I said, the application was based on UltraVNC 1.0.8.5... I'm now thinking of doing the same on 1.0.9.x or just make a new project and reuse some as much of the RFB code in it.

Since other people may be interested on something like this I'd like to receive some feedback about the feautres people find interesting for a remote support app, and which of them would only add weight to the download.

Further more, it would be nice to hear if you think there are pros or cons about making it in a new project (Mainly to make thing simpler as the application is far more simple the the whole UltraVNC Project). I thought keeping up with the original, even if the code wasn't as light would make easier updating to newer versions, but in fact it just makes it as hard going though diff files and being alert about previous changes in order not to break the code.

Well... that's about it.

Looking forward to hear from you.

[B]

I'm not a big fan of removing features.

How many kilobytes did this actually save you?

[shadowfax]

Not much really. After the Diet it lost about 500 Kb, although that's almost 1/3 of it weight. Making it look fancier it got back its original weight due to a background bitmap which I'll remove and use GDI instead. The "fancy" version after UPX is about 700 Kb download I guess it could have been less without the bitmap, maybe 500 to 600 Kb.

However, most of this weight loss is gained excluding the JAVA files, followed by the logging strings, followed by some dialog boxes. In fact, some of the hardcoded methods are almost unused and make the changes meaningless.

However it made me aare of some redundant pieces of code, where the same variable would be set in the exact same way in the same function in two separate snippets while the variable was unchanged during the code between them.

Taking away some pieces of code also resulted on a slight performance gain, lower CPU and memory usage. Not much, but a samll perfomance gain plus a small diet seems fine.

I agree with you that taking away features is not a nice way to go... However, if the goal is to have a reversed connection for remote support, some functions are meaningless. For example: what use is there for a listening port if nobody is going to connect to that port and it could even be blocked by the firewall or inaccesible since the user hasn't or doesn't know how to configure por mapping?

Therefore it seems fair enough to strip away some code snippets as it reduces the bandwith used at your ISP while it makes the app run a bit more responsive.

I guess the nicest way to go would be to have precompiler conditions in such way you could enable compile the full version or the reverse only version. However, this would be possible to do cleanlly if the GUI and the RFB (Server, client, desktop, etc) would be split in a separate project in order to create different GUI for basic applications and a common point for all this aplications.

That is, each GUI and the application start functions would run in a standaolne project and precompiler conditions would run in the independent project as a lib or statically linked. I've always wanted this to happen as it would merge all the projects (UltraVNC, SC, Helpdesk) into a single project with thre independent "GUI" projects, giving flexibility to other programmers. But I don't know if this will happen

[B]

Oh, I misunderstood you earlier. By "remote support" I thought you meant VNC's purpose as a whole, but it sounds like you're really talking about temporary help desk "get in and get out" usage in the UltraVNC SC / ChunkVNC / SCPrompt style.

I can see your point now. I'm still not sure it matters much if you're already under 1 MB though...

GoToMyPC and, to a lesser degree, LogMeIn are monstrous downloads by comparison.

[shadowfax]

Well UltraVNC has been stripped down under 1 MB, but I'm looking forward into opening a new port for communications (Chat) or how to insert a new way to communicate with the server through a voice chat. I guess it would be quite usefull for temporary remote support. I think quite a lot of apps focused this way uses some kind of voice chat.

Probably the most usefull way would be to make it in such way that the chat service can be established before the RFB protocol has been stated, something like NTRGlobal product. I guess this could be done through a simple protocol such that the server would send distinct commands to the server, such as:



privmsg <nickname|ID> <:message> (Kind of IRC) where a message can be sent to a, lets call it Operator (or technician).

oper <nickname> <password> (Once again kind of IRC) whare an operator/technician would authenticate to the server.

listops would return the nicknames of all online operators/technicians (In my case I would just need the number of available operators to show an alert if none are available, but it could be used to dynamically fill the list in PCHelpware).

listusers (Only executable by Operators/technicians). Would return the list of available "servers" connected to the repeater with no operator/technician assigned to them. Could use a flag such as -a to list every "server" (With or without technician assigned to it), in this case it should include in the results if the server has been assigned or not. Results shall be listed chronologically to follow a FIFO (First In First out) flow.

assign <ID> (Only executable by technicians) would start the connection Server-Viewer. If implemented on different ports the technician the message would be assing <ID> <ip_address[:port]> (once again IRC style similar to a DCC).

voice <ID> (Only executed by operators/technicians) similar to the above command and kind of IRC DCC Chat, where the voice chat would be enabled.

filetransfer <ID> (Only executable by operators/technicians) once again IRC style similar to a DCC send where the operator would send a file to the server.

quit exits the server or viewer cleanlly.


All the commands stated as DCC style could send in its reply an URL to the downloadable executable file of the "Server", this way the "chat" protocol could even be implemented in some other language such as Flash or an Activex, and download the "server" on request.

That's quite a change, but IMHO it would make it more look-alike other payed services on an opensource project

Stripping down UltraVNC for this use is a first step forward to getting such a project on it's way... If there was a way to leave all RFB code away from the GUI it would make it easy for different projects based on the code for the fullblown UVNC... All the code for GUI and this type of repeater could be issolated as the Application project, leavinf another application project for the full-blown UVNC. However, I really don't think this type of code isolation will be possible a short period of time, therefore it needs even more modifications to work (Both on the server and viewer side).

Once again, this is only an idea, and I'm uncertain I'll get the time to make it grow into a real project...

[B]

Uh, I'm no expert on this, but isn't most of that already in the open source Jabber protocols?

[redge]

i prefer a true VoIP outside of computer that not break after log off/shutdown/restart !
so i still connected with voice with the customer even computer reboot.