[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: Fri, 22 Mar 2019 09:36:13 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1

On 3/21/19 9:16 PM, t3sserakt wrote:
> Hi Christian,
> is this major issue of identifying a specific tunnel documented somewhere?

Not really, I'm also not sure it is a 'major issue'. The basic problem
is that tunnels are an internal design detail of CADET, and tunnels are
constantly created and destroyed, and there is no clear 'identifier' one
can associated with a tunnel. So while CADET has one (basically, the
pointer), that's not something we can give out via the IPC API --- and
except for debugging, there is no real need to do so.

> 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.

Well, the initiating peer will first create a channel, and then setup a
connection, and then find paths to create tunnels for it.  On the other
end, first the other peer will show up with a tunnel, then a connection
is established (KX), and finally channels. So until the KX is finished,
you will exactly see the situation you describe, with one peer knowing
about the channel (as it is trying to create one), and the other one
only having a tunnel (or more!) and a connection.

> 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?

Ok, that suggests maybe our timeout for idle tunnels is way too short?
That's quite possible, all of those parameters have not been properly tuned.

> 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?

I'd start with the idle-tunnel timeout value. Our transport is sometimes
excessively slow (hence the work on TNG), and as a result maybe we hit
the tunnel timeout and then have to do it all again, possibly never
making progress on getting the channel up.

Happy hacking!


Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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