View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002896 | GNUnet | cadet service | public | 2013-06-18 19:45 | 2013-12-24 20:54 |
| Reporter | Florian Dold | Assigned To | Bart Polot | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Product Version | Git master | ||||
| Target Version | 0.10.0 | Fixed in Version | 0.10.0 | ||
| Summary | 0002896: clarify tunnel shutdown semantics | ||||
| Description | It is currently not defined what happens with messages already sent (by either side of the tunnel) when a client destroys the tunnel. While some clients may just want to destroy the connection and ignore lost messages, it is often necessary for the tunnel to perform a proper shutdown. Thus, either GNUNET_MESH_tunnel_destroy should be changed accordingly, or a new function GNUNET_MESH_tunnel_shutdown should be introduced. On a related note, why does GNUNET_MESH_tunnel_destroy not call the tunnel end handler? This is inconsistent with GNUNET_SERVER_client_disconnect, and inconvenient insofar as there's no way to retrieve the tunnel context when explicitly destroying the tunnel -- the user must always additionally store it in some data structure. | ||||
| Tags | No tags attached. | ||||
|
|
This design / API consistency issues would be better answered by Christian. I see a certain conflict, the more we want to emulate TCP's behavior, the less consistent we make the API... As for the current behavior, calling tunnel destroy makes sure that all pending outgoing messages will be delivered, but no incoming messages will be accepted anymore. To have a shutdown with ACk for all data, both sides must agree to close the connection, otherwise the side that did not destroy the tunnel cannot know whether the last data messages were received or not. Alternatively we could just include a ACK value in the "FIN" packet and add a "last received message" value to the TunnelEndHandler callback... which would require counting on the client side anyway... |
|
|
So there are two issues here - We agreed that calling the end handler on explicit shutdown makes sense. - As for _shutdown call, we won't implement any. tunnel_destroy makes a best effort attempt to deliver all pending outgoing messages but stops listening immediately. If a two-way reliable delivery of last messages is needed, it must be accomplished by an application level FIN-ACK handshake before any of the peers calling tunnel_destroy. |
|
|
Fixed in r27481 - r27483. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2013-06-18 19:45 | Florian Dold | New Issue | |
| 2013-06-18 19:45 | Florian Dold | Status | new => assigned |
| 2013-06-18 19:45 | Florian Dold | Assigned To | => Bart Polot |
| 2013-06-19 02:21 | Bart Polot | Note Added: 0007155 | |
| 2013-06-19 02:22 | Bart Polot | Note Edited: 0007155 | |
| 2013-06-19 11:09 | Bart Polot | Note Added: 0007161 | |
| 2013-06-19 11:09 | Bart Polot | Status | assigned => acknowledged |
| 2013-06-19 11:29 | Bart Polot | Note Added: 0007162 | |
| 2013-06-19 11:29 | Bart Polot | Status | acknowledged => resolved |
| 2013-06-19 11:29 | Bart Polot | Fixed in Version | => Git master |
| 2013-06-19 11:29 | Bart Polot | Resolution | open => fixed |
| 2013-06-25 12:11 | Christian Grothoff | Fixed in Version | Git master => 0.10.0 |
| 2013-06-25 12:11 | Christian Grothoff | Target Version | => 0.10.0 |
| 2013-12-24 20:54 | Christian Grothoff | Status | resolved => closed |
| 2014-05-09 18:34 | Christian Grothoff | Category | mesh service => cadet service |
