View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003325 | GNUnet | GNS | public | 2014-02-14 21:25 | 2014-04-08 16:41 |
| Reporter | schanzen | Assigned To | Christian Grothoff | ||
| Priority | high | Severity | major | Reproducibility | have not tried |
| Status | closed | Resolution | fixed | ||
| Product Version | Git master | ||||
| Target Version | 0.10.1 | Fixed in Version | 0.10.1 | ||
| Summary | 0003325: GNS lookups never time out | ||||
| Description | Lookup non existing label in your own zone. It will hang forever because DHT lookups have no timeout. | ||||
| Tags | No tags attached. | ||||
|
|
So why is this a problem? I don't see a problem with this in gnunet-gns, but it might be a problem in the NSS plugin if the standard requires the plugin to time out. In general, I'm fine with a DHT 'get' hanging, as any timeout is arbitrary. But if there is an "expected" timeout in NSS, we should of course realize that. |
|
|
I see this as a problem: I lookup a record that does not exist in my zone. gnunet-gns should not hang. This is defined behaviour im my opinion. A DHT lookup should never happen anyway. Also it should be possible to "miss" in general. Not just "wait". Right now gns either has a result. or hangs? this is bad design. And note that (I hope!) this is only an issue where we lookup nonexistant recods in locally manged zones where DHT should be irrelevant. Example: Program X always tries to lookup AAAA record for resolution. If lookup fails fallback to A. If gethostbyname is used then gns will hand forver on the AAAA lookup. The program will have to create it's own timeout handling only for gns. NSS does not force any timeouts... and we could implements that in the plugin but... that's not really the correct place to to that IMO. |
|
|
If it is our own zone (only), I agree that we should terminate 'instantly'. Also, if there is only an A record and AAAA is asked for (or vice versa), we should return immediately. I'll look into those. Still, the DHT-timeout case where there simply was no response found, that is another issue. |
|
|
Yeat I think I miscommunicated the original issue. The thing is that it's impossible right now for the GNS resolver to "return immediately" as it has no concept of the "maste-zone" |
|
|
SVN 32351 ensures that GNS never uses the DHT if we only lookup in the master zone (only for gnunet-gns). |
|
|
SVN 32354 ensures that if GNS finds any (non-expired) block (even if all the records have the wrong record type) in the namecache, it won't even bother to go to the DHT. |
|
|
SVN 32357 adds a timeout option (-T) to gnunet-gns, which can be used by the NSS plugin if it wants to force a particular timeout on the child process. Note that NXDOMAIN on the master zone and "no matching record found" should already create a response, so I'm not sure this is required. Still, having the option seemed to make sense in general. |
|
|
Fixed a small bug in gns api to make this work. _however_ the problem is only band aided I think. Looking up test.doesnotexist.gnu will hang again, eventhough it should not. I guess we can use the timeout then but... we really shouldn't have to. |
|
|
True; the issue is that right now the gnunet-service-gns doesn't even know if it is looking up a value for which the local peer is the origin. I guess we could change the API to pass that information through from the client... |
|
|
The problem with fix is also: + records in remote zones are never reolved if it's the first label: ex. myfriend.gnu (A record) I think it might make sense to move functionality into gnunet-gns: if master zone is used: lookup first label non cached; 1. No result -> fail 2. Result exists -> return result (if applicable, i.e. single label and not PKEY) or -> resolve again non cached |
|
|
Ok, this should now be fixed in SVN 32499: I added an enum value to indicate that the top-level request is in the master zone, so even if there is foo.invalid.gnu, invalid.gnu won't go to the DHT anymore. |
|
|
Please let me know if it is better now (could not test reasonably well on this system). |
|
|
Tested it now, seems to work fine (for master zone). |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2014-02-14 21:25 | schanzen | New Issue | |
| 2014-02-14 21:25 | schanzen | Status | new => assigned |
| 2014-02-14 21:25 | schanzen | Assigned To | => Matthias Wachs |
| 2014-02-14 21:29 | schanzen | Assigned To | Matthias Wachs => Christian Grothoff |
| 2014-02-16 15:22 | Christian Grothoff | Target Version | => 0.10.1 |
| 2014-02-16 15:24 | Christian Grothoff | Note Added: 0008104 | |
| 2014-02-16 15:24 | Christian Grothoff | Status | assigned => feedback |
| 2014-02-16 15:34 | schanzen | Note Added: 0008105 | |
| 2014-02-16 15:34 | schanzen | Status | feedback => assigned |
| 2014-02-16 15:38 | Christian Grothoff | Note Added: 0008108 | |
| 2014-02-16 15:39 | schanzen | Note Added: 0008109 | |
| 2014-02-16 15:55 | Christian Grothoff | Note Added: 0008110 | |
| 2014-02-16 16:04 | Christian Grothoff | Note Added: 0008111 | |
| 2014-02-16 16:10 | Christian Grothoff | Note Added: 0008112 | |
| 2014-02-16 16:35 | Christian Grothoff | Status | assigned => feedback |
| 2014-02-16 21:38 | schanzen | Note Added: 0008116 | |
| 2014-02-16 21:38 | schanzen | Status | feedback => assigned |
| 2014-02-17 00:21 | Christian Grothoff | Note Added: 0008117 | |
| 2014-02-17 19:59 | schanzen | Note Added: 0008122 | |
| 2014-03-04 12:28 | Christian Grothoff | Note Added: 0008127 | |
| 2014-03-04 12:28 | Christian Grothoff | Note Added: 0008128 | |
| 2014-03-04 12:28 | Christian Grothoff | Status | assigned => feedback |
| 2014-03-05 15:37 | Christian Grothoff | Note Added: 0008133 | |
| 2014-03-05 15:37 | Christian Grothoff | Status | feedback => resolved |
| 2014-03-05 15:37 | Christian Grothoff | Fixed in Version | => 0.10.1 |
| 2014-03-05 15:37 | Christian Grothoff | Resolution | open => fixed |
| 2014-04-08 16:41 | Christian Grothoff | Status | resolved => closed |
