Exceed onDemand versus VNC
sinister
My sysadmin is pushing people to use Exceed onDemand.
One thing I really like about VNC is the connect/reconnect feature---if the
network goes down or the connection is somehow lost, all the processes
living within the X windows in the VNC desktop stay alive. It's also handy
when I want processing to continue yet want to turn my PC off---I just kill
the client, turn off the PC, go to bed, wake up and reconnect.
The sysadmin claims that Exceed onDemand has a suspend feature. But does it
have the ability to keep processes "alive" on the Solaris host if the
connection between my PC and the Solaris box dies?
Also, last time I tried Exceed from home it was unusuable. I had been using
X-Win32 (like Exceed, but cheaper and IIRC without as much fancy TCP/IP
stuff) at work to connect from a PC to a Solaris box, and when I tried it
from home, both it and Exceed were unusable (this was over DSL)---things
took forever. My diagnosis at the time was that it wasn't really a
bandwidth problem but a network latency problem with X, which VNC finesses.
Is that likely to be any better with Exceed a few years on now?
TIA,
S
Peter C. Tribble
"sinister" <sini...@nospam.invalid> writes:
> I currently use VNC to access a Solaris 9 host. I like it.
>
> My sysadmin is pushing people to use Exceed onDemand.
When you may both be much better off with NX:
--
-Peter Tribble
MRC Rosalind Franklin Centre for Genomics Research
http://www.rfcgr.mrc.ac.uk/~ptribble/
sinister
"Peter C. Tribble" <ptri...@hgmp.mrc.ac.uk> wrote in message
news:cj130v$j08$1...@helium.hgmp.mrc.ac.uk...
> In article <90U4d.500$iD6.440@trnddc05>,
> "sinister" <sini...@nospam.invalid> writes:
>> I currently use VNC to access a Solaris 9 host. I like it.
>>
>> My sysadmin is pushing people to use Exceed onDemand.
>
> When you may both be much better off with NX:
>
> http://www.nomachine.com/
How does it compare to VNC in respect to the questions I posted?
If I turn my PC off, will the applications I'm running continue to run on
the Solaris box, as is the case with VNC? (With me reconnecting later.)
Mark Clements
>
> Also, last time I tried Exceed from home it was unusuable. I had been using
> X-Win32 (like Exceed, but cheaper and IIRC without as much fancy TCP/IP
> stuff) at work to connect from a PC to a Solaris box, and when I tried it
> from home, both it and Exceed were unusable (this was over DSL)---things
> took forever. My diagnosis at the time was that it wasn't really a
> bandwidth problem but a network latency problem with X, which VNC finesses.
> Is that likely to be any better with Exceed a few years on now?
My experience is that vnc is orders of magnitude faster: sitting on the
end of a DSL connection in France and tunnelling it through ssh to a
university in London, applications are vastly more responsive than if I
were using Exceed and sitting on the university network itself.
Mark
Kyler Laird
>One thing I really like about VNC is the connect/reconnect feature---if the
>network goes down or the connection is somehow lost, all the processes
>living within the X windows in the VNC desktop stay alive.
This can be done in X with a pseudoserver (similar to what VNC does). The X
server you use (Exceed or whatever) wouldn't matter in this case.
http://www.software-facilities.com/x11-software/xmove.php
--kyler
Peter C. Tribble
"sinister" <sini...@nospam.invalid> writes:
>
> "Peter C. Tribble" <ptri...@hgmp.mrc.ac.uk> wrote in message
> news:cj130v$j08$1...@helium.hgmp.mrc.ac.uk...
>> In article <90U4d.500$iD6.440@trnddc05>,
>> "sinister" <sini...@nospam.invalid> writes:
>>> I currently use VNC to access a Solaris 9 host. I like it.
>>>
>>> My sysadmin is pushing people to use Exceed onDemand.
>>
>> When you may both be much better off with NX:
>>
>> http://www.nomachine.com/
>
> How does it compare to VNC in respect to the questions I posted?
>
> If I turn my PC off, will the applications I'm running continue to run on
> the Solaris box, as is the case with VNC? (With me reconnecting later.)
That's present in the current development version, so it's not in the
current production version but will be in the next.
And for most things it's way faster than VNC, and fully encrypted.
But the only way to see how well it works for you, with your
applications in your environment, is to actually test it. (Which needs
your sysadmin to get involved.)
sinister
"Kyler Laird" <Ky...@news.Lairds.org> wrote in message
news:6qnd22-...@lairds.us...
> "sinister" <sini...@nospam.invalid> writes:
>
>>One thing I really like about VNC is the connect/reconnect feature---if
>>the
>>network goes down or the connection is somehow lost, all the processes
>>living within the X windows in the VNC desktop stay alive.
>
> This can be done in X with a pseudoserver (similar to what VNC does). The
> X
OK. But my question is: can Exceed do this on its own, without sticking
another layer (i.e. a pseudoserver) in between?
If not, then in my case there's no advantage to Exceed over VNC...
Kyler Laird
>>>One thing I really like about VNC is the connect/reconnect feature---if
>>>the
>>>network goes down or the connection is somehow lost, all the processes
>>>living within the X windows in the VNC desktop stay alive.
>>
>> This can be done in X with a pseudoserver (similar to what VNC does). The
>> X
>OK. But my question is: can Exceed do this on its own, without sticking
>another layer (i.e. a pseudoserver) in between?
In the X server? Of course not. I thought it was obvious that there has
to be something to maintain the session.
>If not, then in my case there's no advantage to Exceed over VNC...
Right, they both require something to keep running.
--kyler
sinister
> "sinister" <sini...@nospam.invalid> writes:
>
>>>>One thing I really like about VNC is the connect/reconnect feature---if
>>>>the
>>>>network goes down or the connection is somehow lost, all the processes
>>>>living within the X windows in the VNC desktop stay alive.
>>>
>>> This can be done in X with a pseudoserver (similar to what VNC does).
>>> The
>>> X
>
>>OK. But my question is: can Exceed do this on its own, without sticking
>>another layer (i.e. a pseudoserver) in between?
>
> In the X server? Of course not. I thought it was obvious that there has
> to be something to maintain the session.
Right. I was just confirming.
>
>>If not, then in my case there's no advantage to Exceed over VNC...
>
> Right, they both require something to keep running.
In terms of what the user sees, VNC requires nothing extra.
> --kyler
Kyler Laird
>>>If not, then in my case there's no advantage to Exceed over VNC...
>>
>> Right, they both require something to keep running.
>In terms of what the user sees, VNC requires nothing extra.
Now we're right back where I started. If you use put xmove on the application
server (instead of VNC), then in terms of what the user sees, Exceed requires
nothing extra. (Heck, in terms of what the admin sees, there's nothing "extra"
beyond what VNC requires.)
My point was that there's little difference between VNC and X in this regard.
I suggest that you concentrate on other differences you found. This one isn't
valid.
--kyler
Mohun Biswas
> Now we're right back where I started. If you use put xmove on the application
> server (instead of VNC), then in terms of what the user sees, Exceed requires
> nothing extra. (Heck, in terms of what the admin sees, there's nothing "extra"
> beyond what VNC requires.)
The URL given above points to a package which hasn't been updated since
1997. Of course it's possible the application is that stable but still,
the age raises concerns about how viable this particular implementation
is. Are you actually using it in 2004 successfully?
--
Thanks,
M.Biswas
sinister
> "sinister" <sini...@nospam.invalid> writes:
>
>>>>If not, then in my case there's no advantage to Exceed over VNC...
>>>
>>> Right, they both require something to keep running.
>
>>In terms of what the user sees, VNC requires nothing extra.
>
> Now we're right back where I started. If you use put xmove on the
> application
> server (instead of VNC), then in terms of what the user sees, Exceed
> requires
> nothing extra. (Heck, in terms of what the admin sees, there's nothing
> "extra"
> beyond what VNC requires.)
But, first, you haven't explained what xmove does. Does it apply to *every*
X application? Or just the ones the user designates? Do you have to apply
it to a particular application before using that application?
Second, I count:
VNC: 2 pieces of software (VNC server, client)
Exceed plus xmove: 3 pieces of software (Exceed server, client, and xmove)
Maybe there's things I'm not counting that I should be.
Then there's the point that Mohun Biswas makes---that the xmove package
hasn't been updated since 1997.
> My point was that there's little difference between VNC and X in this
Kyler Laird
[on xmove]
>The URL given above points to a package which hasn't been updated since
>1997. Of course it's possible the application is that stable but still,
>the age raises concerns about how viable this particular implementation
>is. Are you actually using it in 2004 successfully?
I haven't used it and I'm not recommending it. It's just an example
of how X can be made to function (in one aspect) like VNC.
Perhaps this will be more satisfying.
http://ximove.com/
I prefer VNC (in part because there are Java applet versions of the
viewer). I'll probably use FreeNX when it's a Debian packages (and
includes a Java applet viewer).
--kyler
Kyler Laird
>Second, I count:
>VNC: 2 pieces of software (VNC server, client)
>Exceed plus xmove: 3 pieces of software (Exceed server, client, and xmove)
>Maybe there's things I'm not counting that I should be.
The X terminology is confusing. I'd write it like this.
VNC: 3 pieces of software (VNC server, VNC client, applications)
Exceed plus xmove: 3 pieces of software (xmove, Exceed server, applications)
--kyler
sinister
You forgot the Exceed client.
>
> --kyler
Richard Santink
server on the PC, not the host.
RAS
sinister
"Richard Santink" <rsan...@nortel.ca> wrote in message
news:415AAFC...@nortel.ca...
>I don't think there is an Exceed 'client' per se. Exceed runs as an X
>server on the PC, not the host.
AFAICT, you're wrong:
http://mimage.hummingbird.com/alt_content/binary/pdf/collateral/ds/eod_ds.pdf
While indeed one speaks of X servers running on the local host, not the
remote host where the application is running, Exceed's own nomenclature goes
the other way (though I'm sure they still speak of *X* server and client in
the correct way). And you do need software at both ends---a server and a
client.
Richard Santink
that Exceed itself, need only be installed on the Windows machine..
there is no Exceed server that need be configured on the linux or unix
host. As for their use of the terms 'server' and 'client' I'm still a
bit foggy..
RAS
sinister
> Good enough.. as I pointed out, I wasn't positive.
Fair enough.
> However, I do know, that Exceed itself, need only be installed on the
> Windows machine.. there is no Exceed server that need be configured on the
> linux or unix host.
That's possible.
The particular Exceed product I'm looking at is Exceed onDemand.
I do things over DSL, between work and home. When I did this kind of thing
before, I tried two X servers, X-Win32 (basically, like Exceed but without
stuff you don't need, and cheaper), and Exceed. Perhaps (can't recall) the
Exceed was like the product you're describing---an X server on the PC, with
nothing on the Unix host running the "actual application".
Both X-Win32 (which worked fine from a PC to the Unix host over the local
ethernet at work) and Exceed were so slow as to be useless. I did a little
research, and it seems that bandwidth isn't the only issue, but also
"network latency." X does some kind of synchronization or something,
whereby packets are sent back and forth. It might be OK over an ethernet,
where I suppose the circuit time is on the order of 1 ms or less, but over
something like DSL (with the circuit time being on the order of tens of ms),
it'll just kill you.
> As for their use of the terms 'server' and 'client' I'm still a bit
> foggy..
In this case it's probably because their "server" is serving up a special
protocol that enables communication over a slower network (e.g. DSL) to be
do-able. VNC (which I actually think is fine, but my sysadmin is pushing
Exceed...) has the same nomenclature (i.e., the one opposite of the usual X
nomenclature).
Cheers,
S
Kyler Laird
>> The X terminology is confusing. I'd write it like this.
>> VNC: 3 pieces of software (VNC server, VNC client, applications)
>> Exceed plus xmove: 3 pieces of software (xmove, Exceed server,
>> applications)
>You forgot the Exceed client.
I used the term "applications" instead of "X clients" in order to
be more parallel with the wording in the VNC line.
I understand that saying "Exceed server" instead of "X server" might
be contrary to their terminology. I probably should have written
"Exceed client."
--kyler
Kyler Laird
>The particular Exceed product I'm looking at is Exceed onDemand.
It looks like they're providing some sort of low-bandwidth proxying.
In this case, we're no longer talking about X. It's behaving *just*
like VNC.
Heck, if you want to go with a proprietary solution and get suspend/
resume functionality, you might as well use something like XVision
Eclipse.
http://www.tarantella.com/products/vision/ds/xveds.html#resume
>Both X-Win32 (which worked fine from a PC to the Unix host over the local
>ethernet at work) and Exceed were so slow as to be useless. I did a little
>research, and it seems that bandwidth isn't the only issue, but also
>"network latency." X does some kind of synchronization or something,
>whereby packets are sent back and forth. It might be OK over an ethernet,
>where I suppose the circuit time is on the order of 1 ms or less, but over
>something like DSL (with the circuit time being on the order of tens of ms),
>it'll just kill you.
Yup, bandwidth/latency problems are why LBX was developed.
http://studenthelp.itee.uq.edu.au/remote/lbx.html
>> As for their use of the terms 'server' and 'client' I'm still a bit
>> foggy..
>In this case it's probably because their "server" is serving up a special
>protocol that enables communication over a slower network (e.g. DSL) to be
>do-able.
Agreed.
>VNC (which I actually think is fine, but my sysadmin is pushing
>Exceed...) has the same nomenclature (i.e., the one opposite of the usual X
>nomenclature).
So he wants a less-functional (costly) proprietary solution to X proxying
instead of an Open solution which does everything desired and more? I'd
expect that from management, not a sysadmin.
--kyler
Juhan Leemet
> "Richard Santink" <rsan...@nortel.ca> wrote in message
[snippage]
> Both X-Win32 (which worked fine from a PC to the Unix host over the
> local ethernet at work) and Exceed were so slow as to be useless. I did
> a little research, and it seems that bandwidth isn't the only issue, but
> also "network latency." X does some kind of synchronization or
> something, whereby packets are sent back and forth. It might be OK over
> an ethernet, where I suppose the circuit time is on the order of 1 ms
> or less, but over something like DSL (with the circuit time being on the
> order of tens of ms), it'll just kill you.
ISTR a buddy of mine used X over serial dialup years ago. It is very slow.
There was a way to improve it by some kind of compression (?) on the
serial transmission, or was that some "middleware" that did something
special with polling and/or synchronization (as you put it?). It never was
great, but it became usable. I'm not any kind of expert in this area. If
interested (and if no one else here recalls the method) I can try to get
that info (but it may take time) from my buddy of years ago.
>> As for their use of the terms 'server' and 'client'...
>
> ...VNC...Exceed... has the same nomenclature (i.e., the one
> opposite of the usual X nomenclature).
I think the confusion arises because most of the punters think in terms of
boxes, and not services. The X server provides a display service,
therefore it obviously runs on the computer/device with the display
attached. Services can be provided all over the place (including from
"workstations"), so it is meaningless to talk of "THE server" (box).
Is this all legacy from PCs attached to a (Corvus?) file/print server?
--
Juhan Leemet
Logicognosis, Inc.
David Magda
> Yup, bandwidth/latency problems are why LBX was developed.
> http://studenthelp.itee.uq.edu.au/remote/lbx.html
LBX isn't that useful according to Keith Packard:
http://keithp.com/~keithp/talks/lbxpost/paper.html
Mr. Packard did some analysis of X network performance and generally
concluded that using SSH compression is as good as, or better than,
using LBX:
http://keithp.com/~keithp/talks/usenix2003/
The main issue with SSH is it can increase latency on high bandwidth
links. From the conclusions:
Performance using LBX over the highest latency links is no better
than SSH. Performance over broadband network of the protocol
without compression is only 25 percent worse than LBX. LBX does
not solve either the authentication and security problems that
SSH solves. We saw little evidence of LBX ever helping. At least
as implemented, LBX looks to have been a bad idea
--
David Magda <dmagda at ee.ryerson.ca>, http://www.magda.ca/
Because the innovator has for enemies all those who have done well under
the old conditions, and lukewarm defenders in those who may do well
under the new. -- Niccolo Machiavelli, _The Prince_, Chapter VI
Christopher Browne
> We saw little evidence of LBX ever helping. At least as
> implemented, LBX looks to have been a bad idea
That strikes me as overstating things in a pretty mean fashion.
LBX may have turned out to be unsuccessful, but you often have to go
down some blind paths that _weren't_ necessarily "bad ideas" in order
to find the right path.
We solved a performance problem yesterday (almost a month after the
initial report) that was very much like that; there was a very
particular problem involving a runaway monitoring process.
We couldn't _find_ it until we went down several "blind paths" to rule
out things as NOT being broken.
I see no reason to have expected LBX to be a "bad idea," a priori. It
turns out that it wasn't as good as SSH tunnelling, but we couldn't
really know that before both were tried.
--
wm(X,Y):-write(X),write('@'),write(Y). wm('cbbrowne','acm.org').
http://www3.sympatico.ca/cbbrowne/postgresql.html
"Be humble. A lot happened before you were born." - Life's Little
Instruction Book
sinister
> "sinister" <sini...@nospam.invalid> writes:
>
>>The particular Exceed product I'm looking at is Exceed onDemand.
>
> It looks like they're providing some sort of low-bandwidth proxying.
> In this case, we're no longer talking about X. It's behaving *just*
> like VNC.
OK. Though in its favor, I'm pretty sure it includes encryption, which VNC
doesn't. Of course, you'd think the guy would just set up ssh, but no...
>
> Heck, if you want to go with a proprietary solution and get suspend/
> resume functionality, you might as well use something like XVision
> Eclipse.
> http://www.tarantella.com/products/vision/ds/xveds.html#resume
One thing that's not clear to me (I'm not referring to your posts, but to
the terms as generally used): Does suspend/resume allow the apps you're
using to continue working? E.g. I often set up software sessions that
involve lots of number crunching and want to let them run on the UNIX host
at work *and* turn my home PC off. I can easily do it with VNC; just
disconnect the client on my home PC. But I'm not sure about Exceed.
>
>>Both X-Win32 (which worked fine from a PC to the Unix host over the local
>>ethernet at work) and Exceed were so slow as to be useless. I did a
>>little
>>research, and it seems that bandwidth isn't the only issue, but also
>>"network latency." X does some kind of synchronization or something,
>>whereby packets are sent back and forth. It might be OK over an ethernet,
>>where I suppose the circuit time is on the order of 1 ms or less, but
>>over
>>something like DSL (with the circuit time being on the order of tens of
>>ms),
>>it'll just kill you.
>
> Yup, bandwidth/latency problems are why LBX was developed.
> http://studenthelp.itee.uq.edu.au/remote/lbx.html
OK.
>
>>> As for their use of the terms 'server' and 'client' I'm still a bit
>>> foggy..
>
>>In this case it's probably because their "server" is serving up a special
>>protocol that enables communication over a slower network (e.g. DSL) to be
>>do-able.
>
> Agreed.
OK.
>
>>VNC (which I actually think is fine, but my sysadmin is pushing
>>Exceed...) has the same nomenclature (i.e., the one opposite of the usual
>>X
>>nomenclature).
>
> So he wants a less-functional (costly) proprietary solution to X proxying
> instead of an Open solution which does everything desired and more? I'd
> expect that from management, not a sysadmin.
Well, he has a propensity for liking proprietary solutions.
The stupidest thing is when I got to the job a few months ago, everyone who
had to run stuff on the Sun Solaris server had a SunRay or SunBlade. *And*
they had their own PC (which they'll want in any case). I thought, "why not
just use VNC from the PC?"
It's a real pain the a** his way, because you have to constantly switch
mouse and keyboard. (And Sun and PC keyboards are slightly differently laid
out.) And as you point out his solution is more expensive.
IIRC he was pretty uptight about people connected with VNC with no
encryption. I had thought that the solution to that would be set up ssh,
but he was too lazy to do that.
Past tense above, because he was drummed out of the office Friday for some
kind of no-no. There had been no sudden failure (like lost data), just the
same continuing level of (in)competence. Some kind of non-technical ethics
thing got his butt canned.
Now we have to look for a new one...
Thanks for your replies,
S
>
> --kyler
sinister
"David Magda" <dmagda+tr...@ee.ryerson.ca> wrote in message
news:86zn358...@number6.magda.ca...
> Kyler Laird <Ky...@news.Lairds.org> writes:
>
>> Yup, bandwidth/latency problems are why LBX was developed.
>> http://studenthelp.itee.uq.edu.au/remote/lbx.html
>
> LBX isn't that useful according to Keith Packard:
>
> http://keithp.com/~keithp/talks/lbxpost/paper.html
>
> Mr. Packard did some analysis of X network performance and generally
> concluded that using SSH compression is as good as, or better than,
> using LBX:
>
> http://keithp.com/~keithp/talks/usenix2003/
>
> The main issue with SSH is it can increase latency on high bandwidth
> links. From the conclusions:
On *high* bandwidth links...
How much effect does SSH have on latency over something like DSL or cable?
sinister
"Juhan Leemet" <ju...@logicognosis.com> wrote in message
news:pan.2004.09.30....@logicognosis.com...
> On Thu, 30 Sep 2004 01:48:12 +0000, sinister wrote:
>> "Richard Santink" <rsan...@nortel.ca> wrote in message
>> news:415B4A0C...@nortel.ca...
> [snippage]
>> Both X-Win32 (which worked fine from a PC to the Unix host over the
>> local ethernet at work) and Exceed were so slow as to be useless. I did
>> a little research, and it seems that bandwidth isn't the only issue, but
>> also "network latency." X does some kind of synchronization or
>> something, whereby packets are sent back and forth. It might be OK over
>> an ethernet, where I suppose the circuit time is on the order of 1 ms
>> or less, but over something like DSL (with the circuit time being on the
>> order of tens of ms), it'll just kill you.
>
> ISTR a buddy of mine used X over serial dialup years ago. It is very slow.
> There was a way to improve it by some kind of compression (?) on the
> serial transmission, or was that some "middleware" that did something
> special with polling and/or synchronization (as you put it?). It never was
> great, but it became usable. I'm not any kind of expert in this area. If
> interested (and if no one else here recalls the method) I can try to get
> that info (but it may take time) from my buddy of years ago.
VNC is very good for this. I started the whole thread because my sysadmin,
who likes to push proprietary services, wanted us to use Exceed onDemand
rather than VNC.
>
>>> As for their use of the terms 'server' and 'client'...
>>
>> ...VNC...Exceed... has the same nomenclature (i.e., the one
>> opposite of the usual X nomenclature).
>
> I think the confusion arises because most of the punters think in terms of
> boxes, and not services. The X server provides a display service,
> therefore it obviously runs on the computer/device with the display
> attached. Services can be provided all over the place (including from
> "workstations"), so it is meaningless to talk of "THE server" (box).
Right.
> Is this all legacy from PCs attached to a (Corvus?) file/print server?
As the OP, it concerns connecting from PCs (both over high-bandwidth etheret
and over DSL/cable) to Solaris.
sinister
OK. Sorry for being testy.
>
> --kyler