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...
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 >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ GNUnet-developers mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnunet-developers
