View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002186 | GNUnet | GNS | public | 2012-02-28 10:01 | 2013-08-15 14:47 |
| Reporter | schanzen | Assigned To | Christian Grothoff | ||
| Priority | low | Severity | feature | Reproducibility | N/A |
| Status | closed | Resolution | won't fix | ||
| Product Version | Git master | ||||
| Target Version | Git master | Fixed in Version | Git master | ||
| Summary | 0002186: GNS service needs zone transfer functionality | ||||
| Description | We need some way to transfer zones between GNS nodes. I suggest a second block plugin for the GNSNameRecordBloc/GNSRecordBlock layout would be incompatible with a zone information block because they can also contain private records. Either: Store all of the (non private) records in the block and sign them (namestore api) or Put meta information into the block to allow communication with the peer (via mesh?) | ||||
| Tags | No tags attached. | ||||
|
|
Actually, the idea was that each GNS service periodically PUTs a (trivial) block (with a new block type, key is hash of public key) with just the (signed) current zone revision number (which we need to make up and store somehow, I know -- different issue) into the DHT --- and enables path tracking for that block. Then, when we want to do a zone transfer, we just do a GET for that block and thus 'learn' a path to the other GNS peer (there'll eventually be an API for us to give such paths to mesh, for now this detail can be ignored). Then we ask the *stream* library to create a TCP-like connection to the other GNS peer and send a "please start (incremental) zone transfer starting with (last revision we have)". Then we get a stream of the blocks in the DHT that have changed since the last revision. At least that was my vision for this. |
|
|
With the recent addition of query privacy ("new crypto"), the zone transfer makes even less sense. Even with DNS, this is these days an unpopular feature. And database replication can be done with tools from the respective database (of the namestore). So I think this would simply be a miss-feature. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2012-02-28 10:01 | schanzen | New Issue | |
| 2012-02-28 10:01 | schanzen | Status | new => assigned |
| 2012-02-28 10:01 | schanzen | Assigned To | => schanzen |
| 2012-03-16 22:07 | Christian Grothoff | Note Added: 0005623 | |
| 2012-03-16 22:11 | Christian Grothoff | Product Version | => Git master |
| 2012-03-16 22:11 | Christian Grothoff | Target Version | => 0.9.4 |
| 2012-04-18 15:50 | Christian Grothoff | Severity | major => feature |
| 2012-06-20 15:47 | Christian Grothoff | Priority | normal => low |
| 2012-06-22 10:53 | Christian Grothoff | Target Version | 0.9.4 => 0.9.5 |
| 2012-06-22 10:58 | Christian Grothoff | Target Version | 0.9.5 => 0.10.0 |
| 2012-10-07 14:06 | Christian Grothoff | Target Version | 0.10.0 => |
| 2013-07-10 23:44 | Christian Grothoff | Assigned To | schanzen => |
| 2013-07-10 23:44 | Christian Grothoff | Status | assigned => confirmed |
| 2013-08-15 14:47 | Christian Grothoff | Note Added: 0007382 | |
| 2013-08-15 14:47 | Christian Grothoff | Assigned To | => Christian Grothoff |
| 2013-08-15 14:47 | Christian Grothoff | Reproducibility | have not tried => N/A |
| 2013-08-15 14:47 | Christian Grothoff | Status | confirmed => closed |
| 2013-08-15 14:47 | Christian Grothoff | Resolution | open => won't fix |
| 2013-08-15 14:47 | Christian Grothoff | Fixed in Version | => Git master |
| 2013-08-15 14:47 | Christian Grothoff | Target Version | => Git master |
