Hello everyone!
I will be transferring an update app to Xojo, and I am wondering which is the best strategy. Create a web app that will also be used in administration and pass JSON data to the client communicating via the HandleSpecialUrl, or use TCP Sockets or some other way?
The client will be a Xojo desktop app which will be putting the update binaries (with the version data) in a local database…
This update is based on projects, objects and items. Each client has subscribed to one or more projects, each project has one or more objects, and each object has one or more items, each item has a version number, a binary (content) and some metadata. So what is actually transferred are the items (and the new objects) together with their metadata. I consider to use base64 encoding for the binaries and wrap them / transfer them as JSON data.
There are a few hundred clients, and the scheduled updates are during the night, hopefully not many happening simultaneously.
Almost all clients are on Windows and a few on Mac. The server part will be on a Windows Server.
Any suggestion/thought will be greatly appreciated.
Have you thought of using base85… slightly faster than base64 and smaller sized encrypted string… Just a thought:
http://forums.realsoftware.com/viewtopic.php?f=21&t=43389&sid=c5cdd1ec5b1cf41c239323c5126b6199
In a similar type application (peer to peer sharing and chat messaging), I use the Web edition as the browser front end for management and have a custom tcp based server embedded into the stand alone Web application. Clients only access the custom tcp server, all content, statistics and logging are managed via the browser front-end. This method also allows for more simultaneous connects I’ve found at better speeds; than using HandleSpecialURL to handle requests can output to the clients.
Hi Foti,
If you don’t have firewalls and proxies in the middle of client and server, go with a tcp server as Matthew described above. Also, don’t forget that HandleSpecialUrl can handle one request, on each time. So you need to forget the simultaneous connects (it creates queues), meaning more delays compare with a tcp server.
Thanks Mathew and Antonis,
I will check out the base85. Now I suppose if I need to only to privide the update services, I should use a desktop app functioning as a TCP server. Correct?
Also any suggestions on how many sockets should I have available listening? Let’s say there are 300 clients connecting over night (not simultaneously).
Foti,
Console application, with max 25 sockets. Xojo is 32bit application. I am proposing the following. Install haproxy in front of xojo application and run multiple xojo servers (10-20 servers according to your hardware). Haproxy can handle tcp connectivity. So, you can handle 300 users , on the same time.
mServerSocket.MaximumSocketsConnected=25
mServerSocket.MinimumSocketsAvailable=2
Antoni thank you for you reply,
What is the advantage in using a console application instead of a desktop app (since the desktop app can more easily display info on what is going on)?
Console app can run as service … so you don’t worry if the server restarted or not (and if the application hanged, it will restart) . Desktop app… it is not guarantee that it will start on server’s start-up and of course, it is not going to start without a human availability, if a run time error happened during the night. This is another benefit, to have a load balancing in front of the server application.
Write data on database (Sqlite), so from 3rd desktop/web application to have statistics for whats going on with the server side application.
It is possible to run a desktop application as a service using an application like FireDaemon that I use (on Windows), which also allows it to interact with the user when logged on, and, it starts automatically when the server restarts, and works when no one is logged on. Also it restarts the “service” in case of a crash actually what happens is defined by the user.
Also the data to update as well for validation and logging exist already on a Postgesql server.
Thank you very much for your input.