On 23.03.19 15:02, Christian Grothoff wrote: > Well, that could be it, given that we do sometimes see very large > transport delays. Not sure, of course. Now, with transport working > properly, 90s should of course be sufficient...
But why do I see those delays quite often, if transport works properly now. Is it, because some nodes might still use old code base? > On 3/22/19 9:49 AM, t3sserakt wrote: >> I looked into the code. Idle tunnel means no channel, but it is checked >> only if >> >> CADET_TUNNEL_KEY_UNINITIALIZED >> >> and the destroy_tunnel task is scheduled and triggered after 90 seconds >> >> On 21.03.19 21:16, t3sserakt wrote: >>> Hi Christian, >>> >>> is this major issue of identifying a specific tunnel documented somewhere? >>> >>> Is this issue the reason why I only see the output of /GNUNET_i2s_full >>> (peer)/ where the tunnel is to be identified? Then the only additional >>> information the '-t' option was giving is the identifiers of channels >>> and connections. >>> >>> Maybe I describe the problem I am searching after a bit more in >>> detail, to let you know why I hoped the '-t' option could give me >>> helpful information. >>> >>> When I am testing the connectivity between nodes via cadet. Sometimes >>> the creation of a functioning channel I can use for sending messages >>> between nodes back and forth is within seconds, sometimes it need >>> minutes or hours, or I stop the testing, because it takes to long. >>> These tests are exploratory by doing manual real world tests. No >>> automatic testing. >>> >>> In the case of not being able to send messages from one node to the >>> other, I see - using the '-P' and '-T' option - on one node there is >>> both a tunnel and a channel to the other node, on the other node I >>> never see a channel and sometimes a tunnel. How is it possible to have >>> one node having tunnel and channel to the other node, if the other >>> nodes knows nothing about this channel and tunnel. >>> >>> In the logs of the node sometimes knowing of a tunnel and sometimes >>> not, I see the tunnel is created and destroyed (because being idle) in >>> short intervals. So it looks like there is some basic connectivity >>> between those nodes, otherwise the tunnel would not be created again >>> and again, right? >>> >>> So my best guess at the moment is, that we maybe might have a similar >>> problem with the reliability of message send back and forth between >>> nodes for channel creation. >>> >>> Another finding is, that despite the fact that on one node >>> gnunet-cadet is showing me the existence of a tunnel all the time I >>> see a lot of >>> >>> "Trying to make KX progress on Tunnel XXXX in state >>> CADET_TUNNEL_KEY_AX_AUTH_SENT" >>> >>> log messages. >>> >>> Before I start searching for the needle in the haystack, do you have >>> any idea where to start my search in the code, or if it might be >>> another reason to look after than reliability of channel creation >>> messages? >>> >>> Happy hacking! >>> >>> t3ss >>> >>> On 20.03.19 08:47, Christian Grothoff wrote: >>>> Hi t3ss, >>>> >>>> Well, what the old '-t' option showed wasn't really useful for current >>>> CADET, and it wasn't obvious to me what we would want to show that >>>> wasn't covered by the '-P', '-p' and '-T' options post #5385. >>>> Furthermore, there is the major issue of identifying a specific >>>> 'tunnel'. So right now, the '-p' option covers (most of?) this, and >>>> usually I would say that if there were more information to be returned, >>>> it could probably be included in the existing -pPT option family. >>>> >>>> That said, if you have some information to be returned that is not >>>> easily covered by extending -pPT, I'm not against re-introducing '-t'. >>>> It just didn't seem to serve any useful purpose anymore. >>>> >>>> Happy hacking! >>>> >>>> Christian >>>> >>>> On 3/20/19 7:15 AM, t3sserakt wrote: >>>>> Hey Christian, >>>>> >>>>> >>>>> after the fix of #5385 gnunet-cadet had no "-t" option anymore to show >>>>> info about a specific tunnel. why that? >>>>> Do we "only" need to reimplement this option with the asynchronous API >>>>> that was introduced with #5385? >>>>> >>>>> >>>>> Cheers >>>>> >>>>> >>>>> t3ss >>>>> >>>> _______________________________________________ >>>> GNUnet-developers mailing list >>>> [email protected] >>>> https://lists.gnu.org/mailman/listinfo/gnunet-developers >>> _______________________________________________ >>> GNUnet-developers mailing list >>> [email protected] >>> https://lists.gnu.org/mailman/listinfo/gnunet-developers >> _______________________________________________ >> GNUnet-developers mailing list >> [email protected] >> https://lists.gnu.org/mailman/listinfo/gnunet-developers >> > > _______________________________________________ > GNUnet-developers mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/gnunet-developers
signature.asc
Description: OpenPGP digital signature
_______________________________________________ GNUnet-developers mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnunet-developers
