[Serana]

Hello,

I've had to many multiplayer games ruined because the server crashed because of a render or sound process crash.
So, for me, the server must be separated from the client.


I would like to design this modification with you.

Let's start with the requirements :
- The server, the dispatcher GUI and RunActivity must be in different processes (not threads).
- The server application should only show a log of all of the actions occurring on the server (connections, errors, etc.)
- In the RunActivity application, it should be possible to join a multiplayer server after the game is loaded.
- In order to have a good fluidity in the movements of trains, the position reports and the state of the train (that can affect graphics and sound) should be sent from the clients to the server every 50 ms (default value used in the IVAO multiplayer client for Flight Simulator).
- Signalling updates should be calculated and sent every 500 ms (usual cycle time for track side signalling systems).
- The dispatcher GUI must be more accurate than the current one (maybe we should use the TrackViewer view for this)

Don't hesitate to comment these requirements or propose new requirements.

Once these requirements are approved, I will start to design the architecture and the functions.

[James Ross]

In case you're not already aware, I'm pulling the simulator and viewer apart as soon as I can, which may make this work easier. It might also be worth asking JTang, who I believe has a standalone server already, whether that could serve as a basis or inspiration or not.

As for these proposals, they sound pretty good. Ideally, the dispatcher would actually just be another client to the server (running a 2D viewer instead of a 3D viewer). I'm not sure being able to join multiplayer after the game is loaded should be included here, though with the right code restructuring it may be easy to implement.

[Csantucci]

I always hesitate when I see that there are ideas to change features that - more or less - work and are used with satisfaction.
If there are crashes (yes, there are) the other approach is to remove bugs instead of rewriting everything.
Some preliminary comments:
- what is done should still be compatible with Jtang's Tsimserver, that is commonly used - at least in my country - to host the multiplayer sessions; I also think looking for Jtang's advice is important
- it should be still possible to act as dispatcher and at the same moment to be a player and to have a look - on the main OR window - at a specific point of the route or to follow a train (but I believe to understand this is possible in your idea); this should be possible without higher overheads than today's ones; also, the dispatcher window is commonly used also in single player
- I don't get the advantage in joining the MP session after OR is already running (that is when the main window already shows the world)
- reducing update time is quite desirable, especially when the trains of two or more players meet or even more run on parallel tracks; however for sure there are bandwidth limits here; in the first period when MP came out, update time was configurable via an OR option. I still think having this configurable is the best solution. This of course could be done also with today's architecture.

And anyhow: please no single feature less with this new architecture, if it is decided to proceed.

[Serana]

Csantucci, on 14 October 2015 - 11:11 AM, said:

I always hesitate when I see that there are ideas to change features that - more or less - work and are used with satisfaction.

Due to these crashes, it is not satisfactory at all in the community I come from.

Csantucci, on 14 October 2015 - 11:11 AM, said:

If there are crashes (yes, there are) the other approach is to remove bugs instead of rewriting everything.

There will always be crashes. Separating the server minimize the impact of a crash... that has nothing to do with the server.

Csantucci, on 14 October 2015 - 11:11 AM, said:

- what is done should still be compatible with Jtang's Tsimserver, that is commonly used - at least in my country - to host the multiplayer sessions; I also think looking for Jtang's advice is important

I think the Tsimserver (and the OR server) is just broadcasting messages coming from each client. The new server will probably store the main states of the trains.

Csantucci, on 14 October 2015 - 11:11 AM, said:

- it should be still possible to act as dispatcher and at the same moment to be a player and to have a look - on the main OR window - at a specific point of the route or to follow a train (but I believe to understand this is possible in your idea); this should be possible without higher overheads than today's ones; also, the dispatcher window is commonly used also in single player

I think we can probably have 3 modes : 3D only, dispatcher only, 3D + dispatcher

Csantucci, on 14 October 2015 - 11:11 AM, said:

- I don't get the advantage in joining the MP session after OR is already running (that is when the main window already shows the world)

It's simple : if the server crashes, you can reconnect without restarting the simulation.

Csantucci, on 14 October 2015 - 11:11 AM, said:

- reducing update time is quite desirable, especially when the trains of two or more players meet or even more run on parallel tracks; however for sure there are bandwidth limits here; in the first period when MP came out, update time was configurable via an OR option. I still think having this configurable is the best solution. This of course could be done also with today's architecture.

The numbers I wrote were wrong.
On IVAO, the server/client communication is, by default, at a frequency of 0,2 Hz (5 s). For formation flights, the clients connect themselves to each other (P2P) and send messages at a higher frequency (by default, 10 Hz (100 ms)). That's a lot more acceptable.

[JTang]

It is currently impossible as James has said, until we have the viewer and simulator completely separated.

Crashes are easy to prevent by inserting a try-catch block somewhere in the update process. I have provided a version with this feature to the Chinese community and works fine.

Even with crashes, using public servers will not be a big concern as the server will declare a new dispatcher. You just need to get reconnected and ask the declared dispatcher to assign you as an aider and gain full control back.

I could not see the need to have very high frequency of update, as trains move slowly.

[disc]

JTang, on 15 October 2015 - 03:52 AM, said:

Crashes are easy to prevent by inserting a try-catch block somewhere in the update process. I have provided a version with this feature to the Chinese community and works fine.

The problem is, that try catch has some performance toll.

Lower update frequency looks nice, however it seems that the game needs an update locked to fps for those things that need frequent updates, and a slower update for others.

[Serana]

JTang, on 15 October 2015 - 03:52 AM, said:

Crashes are easy to prevent by inserting a try-catch block somewhere in the update process. I have provided a version with this feature to the Chinese community and works fine.

Those crashes are provoked by a hang of the Render or Sound process. And a try/catch block can't do anything with this.
It has been repeatable on all of the players' computers.

[James Ross]

Serana, on 15 October 2015 - 05:06 AM, said:

Those crashes are provoked by a hang of the Render or Sound process. And a try/catch block can't do anything with this.
It has been repeatable on all of the players' computers.

If you have repeatable crashes or hangs, have they been reported anywhere? I agree with the separation (and with not adding try/catch) but just want to check we're also fixing the underlying issues that have been found.

[Serana]

Never found where these hangs came from. Each time there was a hang, the program wasn't executed in debug mode and the log didn't have any relevant information.

That's why it was never reported.

[James Ross]

Serana, on 15 October 2015 - 05:28 AM, said:

Never found where these hangs came from. Each time there was a hang, the program wasn't executed in debug mode and the log didn't have any relevant information.

That's why it was never reported.

If it's hanging, after 10 seconds or so it'll "crash" itself and the log should contain stack traces that are generally useful. Does it not do any of this?