🚀 go-pugleaf

Hans Galema wrote:

Thanks, Hans.

>Sorry but you are just summing up a bunch of things and with
>every new one I think "Where is this all about?".

Yeah, I can ramble sometimes.
And, I've gotten ahead of myself on this post too...
Lots of questions that may be moot.
But the mind is churning, trying to consider all angles....

>Could you please start to explain about how many programs you
>are talking? And then what each program should do?

Current:
One application (99% console, 1% GUI because radio buttons are a pain
in console mode).
It runs their business (Customer records, Invoicing, A/R, etc.)
Perhaps 10+ users, maybe 1 to 6 sessions(consoles) per user.
Exe is 1 Mb, uses 4 when loaded, and may expand to 20+ under use.
Standard DOS-style file i/o pulls lots of files off the server, then
updates randomly (with proper multiuser locking, etc).
Goal: reduce network usage. (VPN bandwidth seems to be rather small)

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.

>And then please state the subjects where you need advise.
Just to be extra clear, I've added  {advise?}  at answer points LOL.

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".

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?}

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?}
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.

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?}
ThirdPointFive:
Or should I forget "Service", and just make it an ordinary app?
	{advise?}

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?}

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)

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