[Top][All Lists]

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

Does gnunet-download ever contact gnunet-service-fs?

From: Cy
Subject: Does gnunet-download ever contact gnunet-service-fs?
Date: Thu, 14 May 2020 20:48:20 -0700
User-agent: Evolution 3.34.4

I'm trying to understand how gnunet-download works, despite its abominable 
amount of
immediate scheduling and abstractions. One thing I'm confused about though. 
download is an FS client, right? Uses gnunet-service-fs to download?

I attached to gnunet-service-fs using a debugger, then fired up gnunet-download 
for my
download that's bugging out, but I couldn't find which callback was invoked 
when gnunet-
download tells the service to start downloading. Sometimes mysterious "peers" 
connect to the service, unrelated to gnunet-download, but gnunet-download itself
downloaded everything without connecting to gnunet-service-fs. I finally just 
hit "next"
in gdb, so that it would immediately drop to the gdb prompt as soon as the 
select loop in
gnunet-service-fs registered activity. Then I hurriedly switched windows, fired 
another gnunet-download, and... nothing. gnunet-service-fs never left the core 
select loop
for the whole download. Then it left the core select loop when another one of 
"peers" connected.

I'm sure the files are deleted in the directory I'm downloading them to. 
They're indexed
elsewhere on disk, or at least they should be, since I said so while publishing 
gnunet-fs -i only lists one of the files in the
directory (derp/herp/derpxjmfn/filehktb.txt) not any of the other 223 files. 
I'm sure I did publish them just now, and I'm sure I'm not downloading on top 
of existing
data, in case that gnunet-download might be a no-op, if the download already 
matches with
the hash. But even accounting for all this, gnunet-download never connects to 

What does gnunet-download connect to?

Other weirdness, my buggy download actually started inexplicably succeeding. 
Before today,
it would just hang forever. Now it quickly produces the files I just published 
without any
delay, then freezes halfway through. Then a minute later, it dumps out the rest 
of the
files, again without a delay, and successfully completes. 

Seriously, this is what I get:
$ time gnunet-download -V -V -V -R -o
0.06s user 0.01s system 0% cpu 1:00.12 total

Exactly one minute. I verified this twice.

I'm guessing that one of my peers is storing the latter half of the directory I 
But why isn't my own node storing it? Or indexing it? Why exactly one minute's 
delay? Why
only one file in my test data being indexed?  What about the other 224 files I 
in that directory? What about that directory itself?

reply via email to

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