[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [GNUnet-developers] On applications using GNUnet
From: |
Alessio Vanni |
Subject: |
Re: [GNUnet-developers] On applications using GNUnet |
Date: |
Tue, 06 Aug 2019 17:18:20 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) |
> I don't know which documentation sentence in what manual you are
> referencing here, but I think that documentation is simply wrong. CADET
> is port-scan resistant, in that the peer will simply not send anything
> back if the port is not open. In fact, CADET will accept your incoming
> request into an internal table in anticipation that maybe in the future
> a local application will open that port, and then establish the
> connection (as the client might have just been a bit faster than the
> service opening the port). So as a client connecting to a closed port
> will just seem to take "a long time" (= forever), until and unless some
> application opens the port, at which point the session is acknowledged
> and properly opened. But by design you cannot distinguish between a
> closed port and CADET actually failing to reach the target peer -- or
> things just being slow.
In gnunet_cadet_service.h, the documentation comment for
GNUNET_CADET_channel_create says:
/**
* Create a new channel towards a remote peer.
*
* If the destination port is not open by any peer or the destination peer
* does not accept the channel, @a disconnects will be called
* for this channel.
According to this comment, if the destination peer does not have the
specified port opened, then at some point in time I should be notified
about it by the `disconnects' callback. However, if CADET works like
you says, then this comment is wrong (or outdated.)
> Yes, generally it is expected that the application protocol will use the
> session once it is up and exchange messages ;-).
I understand, thanks.
> In addition to Martin's answer, I would add that if you replace ".fun"
> with say ".pin" (our FCFS TLD), it will work. Or if you use ".fr" and
> are using GNS to resolve things in the French .fr TLD. Or see Martin's
> suggestions. Many choices, some will work, some won't. In particular,
> putting "party.alessio" is unlikely to work, unless most operating
> system distributions ship with your zone in their root zone file ;-).
Yes, thanks to Martin now I figured how it works. I need to experiment,
but I should have the basics down.
- Re: [GNUnet-developers] On applications using GNUnet, (continued)
Re: [GNUnet-developers] On applications using GNUnet, Heiko Stamer, 2019/08/07
Re: [GNUnet-developers] On applications using GNUnet, Christian Grothoff, 2019/08/06
Re: [GNUnet-developers] On applications using GNUnet, Christian Grothoff, 2019/08/06
Re: [GNUnet-developers] On applications using GNUnet, Christian Grothoff, 2019/08/06
Re: [GNUnet-developers] On applications using GNUnet, Christian Grothoff, 2019/08/06
- Re: [GNUnet-developers] On applications using GNUnet,
Alessio Vanni <=