View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0004613 | GNUnet | cadet service | public | 2016-08-09 17:12 | 2018-06-07 00:48 |
| Reporter | lynX | Assigned To | |||
| Priority | normal | Severity | feature | Reproducibility | always |
| Status | acknowledged | Resolution | open | ||
| Product Version | Git master | ||||
| Summary | 0004613: Decide: How should we pass cadet signaling on to applications? | ||||
| Description | I thought it was going to be simple to improve the UX of the gnunet-cadet CLI tool by adding messages that inform the user when a connection got established (on the sender's side!) and when it got refused (instead of just terminating)... But the truth is, such information only exists in the cadet_api on a higher protocol layer than the message types that CADET apps can register handlers for. I was thinking of allowing apps also to register handlers for CADET signaling, this way they would know when an ACK or a NACK came in. I presume the types will be numerically distinct even if they aren't sent over the same layer, right? The other option would be to come up with a whole new slew of callbacks or what-the-heck in order to let applications be informed of what is going on in cadet_api.c. | ||||
| Additional Information | I expect a boost in transparency thus usability in all CADET applications if we surface signaling semantics to the higher app layers. Take VPN for example: how the heck is it supposed to find out, if the exit node has stopped servicing a certain port? It just dies, right? | ||||
| Tags | No tags attached. | ||||
|
|
I would expect that if the endpoint dies, CADET does signal that with a dropped channel via the ChannelEndHandler. But, the issue is that that it could be that we (1) lose the connection to the endpoint (network issue), then (2) the endpoint dies, and (3) we fail "forever" to re-establish a network link to the endpoint. I'm not sure what happens in this case. Timeouts are evil, so IMO the best choice we have is for the application to detect that nothing is happening and time out. But I'd not like baking a timeout into CADET here (or always passing one). Anyway, at a high-level, our plan is to next transition the CADET API to be MQ-style. There, we do have the 'enum GNUNET_MQ_Error' for signaling r/w/timeout/malformed errors to the application. The semantics of the enum are under-defined right now, so this might be an opportunity to fix that, maybe eliminating TIMEOUT as a valid value while we're at it. I do not envision CADET signaling to apps details about its internal operation, simply because apps should NOT have to know those, it prevents us from changing them, and app developers simply should not worry about these details. But we do need to be very clear about the semantics, i.e. tell apps that in the above case they are responsible to handle timeout (or wait for the user to be fed up and press CTRL-C). |
|
|
> via the ChannelEndHandler Yes, that is already in use to clean up the application. What is missing is the knowledge when a tunnel becomes available on outgoing side (I might not have figured out the flow of callbacks sufficiently well, though) or when an outgoing tunnel could not be established and the reasons behind it. PSYC uses method inheritance to provide multilingual detailed messages while at the same time allowing applications to remain stupid about such details. They just need to know how to output them, unless they have a damn good reason to provide special code. > developers simply should not worry about these details Not sure but this generally popular philosophy might actually backfire. I think of OTR as an example. While end-to-end encryption runs invisibly and solid as a rock in all applications that provide for it natively (CADET, Tor, Pond, even telegram!), OTR doing it on top of protocols while ignoring those protocol specifics results in lousy usability for the end users. PGP over SMTP/POP/IMAP is a similar success story. Luckily CADET is already its own OTR, but imagine the usual mess if we had to put OTR on top of CADET. With a PSYC-like approach, OTR would be given all the trouble details it needs to act reasonably. With APIs we try to abstract details away, but we risk to also abstract problems away into an area where we can no longer design decent UX for them. Maybe the method inheritance paradigm is something also for GNUnet. |
|
|
> What is missing is the knowledge when a tunnel becomes available on outgoing side This never happens. CADET will forever try to (re-)establish a channel/tunnel if connectivity is lost, until explicitly closed from the either side. There are a few scenarios: - connectivity temporarily lost: CADET buffers some messages and sends them when connectivity returns - remote peer crashed and is restarted (by arm, for example): CADET buffers and sends messages once remote peer comes back. Remote peer will reply "I don't know what channel you're talking about" at which point, the local clients will be notified that the channel was remotely closed (no different from an explicit remote closure). - remote peer "lost power/disappeared" and is forever gone: CADET will keep looking for a route to the peer forever, flow control will stop asking for data from the clients once lower level buffers are full. Any suggestions are welcome, of course. |
|
|
> CADET will forever try to (re-)establish a channel/tunnel Okay.. then it's just a question of designing the protocol appropriately - I should first do a simple handshake before allowing the user to produce messages for a recipient (thinking in chat use case terms). In fact, even the gnunet-cadet tool could do such a handshake before starting to pass data from STDIN. Maybe I will hack that in, if it's okay with you. > remote peer "lost power/disappeared" and is forever gone Some applications are fine with that, some will want to put some keepalive protocol on top to improve transparency. PSYC already acks all messages, so if you type a message to someone and don't see the echo of your own message on your screen within reasonable time, you know the counterpart didn't get it. But that only works with native PSYC clients, not the IRC emulation. |
|
|
gnunet-cadet command-line was initially just for running some simple tests. If you want to turn it into a nice netcat and for that want to add an initial handshake (or even a keepalive), go ahead. For the keepalive, maybe control it with a command-line option (for frequency/timeout) and communicate that as part of the initial handshake. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2016-08-09 17:12 | lynX | New Issue | |
| 2016-08-09 17:12 | lynX | Status | new => assigned |
| 2016-08-09 17:12 | lynX | Assigned To | => Bart Polot |
| 2016-08-10 13:56 | Christian Grothoff | File Added: set.diff | |
| 2016-08-10 13:58 | Christian Grothoff | File Deleted: set.diff | |
| 2016-08-10 14:07 | Christian Grothoff | Note Added: 0011013 | |
| 2016-08-10 14:46 | lynX | Note Added: 0011015 | |
| 2016-08-10 20:23 | Bart Polot | Note Added: 0011023 | |
| 2016-08-10 23:00 | lynX | Note Added: 0011026 | |
| 2016-08-10 23:08 | Christian Grothoff | Note Added: 0011027 | |
| 2018-06-07 00:48 | Christian Grothoff | Assigned To | Bart Polot => |
| 2018-06-07 00:48 | Christian Grothoff | Status | assigned => acknowledged |
