It has to be called before `SetupConnection` is called. Now the
server-data is setup during the constructor.
When connecting using the lobby, the data isn't known at construction
time. Then it is done at the start of `TryToConnectWithSTUN`.
CNetClient and CNetServer are constructed for a single match. The
password of a game can not be changed after creating the match. When the
password is passed to the constructor it's not possible to invoke the
functions in the wrong order and the `ENSURE` can be "checked at
compile-time" so to say.
This reduces the stutter when a client joins.
The decompression isn't put on the task manager. As the client would
have to wait for that either way. Also a new polling loop would have to
be introduced.
The compression code is moved to the file transferer so all data send
through it gits compressed.
Refs: #4210
Make include-what-you-use happy with some files in source and fix what
needs to be fixed.
Ref: #8086
Signed-off-by: Ralph Sennhauser <ralph.sennhauser@gmail.com>
Make include-what-you-use happy with files in source/network and
fix what needs to be fixed.
Ref: #8086
Signed-off-by: Ralph Sennhauser <ralph.sennhauser@gmail.com>
Previously the param type was `void*` now the type has to be specified
as template parameter of the `CFsm`.
With this commit some casts can be removed.
This makes using STUN mandatory for games hosted using the multiplayer
lobby. The motivation for that is a reduction in complexity, because
right now if STUN is disabled we use a home-grown STUN-like logic, which
got implemented before Pyrogenesis got STUN support.
That home-grown logic relies on a custom ejabberd module (mod_ipstamp),
which inserts the external IP-address of a host in the response messages
when a host registers a game. Originally mod_ipstamp was also used to
inform all potential players of a hosts IP-address, however that has
already been removed to let hosts to only share their IP-address with
players actually joining their game.
Removing the home-grown logic and instead always relying on STUN removes
complexity in Pyrogenesis and the lobby server and also eases hosting
games for players, as they don't have to figure out anymore whether they
need to enable STUN or not.
These changes shouldn't negatively impact the ability of Pyrogenesis to
handle different types of NAT or broken networks. There is one
difference though: While the custom logic using mod_ipstamp utilized TCP
as transport protocol, the STUN implementation in Pyrogenesis currently
uses UDP. That doesn't allow hosts with UDP-connectivity issues to
resolve their external IP-address anymore, however without
UDP-connectivity they aren't able to successfully host games anyway, as
the actual game updates are transferred using UDP as well.
Only the sender and the recipients receive the chat messages.
This commit only has an affecto on messages where the addressee(s) are
selected through the dropdown. Addressee(s) selected with a "/" command
are still sent to evevyone and filteret by the receiver.
This patch addresses issues concerning a1796ed71f:
Allow for a more elegant implementation of observer flares.
And still display flares even if the sender is lagging behind:
Split off flares from simulation commands.
Remove the new, problematic 'observer commands' entirely.
Provide an engine function 'SendNetworkFlare' to the JS interface.
-> which sets off the (pretty ordinary) transmission process.
Add a new type of net messages exclusively for flares
-> contains the flare's position and its sender's GUID.
The user doesn't have to fiddle with `std::shared_ptr`.
And two (more unrelated) things: use `std::unordered_map`, use a
`std::find_if` in the callback.
Comments By: @vladislavbelov, @Stan
Differential Revision: https://code.wildfiregames.com/D5239
This was SVN commit r28048.
Avoid cases of filenames
Update years in terms and other legal(ish) documents
Don't update years in license headers, since change is not meaningful
Will add linter rule in seperate commit
Happy recompiling everyone!
Original Patch By: Nescio
Comment By: Gallaecio
Differential Revision: D2620
This was SVN commit r27786.
This fixes packet loss issues on some VPN solutions.
Patch By: sera
Differential Revision: https://code.wildfiregames.com/D4967
This was SVN commit r27599.
The purpose of our client-side hashing for lobby game passwords is to
prevent malicious hosts from getting valuable passwords from clients
(e.g. accidentally typing their lobby password instead of the game, or
even their email password, etc).
However, the hashing was deterministic (and rather simple), making it
possible to compute rainbow tables and recover user passwords anyways.
By adding more variation, including some that cannot so easily be
controlled by the host (the client name), this becomes impractical. The
password hashing function used is rather fast, but given the base low
probability of mistypes, this seems fine.
Differential Revision: https://code.wildfiregames.com/D3459
This was SVN commit r25459.
Instead of using platform-specific sockets, use enet_socket* functions
(which ends up doing the same).
Clean up some confusing APIs, removing the distinction between finding
the public IP for the host/join.
Fix endianness support & use simpler code.
Refs D364 / 61261d14fc (and some subsequent fixing diffs).
Differential Revision: https://code.wildfiregames.com/D3970
This was SVN commit r25453.
This allows joining a lobby game hosted on the same network (behind the
same NAT gateway).
This is relatively primitive to keep things simple: if the server and
the client have the same public IP, it is assumed that they are on the
same network and the client instead requests the local IP.
Differential Revision: https://code.wildfiregames.com/D3944
This was SVN commit r25448.
Follows 34b1920e7b.
JSON functions and ToString are movec to their own headers.
Also clean out a few PersistentRooted usage to use the 2-phase init to
clean up scriptInterface usage.
With these functions split off, we can finally clean out headers and
remove ScriptInterface.h from most of them, in favour of smaller and
more precise headers.
Take the opportunity to clarify some comments regarding Mutability.
Differential Revision: https://code.wildfiregames.com/D3961
This was SVN commit r25434.
Follows 34b1920e7b.
This splits off the object-related functions, such as
[Set/Get/Has]Property, CreateObject, CreateArray, FreezeObject.
It also puts the definitions in the header itself, which might end up
with faster code here & there, though perhaps slower compilation time
(somewhat doubtful since we already included most things anyways).
Differential Revision: https://code.wildfiregames.com/D3956
This was SVN commit r25430.
XMPP JID has a concept of 'resources', which can be used to
differentiate multiple clients of the same account.
We currently hardcode this 'resource' to '0ad' in two places:
- The 0 A.D. client always uses '0ad'
- The network code expects a host resource to be '0ad' when connecting.
As noted in 0fd8aa2a77#31215, it is less effort to store the JI
D directly. This patch does that. It also makes 0 A.D. use a different
resource each time.
Note that resources ought not contain particular information, as the
XMPP server is free to
clobber it. I keep '0ad-' here for debug purposes.
This allows:
- multiple 0 A.D. instances to log on the lobby at the same time (not
massively useful, but good for debugging sometimes)
- hosting a game with a custom resource, which will potentially make it
easier to have dedi
cated servers on one account.
Note that hosting multiple games on one account is currently not
supported and will have weird behaviour on the lobbybots side. They
should be upgraded independently of this.
Refs #3556
Differential Revision: https://code.wildfiregames.com/D3500
This was SVN commit r25407.
The NetServer stored a complete copy of the game Init Attributes, which
it sent to new clients on updates from the controller. This worked well,
but prevents incremental updates and other unrelated messages from being
sent.
This changes the system so that:
- in PREGAME state, the server does not update its copy of the game init
attributes
- the server forwards game setup messages from the controller to all
clients
- Joining clients get a full copy of the Settings, when joining, from
the controller (this is a js-driven behaviour - other situations might
not need do it).
- Make the StartNetworkGame message take a copy of the final init
attributes, to ensure synchronization (and simplify some logic).
In practice, this:
- makes it possible to send different types of gamesetup messages (this
introduces two: a regular update and the full 'initial-update' for new
clients).
- moves some C++ hardcoding into JS - here in essence the PREGAME server
state is now init-attributes-agnostic.
- does not change much for readiness control - the server already needed
to force a change at game start to set random elements.
Note that the loading page is currently still receiving the 'local' game
attributes, which assumes that all clients are correctly synchronized
(they should be).
Refs #3806, #3049
Differential Revision: https://code.wildfiregames.com/D3714
This was SVN commit r25099.
To hide network latency, MP turns send commands not for the next turn
but N turns after that (introduced in c684c211a2).
Further, MP turn length was increased to 500ms compared to 200ms SP
turns (introduced in 6a15b78c98).
Unfortunately, increasing MP turn length has negative consequences:
- makes pathfinding/unit motion much worse & unit behaviour worse in
general.
- makes the game more 'lag-spikey', since computations are done less
often, but thus then can take more time.
This diff essentially reverts 6a15b78c98, instead increasing
COMMAND_DELAY from 2 to 4 in MP. This:
- Reduces the 'inherent command lag' in MP from 1000ms to 800ms
- Increases the lag range at which MP will run smoothtly from 500ms to
600ms
- makes SP and MP turns behave identically again, removing the
hindrances described above.
As a side effect, single-player was not actually using COMMAND_DELAY,
this is now done (can be used to simulate MP command lag).
Refs #3752
Differential Revision: https://code.wildfiregames.com/D3275
This was SVN commit r25001.
The 'controller' of an MP game (the host in general, though dedicated
servers would change that) is currently whoever first tells the server
that it is. This can be abused since it relies on trusting the clients.
This changes that logic: the server defines a 'controller secret', and
the first client to sent the correct controller secret is the
controller. This is safe assuming the secret is unknowable enough (the
current solution wouldn't pass strict cryptography tests, but it's
likely good enough).
Reverts 1a3fb29ff3, which introduced the 'trust the clients' mechanic,
as a change over 'the first local IP is controller'.
Necessary step towards dedicated server, if we want to use the regular
gamesetup (Refs #3556)
Differential Revision: https://code.wildfiregames.com/D3075
This was SVN commit r24952.
phosit