View Issue Details

IDProjectCategoryView StatusLast Update
0003688GNUnetcore servicepublic2018-06-07 00:25
Reporteramatus Assigned ToChristian Grothoff  
PriorityimmediateSeverityminorReproducibilitysometimes
Status closedResolutionfixed 
Product VersionGit master 
Target Version0.11.0pre66Fixed in Version0.11.0pre66 
Summary0003688: 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
DescriptionI'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.
TagsNo tags attached.

Activities

amatus

2015-02-23 01:41

developer   ~0008919

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?

Christian Grothoff

2015-02-23 07:56

manager   ~0008920

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.

amatus

2015-02-23 14:27

developer   ~0008922

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.

Christian Grothoff

2015-02-23 23:45

manager   ~0008924

Ah, I see. Didn't know that. Than that's obviously fine.

Christian Grothoff

2015-02-28 14:39

manager   ~0008931

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.

Issue History

Date Modified Username Field Change
2015-02-22 18:43 amatus New Issue
2015-02-22 23:15 Christian Grothoff Assigned To => Christian Grothoff
2015-02-22 23:15 Christian Grothoff Status new => assigned
2015-02-22 23:15 Christian Grothoff Priority normal => immediate
2015-02-22 23:15 Christian Grothoff Target Version => 0.11.0pre66
2015-02-23 01:41 amatus Note Added: 0008919
2015-02-23 07:56 Christian Grothoff Note Added: 0008920
2015-02-23 14:27 amatus Note Added: 0008922
2015-02-23 23:45 Christian Grothoff Note Added: 0008924
2015-02-28 14:39 Christian Grothoff Note Added: 0008931
2015-02-28 14:39 Christian Grothoff Status assigned => resolved
2015-02-28 14:39 Christian Grothoff Fixed in Version => 0.11.0pre66
2015-02-28 14:39 Christian Grothoff Resolution open => fixed
2018-06-07 00:25 Christian Grothoff Status resolved => closed