View Issue Details

IDProjectCategoryView StatusLast Update
0005513GNUnetobsoletepublic2024-05-03 12:02
Reporteramatus Assigned ToChristian Grothoff Due Date
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionwon't fix 
Platformamd64OSdebianOS Version9
Product VersionGit master 
Target Version0.11.0Fixed in Version0.11.0 
Summary0005513: gnunet-peerinfo -i floods gnunet-service-transport with client connections
Descriptiongnunet-peerinfo will open a client connection to gnunet-service-transport for every address in every peer known without any rate limiting. This can eat up all available file descriptors of gnunet-service-transport, which currently doesn't deal with it very well (0005511).
Steps To ReproduceRun `gnunet-peerinfo -in` over and over again until gnunet-service-transport locks up.
TagsNo tags attached.

Activities

Christian Grothoff

2019-01-26 05:06

manager   ~0013468

I'm not sure we care, for three reasons:
1) select() loop should eventually be replaced with epoll(), eliminating the FD limit;
2) peerinfo is being replaced with peerstore in TNG
3) TNG plugins won't require connections to transport anymore to print addresses

In other words, the redesign will make the _entire_ problematic described here go away. Sure, this will still apply as a problem to 0.11.0 (as TNG won't be ready by then). So for 0.11.0, the fix I'd most like to see is #1: add epoll() support and lift FD limit ;-).

Christian Grothoff

2019-02-12 07:44

manager   ~0013668

0005511 was fixed, hence setting this particular one to wontfix, as there is really no point in fixing it as with TNG the entire architecture will change.

Issue History

Date ModifiedUsernameFieldChange
2019-01-25 17:37amatusNew Issue
2019-01-26 05:06Christian GrothoffNote Added: 0013468
2019-01-26 05:06Christian GrothoffSeveritymajor => minor
2019-01-26 05:06Christian GrothoffStatusnew => acknowledged
2019-02-12 07:44Christian GrothoffNote Added: 0013668
2019-02-12 07:44Christian GrothoffAssigned To => Christian Grothoff
2019-02-12 07:44Christian GrothoffStatusacknowledged => closed
2019-02-12 07:44Christian GrothoffResolutionopen => won't fix
2019-02-12 07:44Christian GrothoffFixed in Version => 0.11.0
2019-02-12 07:44Christian GrothoffTarget Version => 0.11.0
2024-05-03 12:02Christian GrothoffCategorypeerinfo service => obsolete