Re: [Help-gnunet] Questions on latest version

[Christian Grothoff]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

>  Like I've said in the past, the segfaults seem to be *very* unpredictable
> (I've certainly tried to find a reliable way to reproduce them in the
> past), and I don't habitually run processes through GDB.
> This time, I managed to get:
>
> Starting program: /usr/local/bin/gnunet-gtk
> [New Thread 1024 (LWP 799)]
> [New Thread 2049 (LWP 800)]
> [New Thread 1026 (LWP 801)]
> [New Thread 2051 (LWP 802)]
> [New Thread 3076 (LWP 807)]
> [New Thread 4101 (LWP 809)]
> [New Thread 5126 (LWP 811)]
>
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 1024 (LWP 799)]
> 0x08055d08 in _IO_stdin_used ()
> (gdb) ba
> #0  0x08055d08 in _IO_stdin_used ()
> #1  0x08055d03 in _IO_stdin_used ()
> #2  0x00000000 in ?? ()
>
> after trying to start a download. I forget what caused the segfault a few
> days ago, but in the past it's generally been from simply starting
> searches. Whether it's been for unusual keywords or common keywords or
> second searches or first searches, or what, has *never* been clear to me.

That trace doesn't really say anything (stack trace is garbage).  Could be 
pthreads (glibc-version?), could be anything.  What platform are you using? 
If it is Linux/x86, I'd suggest starting gnunet-gtk with valgrind (x86 memory 
debugger), that may tell us which component is to blame. Yes, it will be slow 
- -- on a P4 performance is acceptable.  Do other GTK applications run nicely?

> > For me, it has been rock solid for the
> > last versions (what GTK version are you using???)
>
> The debian/stable package of libgtk1.2 (1.2.10-11)
> which has the filename of libgtk-1.2.so.0.9.1 (don't ask me how they
> come up with the numbers...)

Same version that my RH machine presumably uses (1.2-so.0.9.1), which does 
work.  Puzzling.

<Zaaaaap>

>  What does the URI look like for SBlocks? AFAICT I've not seen one in any
> search response yet.

You won't unless you use gnunet-search-sblock (which should be integrated with 
gnunet-search in the future). You need to specify a namespace (which you can 
learn about out-of-band or by finding a directory that contains some other 
SBlock in that namespace --- or by using your own namespace ID...) together 
with the key. The resulting SBlock URL looks like this:

gnunet://afs/NAMESPACE-ID-IN-HEX/KEYWORD-ID-IN-HEX

Anyway, gnunet-search-sblock currently does not yet support the URI format and 
only gnunet-gtk displays the result of an SBlock insertion in that format 
(which is to the best of my knowledge the only place that actually uses it). 
So it's kind of rare to encounter one of these at the moment :-)

<Zappppp>

> > The problem is, that this is the only practical way to get all of the
> > file-identifiers straight. gnunet-gtk allows you to freely compose
> > directories from files inserted earlier. A GUI is the only good answer to
> > a drag-and-drop build-my-directory problem. I just see no good way to do
> > this with a simple CLI.
>
>  Unless the CLI programs are used as tools by other gnunet programs (eg:
> gui clients implemented with scripts). Not that I'd want the existing
> CLI utilities to be relegated to only being used that way, but you know
> what I mean. It's just a thought though, perhaps even that approach
> is flawed.

Well, I thought of clients linking against the "esed2" library (see current 
CVS) which then provides functions for "insert file", "download file", 
search, etc.  That's how the CLIs and gnunet-gtk work.  They are just some 
small (or not so small for GTK) user interface plugged on top of that 
library. 

In the gnunet_util.h and gnuent_afs_esed2.h header files, you can find the two 
definitions:

/**
 * Get a GNUnet TCP socket that is connected to gnunetd.
 **/
GNUNET_TCP_SOCKET * getClientSocket();

/**
 * Inserts a file under the given name into the local GNUnet node.
 *
 * @param sock the socket to use to talk to gnunetd
 * @param filename the name of the (incoming/source) file
 * @param model the insert model used to
 *        update status information; points to NULL if
 *        no status updates shall be given, otherwise
 *        to a method that takes two size_t arguments
 *        (retrieved so far, total).
 * @param model_data pointer that is passed to the model method
 * @return top IBlock on success, NULL on error
 **/
Block * insertFile(GNUNET_TCP_SOCKET * sock,
                   char * filename,
                   ProgressModel model,
                   void * model_data);

A trivial gnunet-insert would look like this in C:
#include <stuff>
int main(int argc, char ** argv) {
  insertFile(getClientSocket(), argv[1], NULL, NULL);
}

Ok, this one has memory leaks and you probably want to pass a callback 
(ProgressModel) to be informed about the progress, but I think this will be 
much simpler than "fork(); exec("gnunet-insert");" with all of the code 
around it to setup arguments and parse the output of the command 
(stdout/stderr).  The above should also be easier to maintain.

> > Easier to understand, maybe. Easier to use, definitely not. Also note
> > that gnunet-insert still can NOT do everything that the system may allow
> > you to do (like insert a file into your namespace of which you only have
> > the file identifier)
>
>  I'd been wondering if that was the case. Your explanation that directories
> could point to files in either way made me try to figure out how
> gnunet-insert supported that, and I couldn't come up with anything.

Reason being that gnunet-insert can not do it (yet? what would the option look 
like?)

> >. gnunet-gtk actually can do that, but it currently does not allow
> > you to specify "N" and "T". While I'd like both tools to be able to do
> > everything, it'll take some more time to get there.
>
>  Hey, simply having the namespaces and directories is a great step
> forward already; I think as long as there's *some* way to do this stuff,
> that's the main thing. Not that I don't care how complete everything
> is, I'm just saying don't feel too pressured to get it all done straight
> away. Or something. Ahem.

Right, especially since we're talking tool support and documentation here. The 
core of the system (gnunetd, routing, esed2 library) supports everything 
already, and it will obviously take a while to push it to the state where 
everything is *easy* to use.

C
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE/Vjjo9tNtMeXQLkIRArVCAJ9rjXwwq/xEvKEIOtJhFpifhVaG9QCfe40J
oj5+SQILuqlqKsn8fUdfvAA=
=kXkb
-----END PGP SIGNATURE-----