Commit Graph

13 Commits

Author SHA1 Message Date
est31
423d8c1b0d Tolerate packet reordering in the early init process
Fixes a bug where packet reordering made the server give the
client two peer ids instead of one. This in turn confused
reliable packet sending and made connecting to the server fail.

The client usually sends three packets at init: one "dummy"
packet consisting of two 0 bytes, and the init packet as well as
its legacy counterpart. The last one can be turned off since commit
af30183124d40a969040d7de4b3a487feec466e4, but this is of lower
relevance for the bug. The relevant part here is that network
packet reorder (which is a normal occurence) can make the packets
reach the server in different order.

If reorder puts the dummy packet further behind, the following
would happen before the patch:

1. The server will get one of the init packets on channel 1 and
   assign the client a peer id, as the packet will have zero as
   peer id.

2. The server sends a CONTROLTYPE_SET_PEER_ID packet to inform
   the client of the peer id.

3. The next packet from the client will contain the peer id set by
   the server.

4. The server sets the m_has_sent_with_id member for the client's
   peer structure to true.

5. Now the dummy packet arrives. It has a peer id of zero, therefore
   the server searches whether it already has a peer id for the
   address the packet was sent from. The search fails because
   m_has_sent_with_id was set to true and the server only searched
   for peers with m_has_sent_with_id set to false.

6. In a working setup, the server would assign the dummy packet to
   the correct peer id. However the server instead now assigns a
   second peer id and peer structure to the peer, and assign the
   packet to that new peer.

7. In order to inform the peer of its peer id, the server sends a
   CONTROLTYPE_SET_PEER_ID command packet, reliably, to the peer.
   This packet uses the new peer id.

8. The client sends an ack to that packet, not with the new peer id
   but with the peer id sent in 2.

9. This packet reaches the server, but it drops the ACK as the peer
   id does not map to any un-ACK-ed packets with that seqnum. The
   same time, the server still waits for an ACK with the new peer
   id, which of course won't come. This causes the server to
   periodically re-try sending that packet, and the client ACKing it
   each time.

Steps 7-9 cause annoyances and erroneous output, but don't cause
the connection failure itself.
The actual mistake that causes the connection failure happens in 6:
The server does not assign the dummy packet to the correct peer, but
to a newly created one.
Therefore, all further packets sent by the client on channel 0 are
now buffered by the server as it waits for the dummy packet to reach
the peer, which of course doesn't happen as the server assigned
that packet to the second peer it created for the client.
This makes the connection code indefinitely buffer the
TOSERVER_CLIENT_READY packet, not passing it to higher level code,
which stalls the continuation of the further init process
indefinitely and causes the actual bug.

Maybe this can be caused by reordered init packets as well, the only
studied case was where network has reliably reordered the dummy
packet to get sent after the init packets.

The patch fixes the bug by not ignoring peers where
m_has_sent_with_id has been set anymore. The other changes of the
patch are just cleanups of unused methods and fields and additional
explanatory comments.

One could think of alternate ways to fix the bug:

* The client could simply take the new peer id and continue
  communicating with that. This is however worse than the fix as
  it requires the peer id set command to be sent reliably (which
  currently happens, but it cant be changed anymore). Also, such a
  change would require both server and client to be patched in order
  for the bug to be fixed, as right now the client ignores peer id
  set commands after the peer id is different from
  PEER_ID_INEXISTENT and the server requires modification too to
  change the peer id internally.
  And, most importantly, right now we guarantee higher level server
  code that the peer id for a certain peer does not change. This
  guarantee would have to be broken, and it would require much
  larger changes to the server than this patch means.

* One could stop sending the dummy packet. One may be unsure whether
  this is a good idea, as the meaning of the dummy packet is not
  known (it might be there for something important), and as it is
  possible that the init packets may cause this problem as well
  (although it may be possible too that they can't cause this).

Thanks to @auouymous who had originally reported this bug and who
has helped patiently in finding its cause.
2016-05-22 15:56:54 +02:00
ShadowNinja
e4bff8be94 Clean up threading
* Rename everything.
    * Strip J prefix.
    * Change UpperCamelCase functions to lowerCamelCase.
  * Remove global (!) semaphore count mutex on OSX.
  * Remove semaphore count getter (unused, unsafe, depended on internal
    API functions on Windows, and used a hack on OSX).
  * Add `Atomic<type>`.
  * Make `Thread` handle thread names.
  * Add support for C++11 multi-threading.
  * Combine pthread and win32 sources.
  * Remove `ThreadStarted` (unused, unneeded).
  * Move some includes from the headers to the sources.
  * Move all of `Event` into its header (allows inlining with no new includes).
  * Make `Event` use `Semaphore` (except on Windows).
  * Move some porting functions into `Thread`.
  * Integrate logging with `Thread`.
  * Add threading test.
2015-08-23 22:04:06 -04:00
nerzhul
c4b5561b3f Remove unused function from connection.{cpp,h} 2015-08-15 08:48:20 +02:00
kwolekr
8560ece02e Fix BufferedPacket race condition (fixes #2983)
This was caused by the use the non-threadsafe SharedBuffer in a
threaded context.
2015-08-06 02:25:35 -04:00
Břetislav Štec
79e2647556 src/network/connection.h: Fix race condition 2015-08-01 20:44:17 +02:00
Loic Blot
8ac0cf500f connection.cpp: remove unused constructor 2015-07-14 18:33:20 +02:00
Loic Blot
4235f671c1 Fix uninitialized variabled in ConnectionEvent 2015-04-05 11:13:30 +02:00
Loic Blot
1fe4256462 Connection::Receive(): receive Network Packet instead of SharedBuffer<u8>.
Because we get a Buffer<u8> from ConnectionEvent, don't convert it to SharedBuffer<u8> and return it to Server/Client::Receive which will convert it to NetworkPacket
Instead, put the Buffer<u8> directly to NetworkPacket and return it to packet processing
This remove a long existing memory copy
Also check the packet size directly into Connection::Receive instead of packet processing
2015-03-31 11:01:08 +02:00
Loic Blot
dfe00abc5a queued_commands must be a std::deque. RunCommandQueues needs to push packet on front, not back 2015-03-29 10:49:43 +02:00
Loic Blot
61f2d0ca34 Remove unused ConnectionCommand::sendToAll function. NetworkPacket::oldForgePacket returns Buffer instead of SharedBuffer and is used in ConnectionCommand instead of Connection::Send
This remove the NetworkPacket buffer => SharedBuffer => Buffer copy. Now NetworkPacket => Buffer
2015-03-22 12:18:16 +01:00
Craig Robbins
ced6d20295 For usages of assert() that are meant to persist in Release builds (when NDEBUG is defined), replace those usages with persistent alternatives 2015-03-07 22:41:47 +10:00
Loic Blot
b214cde5b4 Remove Queue class which uses std::list and use native std::queue 2015-03-05 16:49:51 +10:00
Loic Blot
ed04e8e9e4 [Patch 2/4] Network rework: packet writing, sending and cleanups
NetworkPacket.cpp:
* Remove some deprecated functions, we must use streaming interface
* m_data converted from u8* to std::vector<u8>
* Add an exporter to forge packet to Connection object
* implement operator << std::wstring. n
* implement operator << std::string
* dynamic resize when write packet content.
* fix string writing and performances.
* create ServerCommandFactory, used by client to get useful informations about packet processing (sending).
  * Reliability
  * Transmit channel
* Implement putRawString for some ugly char (_INIT packet), and use it.
* Many packet read and write migrated
* Implement oldForgePacket to interface writing with current connection
* fix U8/char/bool writing
* fix string writing and performances.
* add some missing functions
* Use v3s16 read instead of reading x,y,z separately
* Add irr::video::SColor support into packets
* Add some missing handlers
* Add a template function to increase offset
* Throw a serialization error on packet reading (must be improved)

PacketFactories:
* Create ServerCommandFactory, used by client to get useful informations about packet processing (sending).
* Create ClientCommandFactory, used by server to get useful informations about packet processing (sending).

Client.cpp:
* implement NetworkPacket ::Send interface.
* Move packet handlers to a dedicated file
* Remove Client::Send(SharedBuffer)

Server.cpp:
* implement NetworkPacket ::Send interface.
* Rewrite all packets using NetworkPacket
* Move packet handlers to a dedicated file
* Remove Server::Send(SharedBuffer)

ClientIface.cpp:
* Remove sendToAll(SharedBuffer<u8>)

Connection.hpp rework:
* Remove duplicate include
* Remove duplicate negation
* Remove a useless variable
* Improve code performance by using a m_peers_list instead of scanning m_peers map
* Remove Connection::Send(SharedBuffer)
* Fix useafterfree into NetworkPacket Sending
* Remove unused Connection::sendToAll

Test.cpp:
* Remove dead code
* Update tests to use NetworkPackets

Misc:
* add new wrappers to Send packets in client, using NetworkPacket
* Add NetworkPacket methods for Connection
* coding style fix
* dead code since changes cleanup
* Use v3s16 read instead of reading x,y,z separately in some packets
* Use different files to handle packets received by client and server
* Cleanup: Remove useless includes

ok @Zeno-
Tested by @Zeno- @VanessaE and @nerzhul on running servers
2015-02-16 11:00:55 +01:00