Re: [GNUnet-developers] Troubleshooting CADET

[Christian Grothoff]

Hi,

A few quick comments:

1) Yes, it is normal that peers that are running for longer should have
an easier time connecting to other peers via CADET. CADET takes time to
announce itself and to learn about the network. This effect is expected
and in fact documented in our paper(s) via measurements.

2) Yes, running in the 'global' network with outdated peers is likely to
cause all kinds of fun problems, as the DHT may or may not work, or in
the worst case the DHT discovers a path which then does not work on the
CADET layer because some hop speaks just enough of the DHT protocol but
not enough of the CADET protocol.

3) Transport does throw quite a few error messages or warnings these
days, largely whenever something takes so long that it will likely cause
some unexpected performance degradation.  Transport is big on my list of
things that needs an overhaul; however, a reasonable workaround is to
disable http/https and stick to tcp/udp-only.  Then there will still be
some warnings (like the UDP flow delay warning), but I'm not aware of
that causing _serious_ problems (unless you need low-latency for
GNUnet-conversation...).

Hope this helps / clarifies a bit.

Happy hacking!

Christian

On 10/26/2017 05:19 PM, peter wrote:
> Hi Martin.
> 
> On 26/10/17 15:03, Schanzenbach, Martin wrote:
>> Personally, I have wondered if maybe the peers that are currently running 
>> (as in the current GNUnet P2P network which are served by through the 
>> gnunet.org hostlist) might not all be on the same version.
>> I am not sure what happens if a node encounters traffic that it does not 
>> understand due to a very old GNUnet version (0.10.x).
>> For example: As far as I remember, nodes drop blocks that are routed 
>> to/through them if they cannot validate them (using the respective block 
>> plugin).
> 
> This would make a lot of sense and matches my observations.
> 
>> Maybe try testing it using a dedicated P2P network of your own nodes?
> 
> This indeed seems to have helped. When I add `FORCESTART = NO` and
> `SERVERS =` to [hostlist] in all config files and then connect the nodes
> using gnunet-peerinfo, the nodes connect quite quickly.
> 
> If I make one of the nodes a server using `OPTIONS = -p 8080` and set
> `SERVERS = <MY DROPLET IP>:8080` on the other nodes, then it also seems
> to work, although I had to wait few minutes for the connection to get
> established.
> 
> I also see a lot of warnings and errors which look like this:
> 
> Oct 26 11:07:19-599311 transport-28379 ERROR Assertion failed at mq.c:347.
> Oct 26 11:07:19-599485 transport-28379 WARNING Calculated flow delay for
> UDPv4 at 1 m for 0HE4
> Oct 26 11:07:19-599627 transport-28379 WARNING Calculated flow delay for
> UDPv4 at 1 m for 0HE4
> 
> Not sure whether that is related. But it does appear as if gnunet is
> still communicating with other nodes (in both cases, when connected
> manually and when one node is a bootstrap server).
> 
> Thanks!
> 
> Peter
> 
> 
> 
> _______________________________________________
> GNUnet-developers mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/gnunet-developers
>

signature.asc
Description: OpenPGP digital signature