On 20110131 12:44 , Jim Lawson wrote:
> Other folks have reported good luck with NoMachine NX. It is a
> commercial product. I have never tried it. www.nomachine.com
I am one of those folks; I use NoMachine NX frequently to excellent
effect, and the Linux server and Mac client I use are free downloads. If
the server to which you're connecting is running either Linux or
Solaris, visit their Download page and look for "NX Free Edition".
Sam Hooker | [log in to unmask]
Systems Architecture and Administration
Enterprise Technology Services
The University of Vermont
> On 1/31/11 12:31 , Kor Kiley wrote:
>> I have an issue with VPN that must also be a result of the "thin pipe."
>>> From home, I make an RDP connection to my UVM office computer (Windows
>> 7), and from there connect to one of our servers using an ssh
>> connection. Once on the server I'm using SciTE (an X application) to
>> edit python files. It works fine except that I frequently lose my RDP
>> connection and will have to wait for a minute for it to
>> auto-reconnect. I'm using Xming as my X server.
>> I've tried the same thing running Xming on my home computer and
>> connecting directly to the server instead of going through my office
>> machine. The result in that situation is even worse!
>> I wasn't sure whether the disconnections were the result of the VPN
>> being overloaded or some problem with my Comcast internet connection
>> at home. I was a little suspicious because I sometimes get
>> disconnected from Skype and from an online flight simulation
>> competition that I participate in.
>> On 1/31/2011 12:10 PM, Jim Lawson wrote:
>>> On 1/31/11 11:25 , Helen Read wrote:
>>>> I brought this up on the list a while ago, and it is still an ongoing
>>>> problem. Accessing files on a mapped network drive over the VPN from
>>>> home is extremely slow. It takes a very long time even to select files
>>>> (so as to copy them to a local folder). Once they are selected, the
>>>> files copy quickly, but it takes forever to get them selected, to the
>>>> point of Windows Explorer not responding. Opening files directly on
>>>> the mapped drive is also incredibly slow and results in whatever
>>>> application that is trying to open the file (Mathematica, Excel, Word)
>>>> Not Responding.
>>> The VPN provides communications security, but there is a tradeoff. It
>>> reduces bandwidth, and increases latency. This is something of a pat
>>> answer, but CIFS (the protocol that's used when Windows maps a drive),
>>> in spite of its name, does not perform all that well when there is low
>>> bandwidth, high latency, or packet loss. If you were already connecting
>>> through a "long thin pipe", as it were, the VPN is only going to make
>>> that worse.
>>> You might have better luck using SCP or SFTP from home. The interface
>>> may not be as convenient, but I think you will find it faster for copy
>>> operations. An added bonus is that using SCP or SFTP does not require
>>> the use of the VPN. You can download WinSCP from www.uvm.edu/software.
>>>> And now, I have an even worse problem. Files that my students submit
>>>> (via a secure webpage requiring NetID login) end up in a directory in
>>>> my public_html directory on Zoo. Over the weekend, I copied the files
>>>> to a local directory so that I could open them and grade them (very
>>>> sloooow to select them for copying, as usual). Two files were
>>>> completely corrupted (in different ways). I e-mailed the students and
>>>> asked them to open up their file to make sure it was OK (these are
>>>> Mathematica .nb files, which are actually ASCII) and resubmit it. Both
>>>> of them said that their files were fine at their end, and resubmitted.
>>>> I copied the newly submitted files to a local directory, and both were
>>>> corrupted in the same way as before for each respective student (but
>>>> different from each other). One of the students submitted a third
>>>> time, with the same result. So this morning, at my office, I opened up
>>>> all five of these files from the mapped network drive, no VPN, and lo
>>>> and behold all five files are perfectly fine.
>>> I have never seen CIFS *corrupt* a file. Is it possible that the files
>>> were only partially transferred to your home computer?