🚀 go-pugleaf

Hans Galema wrote:

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

Well, because in this, the simplest scenario, the client doesn't have
any data. It's a separation-of-function thing. In cutting up the
original application, the simplest "joint" is between the UI and the
app logic. That joint for my console app is cputs/keyin. Simple enough
to replace.

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

60 isn't a hard number, it's an off-the-cuff value. But, yeah, that
seems like a lot of instances to be running on a single cpu.

>> CreateProcess().
>
>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.

True, but...
If the applet is assigning ports, then if it could be notified that an
instance of the application has terminated, it could recycle that
port. The alternative would be for the application to send a message
to the applet, and occasionally, we know that doesn't happen.
{But, reading on, if ports are truely magic, then I wouldn't need to
"know" unless I wanted to meter the number of seats. Which might also
be a nice way to limit the server load.}

>> Or should I forget "Service", and just make it an ordinary app?
>
>An ordinary app would do I think. Why would not it ?

Dunno...that's why I asked...

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

Is that magic? Or do I have to assign those different ports?
I was thinking it wasn't magic. (plain Win32 APIs)

> You do not have to do anything for that.
>The sockets handle all.

So it is auto-magical, then.

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

I like that, but unfortunately, I'm a big user of globals, and they
don't play well with threads. This would entail very heavy rework
indeed. {Ask for examples of the (mis)use if you are curious}

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

Yes, it is. There would be a more complex interface, and it would use
more bandwidth (thus slower) than the other methods (but still, faster
than today's).

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

Yes. Customer said it took 5 minutes to bring up the application, then
another 15 minutes for one function to start over VPN.  Lan is maybe 5
seconds. On-server, about 1.

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

Fair enough.
KVM - multi instance, very easy.
KVM - multi-thread, very hard.
FileServer - somewhat complex.

Thank you for your input.
I didn't want to go ripping into my code only to find out after all
was finished and deliverable, that this sort of thing just wasn't
done.