View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003688 | GNUnet | core service | public | 2015-02-22 17:43 | 2018-06-06 22:25 |
| Reporter | amatus | Assigned To | Christian Grothoff | Due Date | |
| Priority | immediate | Severity | minor | Reproducibility | sometimes |
| Status | closed | Resolution | fixed | ||
| Product Version | Git master | ||||
| Target Version | 0.11.0pre66 | Fixed in Version | 0.11.0pre66 | ||
| Summary | 0003688: If peer A restarts KX with peer B but peer B isn't expecting it, it can take up to 5 minutes to re-establish the connection | ||||
| Description | I'm seeing a problem when peer A loses its connection with peer B but peer B doesn't recognize the connection as lost (happens over HTTP and probably any of the non-connection-oriented transports), when peer A reconnects it starts KX over again and peer B ignores the GNUNET_MESSAGE_TYPE_CORE_EPHEMERAL_KEY messages as "# old ephemeral keys ignored". It takes up to 5 minutes for peer B to timeout and restart KX. | ||||
| Tags | No tags attached. | ||||
| I fixed the problem why A lost its connection with B in rev 35298. It might also be a good idea to have B notice the lost connection with A at the transport level when A tries to reconnect, which would reset core's KX state, right? | |
| I'm not sure I like the "fix" in SVN 35298. Simply using the same timeout regardless of connection status seems a bit wrong -- we had two different #defines for a reason: we don't want to keep an accidental HTTP session just open for 5 minutes. I can see increasing HTTP_SERVER_NOT_VALIDATED_TIMEOUT, but just removing the distinction is not nice. | |
| HTTP_SERVER_NOT_VALIDATED_TIMEOUT is still used for the default MHD timeout. We only set the longer timeout after we have a request and it has made it past all the checks in server_lookup_connection. The check that was invalid was that we require both a GET and a PUT connection, which is not something XHR clients can maintain. | |
| Ah, I see. Didn't know that. Than that's obviously fine. | |
| KX issue should be fixed in SVN 35304. Timestamp compare changed from <= to <, means that we only ignore the repeated KX if it is strictly older. | |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2015-02-22 17:43 | amatus | New Issue | |
| 2015-02-22 22:15 | Christian Grothoff | Assigned To | => Christian Grothoff |
| 2015-02-22 22:15 | Christian Grothoff | Status | new => assigned |
| 2015-02-22 22:15 | Christian Grothoff | Priority | normal => immediate |
| 2015-02-22 22:15 | Christian Grothoff | Target Version | => 0.11.0pre66 |
| 2015-02-23 00:41 | amatus | Note Added: 0008919 | |
| 2015-02-23 06:56 | Christian Grothoff | Note Added: 0008920 | |
| 2015-02-23 13:27 | amatus | Note Added: 0008922 | |
| 2015-02-23 22:45 | Christian Grothoff | Note Added: 0008924 | |
| 2015-02-28 13:39 | Christian Grothoff | Note Added: 0008931 | |
| 2015-02-28 13:39 | Christian Grothoff | Status | assigned => resolved |
| 2015-02-28 13:39 | Christian Grothoff | Fixed in Version | => 0.11.0pre66 |
| 2015-02-28 13:39 | Christian Grothoff | Resolution | open => fixed |
| 2018-06-06 22:25 | Christian Grothoff | Status | resolved => closed |