The1stImmortal wrote:Hi, had a poke at VNC2me and been reading your descriptions etc... looks cool btw
Thanks, your the first person of a technical nature that has made comments on it in this forum (other then friends, and you cannot believe that they will tell you 100% truths)
The1stImmortal wrote:Which is your primary goal?
The first Application is a technical support style one, with others on the way (hopefully dependant on the popularity of this) which will incorporate the collaboration, and "connect to site" styles through the use of UVNC server & repeaters respectively
The1stImmortal wrote:I see a couple of benefit/drawback tradeoffs of using VNC over SSH..... the service you're exposing to the internet is an open SSH port rather than VNC viewer port ...... I'd trust an open SSH port more than an open VNC port
Agreed ... this is a big one, and SSH is the only port i ave open to the net ...
The1stImmortal wrote:SSH compression - I'm not sure you'd cut bandwidth ... SSH compression I've found to be slightly laggy
Over a lan, the compression adds approx 500 millisecond to a full screen refresh (1280x800 256colors) making it about a second, over the INET, the compression shows its own, with a round trip from AUS to the US and back - full screen refresh taking about 2 seconds ... (thats basically right round the world ...)
The1stImmortal wrote:compressing VNC data... well VNC is generally *already* somewhat compressed, and double-compression isn't very efficient.
Bandwidth usage is about 2/3 when using compression, but i probably need to make compression optional through an ini setting ... so that those that are using a local server and clients, don't have to spend the time compressing and decompressing ... good thought !!!
The1stImmortal wrote:BTW, rather than ship multiple binaries etc, and do textual shell calls and IPC, there's a couple of PuTTY-as-library or even OpenSSH-as-library solutions around that might be helpful to consolidate the SSH more into the VNC2ME client package.
I'm interested in this, and have not found any C or C++ dll's, only C# (i don't like .net dependancies), any you can point me towards would be much MUCH appreciated ...
The1stImmortal wrote:Finally, if you're hoping to get this through corporate firewalls at any point, bear in mind that a LOT of corporate firewalls outright block port 22 traffic. Several also actively filter other port connections for SSH traffic and block it.
Yep, already thought of this (and come accross it in practise), i got around this by making SSH listen on 443 (SSL port) ... but i have never come accross those really REALLY good firewalls yet ... MS proxy (can't recall the name atm) doesn't allow SSH connections anymore (not from putty / plink anyway)
The1stImmortal wrote:You may need to keep this in mind and allow future expansion to alternative connection methods (such as HTTPS CONNECT tunnelling - which although not ssh is still SSL encrypted). Once again theres a couple of libraries around to implement this.
The1stImmortal wrote:Finally, make sure you've got a specific SSH server in mind for the other end of the connection, and a guide or preconfiguration examples on how to lock it down to do only VNC traffic.
The1stImmortal wrote: The client machines are going to have a nice easy path to a shell on the vncviewer or middle-man system, and that may not be a Good Thing when you don't 100% trust the clients (after all, they're the ones supposed to be being controlled!)
this is the primary reason i have not yet setup a public VNC2Me server ... i'm in the process of setting up a VPS with CHROOTED sshd and denying the user shell access ... but this is still in the wings ...
The1stImmortal wrote:Cheers,
The1stImmortal
thankyou for all your comments, its always good to get constructive critisism, and you put some thought into it a bit before posting comments, so thanks.