View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002934 | GNUnet | cadet service | public | 2013-07-09 23:25 | 2013-12-24 20:54 |
| Reporter | Florian Dold | Assigned To | Bart Polot | ||
| Priority | normal | Severity | feature | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Product Version | Git master | ||||
| Target Version | 0.10.0 | Fixed in Version | 0.10.0 | ||
| Summary | 0002934: make mesh's client-service protocol nicer | ||||
| Description | Currently, mesh's client-service protocol still differentiates between unicast and to_origin. See Additional Information for an example of what I would consider unnecessary code for the current mesh, which does not have multicast. Furthermore, I don't fully understand the purpose of numbering packets from the mesh-api to the service, as client-service communication is reliable and in-order. I also don't get the different between the pid and the tid of mesh packets (mesh.api:1236). Additionally, for transmitting data from the mesh api to the mesh service, the struct GNUNET_MESH_Data is used, but its definition is in mesh_protocol.h, not mesh.h. All this makes it harder to implement alternative bindings to GNUnet. | ||||
| Additional Information | mesh_api.c:1242 if (t->tid >= GNUNET_MESH_LOCAL_TUNNEL_ID_SERV) { dmsg->header.type = htons (GNUNET_MESSAGE_TYPE_MESH_TO_ORIGIN); LOG (GNUNET_ERROR_TYPE_DEBUG, "# to origin, type %s\n", GNUNET_MESH_DEBUG_M2S (ntohs (mh->type))); } else { dmsg->header.type = htons (GNUNET_MESSAGE_TYPE_MESH_UNICAST); LOG (GNUNET_ERROR_TYPE_DEBUG, "# unicast, type %s\n", GNUNET_MESH_DEBUG_M2S (ntohs (mh->type))); } mesh_api.c:1231 if (psize > 0) { psize += sizeof (struct GNUNET_MESH_Data); GNUNET_assert (size >= psize); dmsg->header.size = htons (psize); dmsg->tid = htonl (t->tid); dmsg->pid = htonl (t->last_pid_sent + 1); dmsg->ttl = 0; memset (&dmsg->oid, 0, sizeof (struct GNUNET_PeerIdentity)); t->last_pid_sent++; } | ||||
| Tags | No tags attached. | ||||
|
|
MESH_Data should indeed be moved to mesh.h or replicated there with a simplified version. The differentiation between unicast and to_orig indicate the direction of the traffic, think of it as sender/destination address equivalent. It is needed in case a relay node gets the traffic from an unexpected peer. Numbering packets is done in the client for historical reasons, it would be possible to eliminate that in the future. Finally: - tid: tunnel ID - pid: packet ID |
|
|
Sorry, the tid vs pid is actually quite obvious, I was a bit confused ;) I still don't get why the distinction between unicast and origin is necessary on the client side. From the api perspective, we simply send a message over a tunnel. Why is it necessary for the details to be handled by the api implementation, and not the service itself? |
|
|
That would be again historical reasons. Will fix soon. |
|
|
BTW: historical reasons = multicast fallout |
|
|
Should be addressed in r27871. If anything is still unnecessary ugly/complicated, please let me know. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2013-07-09 23:25 | Florian Dold | New Issue | |
| 2013-07-09 23:25 | Florian Dold | Status | new => assigned |
| 2013-07-09 23:25 | Florian Dold | Assigned To | => Bart Polot |
| 2013-07-09 23:35 | Bart Polot | Note Added: 0007216 | |
| 2013-07-09 23:41 | Florian Dold | Note Added: 0007218 | |
| 2013-07-09 23:43 | Bart Polot | Note Added: 0007219 | |
| 2013-07-09 23:44 | Bart Polot | Note Added: 0007220 | |
| 2013-07-10 14:03 | Bart Polot | Note Added: 0007221 | |
| 2013-07-10 14:03 | Bart Polot | Status | assigned => resolved |
| 2013-07-10 14:03 | Bart Polot | Fixed in Version | => Git master |
| 2013-07-10 14:03 | Bart Polot | Resolution | open => fixed |
| 2013-07-10 14:41 | Christian Grothoff | Product Version | => Git master |
| 2013-07-10 14:41 | Christian Grothoff | Fixed in Version | Git master => 0.10.0 |
| 2013-07-10 14:41 | 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 |
