Hi, I want to use sme WiFi-enabled PDAs as "wireless terminals". I.e., in much the same way that X terminals operate (though obviously not using XDMCP, etc. -- OTOH, that would make life a lot easier! :> ) A browser interface is out because the browser has functionality that the application can't disable (e.g., history, font selection, etc.). I've never used "terminal services" (there is a TS client built into the PDAs) but suspect it is MS's version of X -- *tied* to a MS implementation (I want an open source solution). Does anything like this *already* exist or do I have to write a simple protocol to do it? Maybe port something like Xnest? Thx, --don
PDA as "X terminal"
Started by ●October 11, 2010
Reply by ●October 11, 20102010-10-11
D Yuniskis <not.going.to.be@seen.com> writes:>I want to use sme WiFi-enabled PDAs as "wireless terminals". >I.e., in much the same way that X terminals operate (though >obviously not using XDMCP, etc. -- OTOH, that would make life >a lot easier! :> )>A browser interface is out because the browser has functionality >that the application can't disable (e.g., history, font selection, >etc.).>I've never used "terminal services" (there is a TS client built >into the PDAs) but suspect it is MS's version of X -- *tied* to >a MS implementation (I want an open source solution).Note, an X Terminal is an X11 Server, which implies what it says, its fairly heavy server process sitting there waiting to render your screen. I'd imagine that running an X server in a PDA would be a bit beyond its capabilities now-a-days, but then again what they had long long ago would be less than what a PDA had now-a-days. But the current X server code is assuming much bigger systems as well now. Yes, Terminal Services is just like its more common name, remote desktop says. You see a desktop remotely just like your windows desktop. There are open-source remote desktop clients. The protocol has to be reverse engineered, but it does work.>Does anything like this *already* exist or do I have to write >a simple protocol to do it? Maybe port something like Xnest?You didn't mention probably the most used protocol (or any of the 100's of things built on top of it), VNC. That is truely opensource, and ported to everything under the Sun. Many vendors co-opt it to do their own (ie. Mac Screen Sharing, VMWare, Parallels, etc. etc). Not that I think VNC is all that responsive compared to RDC or other proprietary ones, but it does seem to be inuse everywhere.
Reply by ●October 11, 20102010-10-11
On Mon, 11 Oct 2010 13:20:34 -0700, D Yuniskis wrote:> I want to use sme WiFi-enabled PDAs as "wireless terminals". > I.e., in much the same way that X terminals operate (though > obviously not using XDMCP, etc. -- OTOH, that would make life > a lot easier! :> ) > > A browser interface is out because the browser has functionality > that the application can't disable (e.g., history, font selection, > etc.). > > I've never used "terminal services" (there is a TS client built > into the PDAs) but suspect it is MS's version of X -- *tied* to > a MS implementation (I want an open source solution). > > Does anything like this *already* exist or do I have to write > a simple protocol to do it? Maybe port something like Xnest?For a PDA, VNC (or similar) is probably a better option, as: 1. It pushes most of the work onto the application server; an X server has to do the rendering itself (and to work with modern applications, may need to support the Render and/or GLX extensions as well as the core X protocol). 2. VNC has relatively fixed overhead. An X server needs to be able to store arbitrary amounts of data (e.g. the X version of FireFox will store every image on the X server as a Pixmap). 3. VNC doesn't rely upon the client maintaining state. You can disconnect from and reconnect to the desktop at will. If you terminate an X server, any connected clients will typically terminate. Terminal Services aka Remote Desktop Services seems to be Microsoft's version of VNC. There are several Linux RDP clients, which suggests that the protocol is reasonably well known. There is also a Linux RDP server (Xrdp), but this doesn't seem to be particularly active: http://xrdp.sourceforge.net/
Reply by ●October 11, 20102010-10-11
2010-10-11 22:20, D Yuniskis skrev:> Hi, > > I want to use sme WiFi-enabled PDAs as "wireless terminals". > I.e., in much the same way that X terminals operate (though > obviously not using XDMCP, etc. -- OTOH, that would make life > a lot easier! :> ) > > A browser interface is out because the browser has functionality > that the application can't disable (e.g., history, font selection, > etc.). > > I've never used "terminal services" (there is a TS client built > into the PDAs) but suspect it is MS's version of X -- *tied* to > a MS implementation (I want an open source solution). > > Does anything like this *already* exist or do I have to write > a simple protocol to do it? Maybe port something like Xnest? > > Thx, > --donHave a look at the "www.openembedded.org" project. This will run Linux and X-Windows on a lot of different targets, including some Compaq PDAs. Best Regards Ulf Samuelsson
Reply by ●October 11, 20102010-10-11
Greetings Doug, Doug McIntyre wrote:> D Yuniskis <not.going.to.be@seen.com> writes: >> I want to use sme WiFi-enabled PDAs as "wireless terminals". >> I.e., in much the same way that X terminals operate (though >> obviously not using XDMCP, etc. -- OTOH, that would make life >> a lot easier! :> ) > >> A browser interface is out because the browser has functionality >> that the application can't disable (e.g., history, font selection, >> etc.). > >> I've never used "terminal services" (there is a TS client built >> into the PDAs) but suspect it is MS's version of X -- *tied* to >> a MS implementation (I want an open source solution). > > Note, an X Terminal is an X11 Server, which implies what it says, > its fairly heavy server process sitting there waiting to render yourCorrect. Though just how heavy depends a lot on the implementation, extensions supported, etc.> screen. I'd imagine that running an X server in a PDA would be a bit > beyond its capabilities now-a-days, but then again what they had long > long ago would be less than what a PDA had now-a-days. But the current > X server code is assuming much bigger systems as well now.There's the rub. Obviously, PDA's *today* are considerably more powerful than the machines at Athena "ages ago". OTOH, X is considerably more *bloated* than it was, back then. I think that a pared down server could easily run on the sort of iron available on a PDA -- though you would probably have to strip off the existing "OS" (I am not familiar enough with the internals of the various handheld OS's to know how well they could handle preemption, etc.)> Yes, Terminal Services is just like its more common name, remote > desktop says. You see a desktop remotely just like your windows > desktop. There are open-source remote desktop clients. The protocol > has to be reverse engineered, but it does work.What about server-side support? (i.e., I don't want to run windows *anywhere*!)>> Does anything like this *already* exist or do I have to write >> a simple protocol to do it? Maybe port something like Xnest? > > You didn't mention probably the most used protocol (or any of the > 100's of things built on top of it), VNC. That is truely opensource, > and ported to everything under the Sun. Many vendors co-opt it to > do their own (ie. Mac Screen Sharing, VMWare, Parallels, etc. etc). > > Not that I think VNC is all that responsive compared to RDC or other > proprietary ones, but it does seem to be inuse everywhere.My original experiences with VNC left a really bad taste in my mouth. E.g., I'll run an X server (on a PC, Sun boxen, X terminal, etc.) instead of dealing with VNC. I think the protocol leaves too much to the "application side" in terms of rendering, etc. E.g., put 30 or 40 "VNC clients" (blech, it gets hard being pedantic with C-S terminology in this regard) on a single "server" and I think things get sluggish. (I suspect the "server" also ends up seeing a bigger overall load -- VNC doesn't seem to have been designed with multiple sessions in mind?) My users are not tech savvy. Some have neurological "issues" that make anything marginally complicated impossible for them to use. E.g., they would be hard pressed to realize that the network connection was "down" unless something *locally* could interact with them to, in effect, tell them "please wait" or "session disconnected", etc. Anything I can do to move smarts (not necessarily "processing"!) to the "application server" side while leaving some application-specific intelligence in the "display server" helps make the system more usable. A generic service might be too sophisticated for them, as users, to use effectively. --don
Reply by ●October 11, 20102010-10-11
Nobody wrote:> On Mon, 11 Oct 2010 13:20:34 -0700, D Yuniskis wrote: > >> I want to use sme WiFi-enabled PDAs as "wireless terminals". >> I.e., in much the same way that X terminals operate (though >> obviously not using XDMCP, etc. -- OTOH, that would make life >> a lot easier! :> ) >> >> A browser interface is out because the browser has functionality >> that the application can't disable (e.g., history, font selection, >> etc.). >> >> I've never used "terminal services" (there is a TS client built >> into the PDAs) but suspect it is MS's version of X -- *tied* to >> a MS implementation (I want an open source solution). >> >> Does anything like this *already* exist or do I have to write >> a simple protocol to do it? Maybe port something like Xnest? > > For a PDA, VNC (or similar) is probably a better option, as: > > 1. It pushes most of the work onto the application server;Yes. Put 40 "clients" on that box (i.e., 40 different users/sessions) and the "server" sees a markedly bigger load. Meanwhile, all that processing power in the PDA is sitting there waiting for "keystrokes"...> an X server has to do the rendering itselfCorrect. But, what *else* is it doing? (in my case, nothing)> (and to work with modern applications, may need > to support the Render and/or GLX extensions as well as the core X protocol).Ah, but *I* write the applications. We're not talking about a general purpose appliance -- rather, a "remote display for product 'foo'". No need to support multimedia, font service, etc.> 2. VNC has relatively fixed overhead. An X server needs to be able to > store arbitrary amounts of data (e.g. the X version of FireFox will store > every image on the X server as a Pixmap).But I'm not running firefox on the PDA! And, it only needs to store whatever *my* application needs to do it's job. Again, you're thinking of a generic solution; I'm looking for a *specific* solution. I could opt to pre-store every image *in* the application on the handheld just to improve responsiveness, etc. -- since I *know* how many images there are, how big they are, when/'where they are used, etc.> 3. VNC doesn't rely upon the client maintaining state. You can disconnect > from and reconnect to the desktop at will. If you terminate an X server, > any connected clients will typically terminate.Yes, that's a desirable feature. Turn off your PDA and your session ends. No need to explicitly "logout"/login, etc. If the application server can't find you, the session *should* be closed (if a connection "drops", I will silently reauthenticate when you move to the next access point, etc. -- but, the application server needs to know that this is happening)> Terminal Services aka Remote Desktop Services seems to be Microsoft's > version of VNC. There are several Linux RDP clients, which suggests that > the protocol is reasonably well known. > > There is also a Linux RDP server (Xrdp), but this doesn't seem to be > particularly active: > http://xrdp.sourceforge.net/Yes, I had looked at that a while back and was disappointed that a BSD port didn't exist. The advantage of RDP/TS is that there is a client on many of the PDAs I am exammining. OTOH, the drawback is that it is an existing client with its own behavior *and* that it coexists with other apps on the PDA (I want a "remote terminal"... not a "PDA that also can be a remote terminal when you're not playing solitaire, etc.") I'll set up a windows box and enable RDP and see what the experience is like. I don't think it is possible (with OOTB licensing) to run *dozens* of sessions concurrently (?) so it might be hard to get a feel for how things would behave under load... --don
Reply by ●October 12, 20102010-10-12
On Oct 12, 5:18=A0am, D Yuniskis <not.going.to...@seen.com> wrote:> Nobody wrote: > > On Mon, 11 Oct 2010 13:20:34 -0700, D Yuniskis wrote: > > >> I want to use sme WiFi-enabled PDAs as "wireless terminals". > >> I.e., in much the same way that X terminals operate (though > >> obviously not using XDMCP, etc. -- OTOH, that would make life > >> a lot easier! =A0:> ) > > >> A browser interface is out because the browser has functionality > >> that the application can't disable (e.g., history, font selection, > >> etc.). > > >> I've never used "terminal services" (there is a TS client built > >> into the PDAs) but suspect it is MS's version of X -- *tied* to > >> a MS implementation (I want an open source solution). > > >> Does anything like this *already* exist or do I have to write > >> a simple protocol to do it? =A0Maybe port something like Xnest? > > > For a PDA, VNC (or similar) is probably a better option, as: > > > 1. It pushes most of the work onto the application server; > > Yes. =A0Put 40 "clients" on that box (i.e., 40 different users/sessions) > and the "server" sees a markedly bigger load. =A0Meanwhile, all that > processing power in the PDA is sitting there waiting for "keystrokes"...Hi Don, 40 clients served simultaneously over RFB (VNC) would be a significant load indeed. My netMCA product line relies practically only on VNC for user access and maintaining a live 800x600, 16 bpp frame takes about 10% of the power of a 400 MHz mpc5200b (not counting networking overhead, just frame change detection and compression). Then it runs under DPS, which is particularly friendly to it. I have limited the number of connected users to 2 (just at the highest level, there are constantly up to 2 VNC server tasks running). But there is another significant advantage of using VNC. The (freely!) available clients (and most notably realVNC, the best in my experience) will listen for an incoming RFB connection. This can be the solution to a load of security issues, e.g. with the netmca you can set it up so it will persistently "call" some host and put it behind a NAT router (uhm, that makes my limit being actually 3 users :-), I did not count that one above). Works great, will come back after all sorts of network failures etc. (I have made it really persistent :-) ). All that said, VNC is a good choice only if the server has its display framebuffer anyway. Which does not have to be very large, of course, so it won't necessarily take a 400 MHz power beast (which has no problems to maintain an SXGA 16 bpp frame). Dimiter ------------------------------------------------------ Dimiter Popoff Transgalactic Instruments http://www.tgi-sci.com ------------------------------------------------------ http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/
Reply by ●October 12, 20102010-10-12
Hi Ulf, Ulf Samuelsson wrote:> 2010-10-11 22:20, D Yuniskis skrev: >> >> I want to use sme WiFi-enabled PDAs as "wireless terminals". >> I.e., in much the same way that X terminals operate (though >> obviously not using XDMCP, etc. -- OTOH, that would make life >> a lot easier! :> ) >> >> Does anything like this *already* exist or do I have to write >> a simple protocol to do it? Maybe port something like Xnest? > > Have a look at the "www.openembedded.org" project. > This will run Linux and X-Windows on a lot of different > targets, including some Compaq PDAs.Hmmm... I didn't see any devices that I recognized. I *think* I could go the NetBSD route if I wanted to wipe the PDAs. I was hoping to find something that would coexist, intially, with the native OS so I don't have to do major surgery just to evaluate the technology... --don
Reply by ●October 12, 20102010-10-12
On 12/10/2010 04:05, D Yuniskis wrote:> Greetings Doug, > > Doug McIntyre wrote: >> D Yuniskis <not.going.to.be@seen.com> writes: >>> I want to use sme WiFi-enabled PDAs as "wireless terminals". >>> I.e., in much the same way that X terminals operate (though >>> obviously not using XDMCP, etc. -- OTOH, that would make life >>> a lot easier! :> ) >> >>> A browser interface is out because the browser has functionality >>> that the application can't disable (e.g., history, font selection, >>> etc.). >> >>> I've never used "terminal services" (there is a TS client built >>> into the PDAs) but suspect it is MS's version of X -- *tied* to >>> a MS implementation (I want an open source solution). >> >> Note, an X Terminal is an X11 Server, which implies what it says, its >> fairly heavy server process sitting there waiting to render your > > Correct. Though just how heavy depends a lot on the implementation, > extensions supported, etc. > >> screen. I'd imagine that running an X server in a PDA would be a bit >> beyond its capabilities now-a-days, but then again what they had long >> long ago would be less than what a PDA had now-a-days. But the current >> X server code is assuming much bigger systems as well now. > > There's the rub. Obviously, PDA's *today* are considerably more > powerful than the machines at Athena "ages ago". OTOH, X is > considerably more *bloated* than it was, back then. > > I think that a pared down server could easily run on the > sort of iron available on a PDA -- though you would probably > have to strip off the existing "OS" (I am not familiar > enough with the internals of the various handheld OS's > to know how well they could handle preemption, etc.) > >> Yes, Terminal Services is just like its more common name, remote >> desktop says. You see a desktop remotely just like your windows >> desktop. There are open-source remote desktop clients. The protocol >> has to be reverse engineered, but it does work. > > What about server-side support? (i.e., I don't want to > run windows *anywhere*!) > >>> Does anything like this *already* exist or do I have to write >>> a simple protocol to do it? Maybe port something like Xnest? >> >> You didn't mention probably the most used protocol (or any of the >> 100's of things built on top of it), VNC. That is truely opensource, >> and ported to everything under the Sun. Many vendors co-opt it to do >> their own (ie. Mac Screen Sharing, VMWare, Parallels, etc. etc). >> Not that I think VNC is all that responsive compared to RDC or other >> proprietary ones, but it does seem to be inuse everywhere. > > My original experiences with VNC left a really bad taste > in my mouth. E.g., I'll run an X server (on a PC, Sun boxen, > X terminal, etc.) instead of dealing with VNC. I think the > protocol leaves too much to the "application side" in terms > of rendering, etc. E.g., put 30 or 40 "VNC clients" (blech, > it gets hard being pedantic with C-S terminology in this > regard) on a single "server" and I think things get sluggish. > (I suspect the "server" also ends up seeing a bigger overall > load -- VNC doesn't seem to have been designed with multiple > sessions in mind?) > > My users are not tech savvy. Some have neurological "issues" > that make anything marginally complicated impossible for them > to use. E.g., they would be hard pressed to realize that > the network connection was "down" unless something *locally* > could interact with them to, in effect, tell them "please wait" > or "session disconnected", etc. > > Anything I can do to move smarts (not necessarily "processing"!) > to the "application server" side while leaving some > application-specific intelligence in the "display server" > helps make the system more usable. A generic service might > be too sophisticated for them, as users, to use effectively. > > --donLet me get this straight - you dismiss browser solutions because local settings (like fonts) will affect the appearance, yet you want a local X server on the PDA? And you dismiss VNC because it is too demanding on the application server side? First off, I'd recommend looking at a browser solution again. It is definitely the most flexible for the PDA side, as it will work with the largest number of models, it is the lightest in bandwidth requirements, and it is the lightest in application server load. Consider things like using simple fonts, passing data using ajax (or comet) to avoid any history issues (since everything is on a single page as far as the browser is concerned), and toolkits like pyjamas to get a nice layout. Also look at java applets - most PDAs will support them. I think you need to work a lot harder here before dismissing this setup, as it has so many advantages. A local X server on the PDA will have far more issues with local fonts and setup, is technically very difficult for users, and will cause endless problems on different PDAs. Consider this only as a plan C or D if everything else fails. VNC works well, and has a lot of versatility. The VNC of today is not the same as it used to be - there are many implementations that provide lots of features. It used to be very heavy on the application server side - a VNC server is actually an X server in itself, running on the application server. But these days the VNC server is lighter if you set it up properly (i.e., don't run KDE on the VNC server!) and can be arranged to run just a single application. A modern application server should be happy serving out a lot of such sessions. It is also possible to share sessions between clients, if that suits your usage. And since there are java clients, VNC will also work with PDAs that lack a VNC client. Another alternative is NoX, if you can get PDA clients for it. NoX clients are simplified X servers, and use a much more efficient version of X for communication between the NoX server and client. You can also look at running an rdp server on the application server. Then you can use standard rdp clients on the PDAs. I don't think rdp servers for Linux are as advanced or well-established as VNC servers, but they may be good enough and the protocol uses less bandwidth (it's similar to NoX in bandwidth).
Reply by ●October 12, 20102010-10-12
On Mon, 11 Oct 2010 19:05:01 -0700, D Yuniskis wrote:> My original experiences with VNC left a really bad taste > in my mouth. E.g., I'll run an X server (on a PC, Sun boxen, > X terminal, etc.) instead of dealing with VNC. I think the > protocol leaves too much to the "application side" in terms > of rendering, etc. E.g., put 30 or 40 "VNC clients" (blech, > it gets hard being pedantic with C-S terminology in this > regard) on a single "server" and I think things get sluggish. > (I suspect the "server" also ends up seeing a bigger overall > load -- VNC doesn't seem to have been designed with multiple > sessions in mind?)"VNC" tends to refer to the protocol. In terms of implementations, you have: 1. Xvnc, i.e. an X server which renders to a framebuffer which is shared via the VNC protocol. Portable, but no hardware acceleration. 2. x11vnc, which shares the framebuffer of an existing (and possibly hardware-accelerated) X server. 3. Dedicated applications which manage their own framebuffer(s) and use libVNCServer to share these. One process can service multiple clients. It can render the framebuffer how it likes, i.e. it can use software rendering or it could use an X server for acceleration. However you do it, VNC isn't going to take advantage of any hardware acceleration available on the "terminal" (except perhaps blits). How much of a disadvantage this is depends upon what hardware is available. If you want a primitive-based protocol rather than a pixel-based protocol, it's probably either X or roll-your-own. In the latter case, it would make sense to design it to fit the hardware (about which you haven't said anything).