🚀 go-pugleaf

Bob Gonder wrote:

> Proposed:
> Hack the user i/o out of the application.(easy)
> Put the user i/o in a new Client.
> Add a connection facilitator to connect clients with new instances of
> the hacked application on the server.

As far as I can see all the possibilities you describe are more
or less possible. Now which one you are going to implement is
up to you. Indeed the different solutions and the problems
to overcome take a different amount of time.

> First:
> Advisability of having a server app that runs the entire application,
> not just file services, all calculations (no FP), all logic,
> everything but keyboard, mouse and video.
>  Only thing the server would send to client would be 99% ascii screen
> info, and a couple messages.
>  Only thing client would send is keyboard/mouse info, and results of
> messge boxes and perhaps some piddly messges like "I've been aborted".

That is possible. But maybe a bit too. Why would not a client do a
calculation if it has all data to do so ?

> I'm a bit concerned that this is an "unfriendly" way to go. But I
> don't know servers, or what other people do with them, so maybe this
> is an acceptable burden on the server machine?	{advise?}

Think that every one has it's own ideas about what a server does.
And there are so many types.

It is up to you to decide if the servercomputer can run 60 instances
of your 'server'program (60: see my other post).

> Second, if the above is acceptable, some deatils of how to do it?
> I'm thinking a very tiny app that sits on the server and listens for a
> specific UDP from a client, and then hooks up that client with a new
> instance of the main application (on the server). The client and
> application would then communicate via TCP/IP.
> 
> Does that sound right?	{advise?}

That is a possibility. Every instance of your server application
has to listen on a different port. So the applet should be
able to start your application with the nextportnumber. After having
done that it should tell the client wich serverport to use.

If you could manage to make your server stop listening after
a succesfull connection (thereby keeping the connection ) then the
next server could use the same port. (This would be a nice
question for the sockets ng).

> Or should the large app listen, and launch another instance?
> But that would raise "last-man-standing" issues (must leave one
> running). The tiny servlet wouldn't have that problem.

Possible too. You have the same problem with the serverport here.
And then who is gonna tell the client ? Well the client could just
try all kind of ports ? And indeed a last-man problem. Who will
solve that ?

> Third:
> If the tiny applett is installed as a service, as I think Remy hinted
> at a year ago, would it use CreateProcess() to launch the main
> application on behalf of each client, or would it need to use
> CreateProcessAsUser().	{advise?}

Don't know why it would. Sorry I never used those functions. I would
just use ShellExecute() as then the responsability of the new process
is not in hands of the tiny applet.

> ThirdPointFive:
> Or should I forget "Service", and just make it an ordinary app?
> 	{advise?}

An ordinary app would do I think. Why would not it ?

> Fourth, just thought of this...
> When a user opens a second client, the servelet (and app) is going to
> see the same IP as a previous instance, so I suppose they would need a
> different port for each client? (Chosen by the Client?)	{advise?}

That is no problem at all. The server listens on a specific port. If a
client wants to connect to the server it uses that port together with
an IP or hostname (ServerIP:serverport). Once a connection is established
the communication is done over a different 'communication'port which is
different for every client. You do not have to do anything for that.
The sockets handle all. If you start many clients from the same computer
then they are distinghuishable for the servercomputer by
ClientIP:communicationport and for your serverprogram also in this way,
but also by every client having it's own socket instance.

> Last:
> If the above just isn't acceptable, then, I think I would need to do a
> much harder re-write. And I see 2 ways to go:
> 
> 1) Same as above, but Multi-thread the application so there would be a
> single application running on the server, and it would start a new
> thread for each client, instead of starting a new instance. (less
> memory usage than the above method, I'm sure)(very hard)

That is the way to go indeed.

> 2) Hack the file i/o out of the application, and put it on the
> server(somewhat hard).	{advise?}

If file i/o is the botttleneck than yes. One server who loads
all files. A client does not request a complete "Customer database"
but only a record for a specific customer. You would need a
command to get the record for reading and another to get it
for writing. If you huse already someting like getrecord() then
good doable.

Is the constipation due by network/VPN THE reason that you have
to rewrite the app ? "Goal: reduce network usage.". Has it
become to slow for the user who waits to much for data to
arrive? Or do they have to pay for every byte sent ?

As I can not know how much time each solution would cost you
or all the difficulties you would encounter I'm unable
to put you an a specific path.

You have thought about it a lot I can see.

Hans.