[Top][All Lists]

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

Re: [GNUnet-developers] On applications using GNUnet

From: Christian Grothoff
Subject: Re: [GNUnet-developers] On applications using GNUnet
Date: Tue, 6 Aug 2019 15:42:05 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0

On 8/4/19 4:17 PM, Alessio Vanni wrote:
> A question on CADET: I wrote a silly program that scans each peer
> checking if a specific port is open (it was part of an experiment.)  The
> documentation says that if the port is closed a certain callback is
> called, but when I tried it the function is never called until the
> channel is destroyed by disconnecting from the CADET service.  

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.

> Actually,
> I log a message when the function is called, but this message is never
> printed until the program exits.  I can't tell if I'm doing something
> wrong because the documentation is either outdated (at least the one in
> the website) or somewhat cryptic.  The question is how to make sure the
> connection with the other peer is established.  Do I have to send a
> message and see what happens?

Yes, generally it is expected that the application protocol will use the
session once it is up and exchange messages ;-).

> Lastly, a question on GNS, which is the part I understood less: let's
> say I'm walking down the street and see a flyier advertising something
> and saying something like "visit us on GNUnet at".  Let's also
> say I don't have GNUnet installed, so when I get back home I install it
> and try to resolve the "" address.  What happens then? Do I get
> something or not? If I do, what do I get?  In particular, is "fun"
> unique like with DNS? If not and is resolved, do I get a single result
> or multiple ones?  Sorry for the barrage of questions, but I'm having a
> hard time understanding some of GNS's implications.

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

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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