View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002882 | GNUnet | transport service | public | 2013-05-08 23:21 | 2013-12-24 20:55 |
| Reporter | Sree Harsha Totakura | Assigned To | Matthias Wachs | ||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | closed | Resolution | no change required | ||
| Product Version | Git master | ||||
| Target Version | 0.10.0 | Fixed in Version | 0.10.0 | ||
| Summary | 0002882: Transport plugins should allow binding to given addresses | ||||
| Description | Transport plug-ins of a peer currently provide addresses of all available network interfaces available on the host the peer is running. These addresses are then advertised by the peer in its HELLO message and are to be validated by other peers which try to connect to this peer. While this behavior is desired on a production system as it tries to make connectivity between peers robust, it is problematic for testing scenarios (especially on the SuperMUC). The problem here is that a host may have many interfaces, each with multiple IPv4 and IPv6 addresses. It is also possible, as in the case with SuperMUC, that only some or one of the interfaces are actually connected to high-speed network (infiniband) and the other ones are all left for management/side-channel communications. While deciding which address to actually use for transport level communications, the peers may choose the slow interfaces. Also, the peers will try to validate all the addresses advertised in their HELLO messages leading to unnecessary overhead during experiment setup. Having a feature to restrict the transport plug-ins to bind to a particular address will solve this problem. The plug-ins will then no longer advertise all available interfaces and the experimenter can set-up the corresponding high-speed interface's address as the bind address forcing the communications to only happen through the high-speed network. Relevant code required for this features seems to exist | ||||
| Tags | No tags attached. | ||||
|
|
Supported by plugin: tcp udp Current issue: NAT returns more external addresses |
|
|
Sree: What's the last state of this issue after the discussion with CG? |
|
|
I recall from the discussion that the issue with NAT returning more external addresses is expected and hence no change is required for it. For testbed/testing scenarios NAT will be simple turned off. Support for binding to a specific interface address is to be added to testbed/testing code. Hence, this issue may be marked as resolved. |
|
|
ACK ... so I can close it |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2013-05-08 23:21 | Sree Harsha Totakura | New Issue | |
| 2013-05-08 23:21 | Sree Harsha Totakura | Status | new => assigned |
| 2013-05-08 23:21 | Sree Harsha Totakura | Assigned To | => Matthias Wachs |
| 2013-05-08 23:22 | Sree Harsha Totakura | Description Updated | |
| 2013-05-14 18:30 | Matthias Wachs | Note Added: 0007099 | |
| 2013-05-27 09:42 | Matthias Wachs | Note Added: 0007119 | |
| 2013-05-27 09:42 | Matthias Wachs | Status | assigned => feedback |
| 2013-05-27 13:12 | Sree Harsha Totakura | Note Added: 0007130 | |
| 2013-05-27 13:12 | Sree Harsha Totakura | Status | feedback => assigned |
| 2013-05-28 09:11 | Matthias Wachs | Note Added: 0007133 | |
| 2013-05-28 09:11 | Matthias Wachs | Status | assigned => resolved |
| 2013-05-28 09:11 | Matthias Wachs | Resolution | open => no change required |
| 2013-06-01 14:50 | Christian Grothoff | Fixed in Version | => 0.10.0 |
| 2013-06-01 14:50 | Christian Grothoff | Target Version | => 0.10.0 |
| 2013-12-24 20:55 | Christian Grothoff | Status | resolved => closed |
