Hello:

I have an old delphi application (a small ERP) running on a customer. People connect using Windows Remote Desktop.

There are plans to increase the number of remote connections a lot (due crisis, many employers will work only partial time from their homes). I think that the remote desktop solution won't scale well. Licenses can be expensive and RDP wastes a lot of resources Why in the hell should we supply a full desktop when people only need to run tiny application?. Due people who connect remotely don't need the full application, just a small subset, I was thinking about programing a reduced version in Lazarus as frontend of the data, and show only the GUI remotely.

I have a couple of ideas:

Using a remote Xwindows server (Are there good Xwindows server for win32?) Making a web application using ExtJs

Any hint? New ideas? Experiences?

I would split the application in a client and a server part. The client contains the GUI part and communicates via SOAP/XML-RPC/JSON-RPC/BINARY protocol with the server part.
The server part includes business logic and data storing.

Michael

El 29/10/2012 12:07, Michael Fuchs escribi?:

Well, that would be the ideal solution, but I don't want to implement a full protocol all calls and answers.

Isn't there already a protocol defined to communicate in lazaris? Just run an application in the server but showing the GUI (Lazarus widgets etc) in the client
That is why I thought in xwindows or ExJs. I can use a RAD

Xming is one of the better Xservers for windows. I'm running 6.9.0.31 since a while on XP sp2 but from time to time it crashes which is quite annoying. I'm also quite disappointed in running lazarus gtk apps over an X tunnel. Screen updates are very very slow, even with a fast local network connection. A simple form takes sometimes seconds to load completely. You see an empty form and then after a wait, all components are shown. Refreshing after masking the window is also very slow. This is not an Xming problem but a lazarus widgetset problem. The same happens on linux clients. GTK LCL apps are generating simply too much traffic. Haven't tried QT.

Ludo

Santiago A. wrote

Using a remote Xwindows server (Are there good Xwindows server for win32?) Making a web application using ExtJs

Doctrine has it that the X protocol isn't very good over long-distance comms, i.e. anything other than an in-memory or LAN connection; it might be improved if tunneled e.g. over SSH. I've used it over a modem link in the past but I might have been lucky, and I don't think that luck has any place in the sort of scenario you're considering. An adequate Win-32 X client is XMing, noting that recent versions aren't entirely free (as I understand it).

Alternatives are something like VNC (check the encryption situation), a proprietary protocol between frontend and middleware (e.g. text command-response via an SSH tunnel), some sort of webapp with a browser at the user end, or the app running entirely at the user end with (encrypted) comms to a backend database (note that PostgreSQL and I believe Firebird allow the database to advise the app that attention is required).

I've seen this with some versions of Lazarus and Mozilla, and "very very" was a gross understatement. I believe that it was at least in part tracked down to the widget set issuing an excessive number of input requests over the network, it didn't appear to affect e.g. VNC which (from the POV of an X app) is a local server.

Santiago A. wrote

Any hint? New ideas? Experiences?

You could generate a web application, providing a browser-interface to the users via Apache or IIS.

Unfortunately Lazarus does not offer very much support for this. But some support indeed recently has been provided (I seem to remember that there had been a New-WebApplication or something like this). ( I understand that not even TTimer is usable in such a Web application.)

I once found that there is "ExtPacal"
"http://code.google.com/p/extpascal/" exactly for that purpose (on the website they mention as well Delphi as FreePascal/Lazarus).

I have no idea if this works nicely and how it is used.

-Michael

Santiago A. wrote

Using a remote Xwindows server (Are there good Xwindows server for win32?)

I once used XMing. It did work, but I think NX Free seems more advanced.

-Michael

Le 29/10/2012 12:52, Michael Schnell a ?crit :

Right. I'm using it with OpenSuse 11.2 as server and a Windows client on Vista 32. Looks perfect until now.

Antonio.

Santiago A. wrote

Well, that would be the ideal solution, but I don't want to implement a full protocol all calls and answers. Isn't there already a protocol defined to communicate in lazaris?

With the Webservice-Toolkit [1] you can easily implement this communication way.

Just run an application in the server but showing the GUI (Lazarus widgets etc) in the client That is why I thought in xwindows or ExJs. I can use a RAD

It is not faster to build a new Web-Application.

Michael

Le 29/10/2012 12:52, Michael Schnell a ?crit :

Look at http://www.nomachine.com/

Michael Fuchs wrote

With the Webservice-Toolkit [1] you can easily implement this communication way.

Sorry, forgot the link:
http://wiki.freepascal.org/Web_Service_Toolkit

Michael

You could make it a client/server application.

I have no experience on this using Lazarus, but on Delphi my colleagues very successfully use the commercial RemObjects kit, which easily provides remote procedure calls via lots of different media, including SOAP and a propriety fast compressing TCP/IP "channel". -> http://www.remobjects.com/

They claim it works with FreePascal, too, but we did not yet check this.

-Michael

Hi Santiago, did you try to run the application from a remote location?, by just publishing the database (assuming you are using a TCP database, such as Firebird, Postgresql, SQL Server, ....) port on your router, you could connect the client to the server remotely.

Leonardo M. Ram? wrote

Hi Santiago, did you try to run the application from a remote location?, by just publishing the database (assuming you are using a TCP database, such as Firebird, Postgresql, SQL Server, ....) port on your router, you could connect the client to the server remotely.

Could definitely work, but:

Having some kind of VPN or TLS encapsulation (e.g. zebedee) may be a good idea.
Firebird e.g. has effective 8 character max passwords. Not too hard to try to brute force...

El 29/10/12 14:38, Reinier Olislagers escribi?:

No matter which protocol I'll use, I will do through a SSH tunnel or VPN. Now, even remote desktop connections are done by an SSH tunnel with client private keys. The problem is not security, but performance.

I don't know why, but standard dataware controls generate a lot of traffic. Perhaps it is a problem of bad application design, but things that work properly in a LAN are almost unusable in a WAN.

Santiago A. wrote

I don't know why, but standard dataware controls generate a lot of traffic.

This is because they mostly use SOAP which produces a huge overhead. That is why we like RemObjects. which is appropriately scalable.

-Michael

El 29/10/12 14:38, Reinier Olislagers escribi?:

No matter which protocol I'll use, I will do through a SSH tunnel or VPN. Now, even remote desktop connections are done by an SSH tunnel with client private keys. The problem is not security, but performance.

I don't know why, but standard dataware controls generate a lot of traffic. Perhaps it is a problem of bad application design, but things that work properly in a LAN are almost unusable in a WAN.

That is also my experience. If a client server app is not developped from the beginning for remote access, the chances are slim that it can be easily adapted for remote access. On a local network, you won't notice a refresh of a semi-large dataset but from remote, performance goes down very quickly. Depending on the DB used, long transfer times for remote users can even cause table locks for the time of the data transfer and slow down local users. Network turn around times (ping) are more important than raw transfer speed for client server apps.

Ludo

Santiago, I don't know which database server you use, but in the case of firebird, I recommend this article:
http://asfernandes.blogspot.com.ar/2009/07/network-latency-influence-on-firebird.html

Regards,

El 29/10/2012 16:55, Leonardo M. Ram? escribi?:

That's an interesting article, thanks. This application uses Firebird,

I suppose that dataware controls do a lot of stuff behind scenes, that is why they are easy to use. As usual, easing things has the drawback that does many things that are not alway necessary but are done just in case. Authomatic process is not always optimized... but it's fast.

For example I stopped using master-detail many times because they were slow, they opened and closed the detail after each scroll of master. Instead, many times I open both and skip the cursor in the detail. Other times, I create a big join with header registers repeated in every record instead of sending two SQLs.
Of course it requires more work than just dropping a few components on the form/datamodule.

That is why I expected some kind of widget that sends just graphic updates, just draws the controls on client side, but data components on the server don't send any data to the client.

give a look to this product:

http://thinstuff.com/

DF

also:
http://www.terminalserviceplus.com/

DF

El 29/10/2012 18:10, duilio foschi escribi?:

Thinstuff is a good alternative to Microsoft Terminal server, I have used before.

Nevertheless, that's remote desktop solution. There is a limit of the simultaneous users a server can support, no more than five without severe performance impact. I want perhaps more than 20 users. Should I install five PCs?

If I could solve with a simple application, that would be easier.

2012/10/29 Antonio Fortuny :

NX also has the advantage you can just forward one application only, not the entire desktop. A possible setup would be:

* write the application in Lazarus as usual, compile and install it on a Linux box (so that it would operate normally if a local user sitting in front of this linux pc started it it locally)

* install ssh server and freenx on this linux machine

* create a user account for every remote user with normal linux administration tools.

* install nx client on the windows machine, configure it so that on login it will start your application (not the desktop session, only your application.

It will behave similar to old school X11 tunneling a single application through an SSH tunnel, only 1000 times faster and workable even on 56k modem connections. It will *not* start a full desktop session for every user, it will essentially only start your application as the only process for that user and will seamlessly integrate all its windows into the client desktop.

Its easy to use for your users, essentially the user just clicks an icon, enters his password, clicks ok and a few seconds later your application will pop up on his desktop.

you don't need to design the application in any special way, you just need to make it work on Linux/GTk2 (or Qt). Setup of nx on the server is a childs play, at least on ubuntu, the last time i installed it from scratch I did not need to configure anything, it just worked, just make sure you can reach your ssh-server from the outside).

Technically it works like this:
* client logs in via ordinary ssh, gets a remote shell on the server
* client executes (through that remote shell) a script that starts nx display proxy (yes, there is no permanent nx server process running and waiting, only a thin wrapper gets started through the ssh shell for each user after login, thats why the only thing that needs to be configured is the ssh server) and then it starts your application.
* display and user interaction for this application (and all its child processes and windows) will then be tunneled through the same ssh connection.

El 29/10/2012 18:43, Bernd escribi?:

Thank you very much, that is exactly what I wanted. What about performance and latency?

Bernd wrote

NX also has the advantage you can just forward one application only, not the entire desktop.

This sounds great for another purpose, that I supposedly will be facing next year: Doing a "headless" embedded device with ARM/Linux and allow for a remote user (via TCP/IP, maybe SSH) see the GUI of a Lazarus application that runs permanently.

On top of what you describe, there seem to be theses additional issues:

1) the "Server" is an ARM device
2) the application is already running (supposedly showing it's GUI on some virtual Desktop provided by the NX infrastructure) when NX attaches to it.

But here it's possible (and decent) to allow for just a single NX connection. :-)

Do you think this is possible ?

Thanks
-Michael

2012/10/29 Santiago A. :

Thank you very much, that is exactly what I wanted. What about performance and latency?

There still is a noticeable delay but it is orders of magnitude faster than VNC or conventional X11 tunneling. It is comparable to the performance of RDP.

You should try it and judge yourself:
http://www.nomachine.com/testdrive.php
(you can either try a complete Gnome session or a few selected applications alone)

And then you should try to setup a server yourself to see how it behaves in your environment.

BTW: I'm not trying to make advertisement for a nomachine here, there exist open source implementatios for most of this stuff (the X11 compression and caching protocol is based on open source code anyways), the server side (for Linux) is available through freenx (free, open) and the commercial windows client from nomachine is available at no charge, so it is possible to make all kinds of experiments with this technology or even setup a production environment without paying for any licenses.

You should also test whether it is possible to mount local media and printers if this is needed for your application, I have NOT tested this because I used it only during a limited period of 6 months last year and only to gain remote access to some applications that did NOT need local printers and local drives.

Also other commercial solutions have been mentioned, you should compare all features and try to test-drive them all. I *personally* would try to choose NX again (with freenx on the server) because essential parts of it are based on open source protocols and libraries and it is mainly centered around Linux on the server side but your mileage might vary.

2012/10/30 Michael Schnell :

1) the "Server" is an ARM device 2) the application is already running (supposedly showing it's GUI on some virtual Desktop provided by the NX infrastructure) when NX attaches to it.

* It is possible to attach to a local running desktop (only to the entire Desktop as far as I know) but then the performance degrades heavily and becomes a bad as VNC because it seems then it cannot do the efficient X11 compression and caching and needs to fall back to VNC protocol, I'm not sure if there are any advantages over VNC in this case.

* You can start a virtual session through nx and detach from it and later re-attach, then there won't be performance problems but then you need to start the application inside an NX session (I'm not sure how easy it is to initiate this locally (on boot) to create a detached session with the application running in it without the client actually connecting and creating it (maybe a scripted local nx client connecting to localhost, starting the application and then immediately detaching from it, might be possible with some advanced scripting trickery).

Alternatively split your application into a service that is started at boot an running always and a GUI that can be started and stopped at any time without interfering with the ongoing operations of the service. This seems to look like a much cleaner solution to your scenario.

Bernd wrote

* It is possible to attach to a local running desktop (only to the entire Desktop as far as I know) but then the performance degrades heavily

I don't see why this should be that way, but I would need to do further investigations to find out if/how this can be avoided when time should come to it.

Alternatively split your application into a service that is started at boot an running always...

Of course for beset performance you even would do client/serve via TCP/IP. But unfortunately the Application is not mine and too extensive modifications can't be done.

Thanks a lot,
-Michael

2012/10/30 Michael Schnell :

Its probably because of the way NX hooks into the X11 protocol. When started inside an NX session the applications will *not* connect to the real xorg xserver but to the virtual NX display server instead which then does all kind of caching and compression of the X11 protocol when forwarding it to the real display on the client side. Its probably not posible to do the same when the applications are already connected to an existing xserver, then it can not intercept and redirect the X11 communication directly it can only do what vnc would do: move the final resulting bitmaps over the network that drop out of the other end of the xorg xserver.

I understand that there are (at least) two ways to do the remote display.

A) Read the pixels from the graphics driver. This is what VNC does. The problem here is, that you don't know when an update is necessary (and thus you need to do polling) and that reading the pixels needs a lot of performances (get a GDI-handle, read the complete screen memory via the bus and then transfer only the pixels that have changed). (In fact some time ago I stole this code from VNC, translated it from C to Pascal and did a thingy that could transfer a rectangle of the screen via TCP to another PC.)

or

B) Hook into the interface between the application and the Windows manager. This is what Linux "Remote X" and Windows "Remote Desktop" do. VirtualBox (and supposedly VMWare) seems to be able to do do this, too, and here I did already see that it is possible to virtualize a single program rather than a complete Desktop.

Seemingly NX can do both, depending on the situation.

It's understandable that doing (B) is at least "difficult", when you want to attach to a running program, as supposedly a program transfers some information when starting and the Window manager needs to know same even when it requests a full repaint. But obviously Windows "Remote Desktop" can handle this problem decently.

So attaching to an already running program (not the Desktop it runs on) using (B) is not that easy :-( . Maybe it's possible to something like starting another instance of the program with NX in the way you originally described and do some magic within the program itself to meld the running instance into the newly started one. (Just raving...)

-Michael

El 31/10/2012 10:13, Michael Schnell escribi?:

I suppose that NX not only compress, but decides from the server (in behalf the client application) what must be send to the client (the graphic server). A lot of things needn't to be send, a lot of things can be joint and send only the final result, and a lot of commands can be queued, cached and sent in less commadds. And the other way around, the client (the graphic server) needent to sent everything.

I suppose that NX does smart decisions filtering what needs to be sent in both directions, so saves a lot of traffic and round trips.

X11 It is acceptable when in a local machine, but not for remote machines, let alone a WAN. I've heard that the problem is in a poor use of X11 of libraries like gtk or qt, I've also heard that the problem is in xlib, the common libarry of most widgets that doesn't optimize the protocol.

I have also heard that X11 is a too low level protocol and should be replaced. There have been some tries like
http://en.wikipedia.org/wiki/Fresco_%28windowing_system%29. In fact, that is what javascript and ajax tries, send widgets etc.

Some /free software/ VNC implementations (e.g. UltraVNC) install their own display driver [under Windows] to exactly know /when/ update is needed and where.

-Michael

Lukasz

Lukasz Sokol wrote

Some /free software/ VNC implementations (e.g. UltraVNC) install their own display driver [under Windows] to exactly know /when/ update is needed and where.

Good to know !

Thanks,
-Michael