IDEA: Before multithreading: Multi-processing

Development directions, tasks, and features being actively implemented or pursued by the development team.
Post Reply
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

IDEA: Before multithreading: Multi-processing

Post by chuck_starchaser »

IDEA: Before multithreading: Multi-processing

Yep, you read that right.
Before we think about splitting threads, we should split an obvious process. Which? A local server.
Why?
Because that's how the engine should have been structured in the first place...
...and because all the infrastructure should be in place already.

We have separate executables for vegastrike and vegaserver.
Vegaserver does physics and collision.
The client side engine has like a built-in server, firmly parasiting on the rest of the code.
A locally running vegaserver would have no appreciable latency, and therefore could remove the
need for the client to compute physics and collision.
In the case of single player mode, the local server simply takes over a hefty workload away from
the vegastrike executable.
In the case of multi-player mode, the local server additionally takes on the task of communicating
with the remote server, and acts as a proxy for it.

VERY simple way to cut the medusa roughly down the middle.
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: IDEA: Before multithreading: Multi-processing

Post by klauss »

Not simple.

The multiplayer server lacks serious features, like campaign stuff.

It would be a major endeavor to cut things the way you propose.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: IDEA: Before multithreading: Multi-processing

Post by chuck_starchaser »

klauss wrote:Not simple.

The multiplayer server lacks serious features, like campaign stuff.
The vegastrike executable has the campaign stuff. I didn't say the local server would do EVERYTHING.
Just whatever it does currently is probably good enough.
It would be a major endeavor to cut things the way you propose.
You saying that multi-threading would be easier?
It's a major endeavor to cut things any way.
But what we get by cutting it this way is that half the work is already done:
We only need to add a few differentiations to the local vegaserver target, namely that
it can use a message queue for communications with the client, instead of UDP; but it has to
communicate as client with the remote server. I.e.: we need a modified vegaserver, which
we could call vegaserver_proxy.
Once that is done, and it works, the next step is to change the vegastrike code so that it
yields completely to the local server.
Once that is done and it works, we can remove unused code.

It's not simple, but it IS rather trivial.
And it simplifies the vegastrike target a great deal.
And it makes use of two cores in multi-core cpu's NOW, without going through all the
headaches of multi-threading.

EDIT:
My guess of what vegaserver does now is it
a) rules the universe map, navigation and stuff
b) computes flight physics and has the last word on it
c) computes collisions and has the last word on them
d) controls spawning of ai's and all that

This amounts to a hefty chunk of code to separate from vegastrike.
And, unlike many other things, it is EASY to separate, because most of the work
has already been done, and communications serialized.
This is an obvious choice, --if not THE obvious choice; a "no-brainer".

EDIT2:
There's no need to move campaigns to the server proxy.
Server proxy could simply yield control of maps and spawning to the client, in
single player mode. Those are not heavy computations, anyways. Just think of
single player server proxy as a physics and collision server.
EDIT3:
Autopilot and AI should go on the local server, too.
Last edited by chuck_starchaser on Mon Mar 08, 2010 7:24 pm, edited 1 time in total.
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: IDEA: Before multithreading: Multi-processing

Post by klauss »

Does vegaserver have AI?

I seem to recall reading that it didn't.

I never tried it.

Really, chuck, vegaserver is heavily impaired to run as single player backend. Before even considering that, heavy review of vegaserver would be required.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: IDEA: Before multithreading: Multi-processing

Post by chuck_starchaser »

klauss wrote:Does vegaserver have AI?

I seem to recall reading that it didn't.

I never tried it.
Hehehe; read my last edit.
Really, chuck, vegaserver is heavily impaired to run as single player backend. Before even considering that, heavy review of vegaserver would be required.
Of course a review is needed; otherwise I would have implemented it, rather than post here :D
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: IDEA: Before multithreading: Multi-processing

Post by klauss »

Hm... a physics backend.

But then it's not harder than making it multithreaded. Only you would use a local (shared memory) message queue instead of an interprocess message queue. But pretty much the same amount of work, and you'd at least stay within client code (which is better known by us).
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: IDEA: Before multithreading: Multi-processing

Post by chuck_starchaser »

klauss wrote:Hm... a physics backend.
Physics, collisions, autopilot and AI back-end, eventually; but physics and collision for starters.
But then it's not harder than making it multithreaded.
It's not harder making it multithreaded, you mean?
Only you would use a local (shared memory) message queue instead of an interprocess message queue. But pretty much the same amount of work, and you'd at least stay within client code (which is better known by us).
I would first try my approach. Tell you why: The code base is a mountain of spaghetti and it would be a HUGE amount
of work to ensure there's nothing accidentally shared by the two threads. (In fact, even if we wanted to split it as a
thread, we might be better off making it a process first, and later move it back in, I think.)
But more importantly, even if we know less about vegaserver than we do about vegastrike, we do know a thing or
two about it: a) It kind of works, and b) it has built-in state serialization, for communications with the client.
And the client has built-in serialization for communicating with the server.
In fact, all we have to do is grab the sockets and repackage those packets as inter-process messages. Done.
Morover, we know that daniel and patrick have been struggling for years to make multiplayer work, and only got
so far; and I can tell you why they had so much trouble, exactly, with complete certainty, and with my eyes closed:
The problem is that the client and server states don't track too well. Yes or Yes?
And the reason for that is that they are different: There's a server proxy built into the client, but it was not named
explicitly and separated properly. It's intertwined and mixed up with all the rest of the code.
(Even if the code was identical, the client's built-in server proxy is running in a different environment, having to share
time with graphics, sound and whatnot. There's occasional freeze-up's in the client, for example. What happens with
server synchronization when that happens? Probably nobody knows. But most people have dual core processors (except
me), and a local server proxy running on a separate core would be MUCH better suited to deal with the remote
server, than the client.)
THAT's been the problem all along. I bet you any money.
Making a slightly modified version of vegaserver called "vegaserver_proxy" and running locally as its own process would
make this proxy track very well with the remote server, and all their problems would vanish at once.

But in a nutshell, what it boils down to is that the work of separating physics and collision is already done; and all we
have to do is modify it a little bit and use it. Separating physics and collision as a thread would amount to duplicating
all that work, with the attendant problems and risks of shared memory. What for? The work is already done.
snow_Cat
Confed Special Operative
Confed Special Operative
Posts: 349
Joined: Thu Jan 05, 2006 12:43 am
Location: /stray/
Contact:

Re: IDEA: Before multithreading: Multi-processing

Post by snow_Cat »

^ - -^ Chuck. While what you are saying is making a lot of sense;
^- - ^ This is the internet, you don't need to hit the carage return to start a new line;
^- - ^ (most of) our browsers will do that for you.

^ - -^ Silliness aside; I like your thinking.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: IDEA: Before multithreading: Multi-processing

Post by chuck_starchaser »

Yeah, a bad habit I acquired for arguably good reasons... In phpBB2 (junction's forum), large images cause text to scroll to the right, and the edit, reply, etceteras buttons to disappear off the screen; so I put in carriage returns prophilactically, just in case somebody decides to stick an oversized picture in a thread.
Glad you like the idea. It came like a flash of lightning in the road to Damascus...
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: IDEA: Before multithreading: Multi-processing

Post by chuck_starchaser »

The steps I envision would be,
  • Make a vegaserver branch called vegaserver_local (to include single player and multiplayer proxy modes)
  • Hack vegastrike and vegaserver_local a tiny bit; just enough to establish inter-process UDP communications.
  • Test solo multiplayer mode; debug.
  • Hack vegastrike multiplayer mode to load campaigns in an off-shoot single player mode within multiplayer mode.
  • Hack vegaserver_local to accept vegastrike's system loading commands
  • Test and debug. Now vegastrike controls the general itinerary and missions; and vegaserver manages one system at a time.
  • Move network predictive code from vegastrike to vegaserver_local. Test and debug.
  • Remove single-player mode from vegastrike; --leaving the single-player mode within the multiplayer mode.
  • Implement vegaserver_local's other role, as vegaserver_proxy (multiplayer mode). Test and debug.
  • Remove networking code from vegastrike.
  • Change vegastrike <-> vegaserver_local communications from UDP to inter-process shared memory + messages.
  • Move AI code from vegastrike to vegaserver_local. Test and debug.
  • Move autopilot code from vegastrike to vegaserver_local. Test and debug.
  • Remove physics, collisions, AI, autopilot and networking code from vegastrike.
  • Optionally: Put all of vegastrike's remaining code in a "k" namespace.
  • Optionally: Put all of vegaserver's code (local and not) in an "s" namespace.
  • Optionally: Move vegaserver local back into vegastrike, as a separate thread.
Once this is all done, vegastrike would be in charge of:
  • User input
  • Missions and campaigns
  • Base activities, Python, etceteras
  • Universe, news, economics
  • flight-group spawning specifications
  • Graphics
And vegaserver_local would be in charge of:
  • Current system, spawning
  • Units in system, AI
  • Autopilot
  • Physics
  • Collisions
  • Networking (communicating with vegaserver_remote in multi-player mode.
I think it would be a pretty good division of labor; totally asynchronous; no mutexes or semaphores at all.
PERFECT for dual core processors.
And it might be doable in a week-end (if all goes well, of course...) :roll:

((For quad-core's, we could split graphics out of vegastrike, and AI out of vegaserver_local.))
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: IDEA: Before multithreading: Multi-processing

Post by chuck_starchaser »

I'm thinking now, even if this idea gains favor among developers; which right now doesn't seem to be the case; a more appropriate time to even think about it would be after a full refactoring of the Unit hierarchy, --as separating physics from ai from other things would have to happen first to make the work easier. (Right now the code is too entangled.)
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: IDEA: Before multithreading: Multi-processing

Post by klauss »

chuck_starchaser wrote:(Right now the code is too entangled.)
Exactly.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
Post Reply