View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001596 | GNUnet | core service | public | 2010-08-05 14:54 | 2010-10-21 15:47 |
| Reporter | mrwiggles | Assigned To | |||
| Priority | high | Severity | major | Reproducibility | always |
| Status | closed | Resolution | open | ||
| Summary | 0001596: Core connections don't stay around as they should (or as I think they should). | ||||
| Description | When running for a "long" time (e.g. ten minutes) connections that exist between peers seem to be lost. Not sure if core disconnect handlers are called, but CORE still accepts messages for the peers that are no longer connected. I created a test case in src/testing/ called 'test_testing_topology_stability' which starts a variable number of peers (10), connects them in a clique, then waits a variable amount of time (10 minutes) before attempting to pass messages between every reported connection. On my system at least, this test case always fails if the delay between connecting and sending messages is long enough. In addition, there are messages printed out of how many peers the respective CORE's are currently aware of. This number usually drops after the delay. | ||||
| Additional Information | My issue here is twofold: First, why are peers getting disconnected? Shouldn't CORE be playing PING/PONG to keep them alive? Five or ten minutes without message sending doesn't seem so long to me, especially if you only know 9 peers or so. Second, even if we assume it's "correct" that peers get disconnected due to lack of messages being sent, shouldn't the core transmit_notify call cause CORE to try to reconnect to the peer that was disconnected? And if so, this certainly should happen locally, and the timeout for message sending is long enough that the connection could be established. As a side note, I first noticed the topologies getting weird after long delays using the DHT, and in that case there are messages being sent on the application level between most of the connections every 30 seconds. In the worst case, a 10 minute test went from 9 connections per peer in a 10 peer test case down to 2.6 connections per peer. But I'm not totally ruling out that the DHT service isn't responsible for that, which is why I made the independent testing test case. *** On certain test machines, this scenario (specifically trying to send a message to a peer that was disconnected) causes external protocol violations in core. | ||||
| Tags | No tags attached. | ||||
|
|
WARNING External protocol violation detected at gnunet-service-core.c:3522 --- WARNING External protocol violation detected at gnunet-service-core.c:2946 |
|
|
Tracing these disconnects indicate they come from the disconnect_notify method in plugin_transport_tcp.c, which is set up from a call to GNUNET_SERVER_disconnect_notify in TCP. Not sure why these are happening, unless server.c has some other timeout or something. |
|
|
Cause of this was improper use or unclear description of disconnect_neighbour in gnunet-service-transport so that when a single address was disconnected for a peer the peer was forced to CORE disconnect. The reason that the tcp level disconnect happens is because of a timeout, but it's okay; transport typically picks a single address and sticks to it making the others go away. Of course, for transport selection we want to keep around all those address (and probe them too). So increasing the transport level ping/pong/revalidation of addresses may be necessary to make lower level disconnects not happen. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2010-08-05 14:54 | mrwiggles | New Issue | |
| 2010-08-05 14:57 | mrwiggles | Note Added: 0004106 | |
| 2010-08-05 16:57 | mrwiggles | Note Edited: 0004106 | |
| 2010-08-06 13:01 | mrwiggles | Note Added: 0004107 | |
| 2010-08-06 15:12 | mrwiggles | Note Added: 0004108 | |
| 2010-08-06 15:12 | mrwiggles | Status | new => resolved |
| 2010-10-21 15:47 | Christian Grothoff | Status | resolved => closed |
