[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GNUnet-developers] gnunet-cadet information about a specific tunnel

From: Christian Grothoff
Subject: Re: [GNUnet-developers] gnunet-cadet information about a specific tunnel
Date: Sat, 23 Mar 2019 15:02:58 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1

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
> 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
>> 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
>>> address@hidden
>> _______________________________________________
>> GNUnet-developers mailing list
>> address@hidden
> _______________________________________________
> GNUnet-developers mailing list
> address@hidden

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]