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.
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.
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.
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.
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.
Follows 1a8de6d2b8.
Validate the password when a client joins a game, so even a player that
knows the connection data cannot join.
Refs #3556, Refs #5913
Differential Revision: https://code.wildfiregames.com/D3438
This was SVN commit r24775.
Current issue with the lobby, is that we make ips of hosts public for
anyone to read. This patch consists of 3 parts.
1.) Removing ips and ports from lobby javascript
2.) Removing need of script on the server to attach public ips to game
stanza by asking the host using xmppclient as proxy.
3.) Implementing password protected matches, to deny this information to
not trusted players.
Further description:
Do not send ports and stunip to the bots.
Removed from stanza.
Do not send ip to the lobby.
Removed from mapping gamelist from backend to gui (still on the backend
side, because it is done by script on 0ad server).
Get ip and ports on request when trying to connect.
On the host side, ask stun server what is host's public ip and remember
it.
On the client side, send iq through xmppclient to the hosting player and
ask for ip, port and if Stun is used, then if answer is success,
continue
with connecting, else fail.
Add optional password for matches.
Add password required identifier to the stanza.
Allow host to setup password for the match. Hash it on the host side and
store inside Netserver. If no password is given, matches will behave
as it is not required.
On the client side, if password for the match is required, show
additional window before trying to connect and ask for password, then
hash it
and send with iq request for ip, port and stun.
Server will answer with ip, port and stun only if passwords matches,
else will asnwer with error string.
Some security:
Passwords are hashed before sending, so it is not easy to guess what
users typed. (per wraitii)
Hashes are using different salt as lobby hashing and not using usernames
as salt (as that is not doable), so they are different even typing the
same password as for the lobby account.
Client remembers which user was asked for connection data and iq's id of
request. If answer doesn't match these things, it is ignored. (thnx
user1)
Every request for connection data is logged with hostname of the
requester to the mainlog file (no ips).
If user gets iq to send connection data and is not hosting the match,
will respond with error string "not_server".
If server gets iq::result with connection data, request is ignored.
Differential revision: D3184
Reviewed by: @wraitii
Comments by: @Stan, @bb, @Imarok, @vladislavbelov
Tested in lobby
This was SVN commit r24728.
This threads the netclient session, which avoids timeouts when the
main-thread is not polling (map creation, very long simulation frames).
Unlike the NetServer, which should be as independent as possible from
the main thread, the NetClient is fundamentally tied to the game thread.
Therefore, this only threads the session object.
To ensure good performance and ease-of-use, lock-free queues for
in/out-going messages are used.
This fixes artificial timeouts, while also improving actual ping reports
(since frame-time is no longer a factor).
It effectively reverts D1513/eda236522c and 2e7e1c0b2b, all hacks around
lag-timeouts (and bits of 1a3fb29ff3).
Based on a patch by: Stan
Comments by: Vladislavbelov
Fixes#3700, refs #3373
Differential Revision: https://code.wildfiregames.com/D2848
This was SVN commit r24518.
GUIObjectBase is made a IGUIObject* to avoid including those headers
un-necessarily. Subsequent diffs ought to clean up the various of
pointers for that with a similar type with reference semantics.
Also:
- Add standard C and C++ headers (mostly cstring for memcpy, string and
vector) where needed.
- Swap out some includes for forward declarations
- Clean up un-necessary boost includes in precompiled and other headers.
- Clean up precompiled headers, including fewer things.
- Move ACPI to the windows-specific folder as it's included there only
and mostly specific to that platform.
Thanks Stan for the testing.
Differential Revision: https://code.wildfiregames.com/D3129
This was SVN commit r24352.
- Check for pending exceptions after function calls and script
executions.
- Call LOGERROR instead of JS_ReportError when there is a conversion
error in FromJSVal, since that can only be called from C++ (where JS
errors don't really make sense). Instead, C++ callers of FromJSVal
should handle the failure and, themselves, either report an error or
simply do something else.
- Wrap JS_ReportError since that makes updating it later easier.
This isn't a systematical fix since ToJSVal also ought return a boolean
for failures, and we probably should trigger errors instead of warnings
on 'implicit' conversions, rather a preparation diff.
Part of the SM52 migration, stage: SM45 compatible (actually SM52
incompatible, too).
Based on a patch by: Itms
Comments by: Vladislavbelov, Stan`
Refs #742, #4893
Differential Revision: https://code.wildfiregames.com/D3093
This was SVN commit r24187.
JSAutoRequest is required before calling into most JSAPI methods, for GC
reasons.
Calling it is required and fragile as one must not forget.
Further, SM52 and later make manipulating JSContext* dangerous as that
can cross Compartment(Realm in SM68) barriers (and ScriptInterface now
matches a Compartment).
The solution to both problems is to avoid using JSContext* in 0 A.D.
itself. To achieve this, a Request class is introduced, and must be used
to access a JSContext* from a scriptInterface. Further, Request is
passed to other ScriptInterface functions isntead of JSContext*, making
it obvious that the caller has already called it, reducing errors and
redundant JSAutoRequest calls.
Only JSNative functions now get a naked JSContext* without protection,
but the likelihood of forgetting a request is lower since many
ScriptInterface functions now expect it.
JSContext* is directly passed to JSAPI functions only.
Part of the SM52 migration, stage: SM45 compatible
Based on a patch by: Itms
Tested By: Freagarach
Refs #4893
Differential Revision: https://code.wildfiregames.com/D3088
This was SVN commit r24176.
DefPersistentRooted is essentially a wrapper around unique_ptr and has
no real reason to exist.
Part of SM52 migration, stage: SM45 compatible.
Patch by: Itms
Tested by: Freagarach
Refs #4893
Differential Revision: https://code.wildfiregames.com/D3086
This was SVN commit r24170.
Make that function static, so that it can be used for these functions
without slowly having to obtain the ScriptInterface instance using
GetScriptInterfaceAndCBData just to get the JSContext again.
Remove few redundant conversions for CreateObject arguments.
Differential Revision: https://code.wildfiregames.com/D2128
Tested on: gcc 9.1.0, clang 8.0.1, Jenkins
Tedious performance testing in: D2128, D2127
This was SVN commit r22894.
Fixes an occurring leak indicated by the reported clang unused variable
compiler warning, refs #5294, #5550,
by adding the missing glooxwrapper::Jingle::Session::Session destructor
.
Fix two leaks that would have occurred if the according code had been
used:
Delete unused glooxwrapper::Jingle::ICEUDP::ICEUDP instead of adding the
missing destructor.
Delete unused glooxwrapper::Jingle::Content::Content instead of adding
the missing destructor.
Explain why glooxwrapper::Client::registerStanzaExtension doesn't leak
the new StanzaExtensionWrapper.
Explain why glooxwrapper::Jingle::Session::sessionInitiate doesn't leak
the new gloox::Jingle::Content, nor the new gloox::Jingle::ICEUDP.
Explain why glooxwrapper::SessionManager::registerPlugins doesn't leak
the new gloox::Jingle::Content and new gloox::Jingle::ICEUDP.
Explain why glooxwrapper::SessionManager::createSession doesn't leak the
gloox::Jingle::Session.
I will not leak memory in the glooxwrapper.
I will not leak memory in the glooxwrapper.
I will not leak memory in the glooxwrapper.
Use references in the StunClient and glooxwrapper to anticipate any
confusion as to whose obligation it is to delete variables when they are
passed around across several files.
Use static_cast and reinterpret_cast instead of C-style casts in the
StunClient.
Differential Revision: https://code.wildfiregames.com/D2094
Refs D2093 for the reported leaks.
Reviewed By: Josh
Comments By: fcxSanya, Vladislav for D2094, and echotangoecho, leper in
61261d14fc
This was SVN commit r22678.
Allows lobby players to host games without having to configure their
router.
Differential Revision: https://code.wildfiregames.com/D364Fixes#2305
Patch By: fcxSanya.
StunClient based on code by SuperTuxKart, relicensed with approval of
the according authors hilnius, hiker, Auria, deveee, Flakebi, leper,
konstin and KroArtem.
Added rfc5245 (ejabberd) support, a GUI option, refactoring and segfault
fixes by myself.
Tested By: user1, Sandarac, Sestroretsk1714, Vladislav, Grugnas,
javiergodas
Partially Reviewed By: leper, Philip, echotangoecho
This was SVN commit r19703.
Access the server from the client only, not from the GUI (except for
autostarted games).
Thereby lay the foundation for clients to setup the game (refs #3806)
and dedicated hosting (refs #3556).
Doesn't transfer nor remove the SetTurnLength showcase from 0ebe3486b6.
This was SVN commit r18322.
Send the "client has rejoined" message after the synchronization
finished instead of right after the loading screen.
Patch by echotangoecho, refs #1949, #1950.
This was SVN commit r18203.
