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
address@hidden
https://lists.gnu.org/mailman/listinfo/gnunet-developers
_______________________________________________
GNUnet-developers mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/gnunet-developers
_______________________________________________
GNUnet-developers mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/gnunet-developers
_______________________________________________
GNUnet-developers mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/gnunet-developers
|
signature.asc