Re: [Help-gnunet] gnunet-download faulty server connection

[Christian Grothoff]

On Thursday 06 May 2004 14:50, Benjamin Kay wrote:
> The new version of gnunet-download definitely has better memory management,
> an improvement that has allowed for download speeds from a mysql database
> in excess of 900 kbps. The bad news is that I get one of these:
> May 6 19:42:08 WARNING: readTCPResult failed, server closed connection
> one of these:
> May 6 19:42:10 WARNING: receiveThread at requestmanager.c:666 could not
> read data from gnunetd, is the server running?
> and one of these:
> May 6 19:42:14 WARNING: could not send request to gnunetd, is it running?
> every few seconds. However I don't get very many messages relating the
> progress of the download.
> Meanwhile, gnunet-stats shows ordinary cpu usage and uptimes in excess of
> an hour. So this definitely isn't a waiting-for-gnunetd-to-start-up issue.
>
> This didn't happen to me prior to veriosn 0.6.2 (unless gnunetd was, in
> fact, not running, which is not the case now). Has anyone else noticed
> this? Should I file a bug report? What's happening on line 666? Who let the
> devil into the requestmanager anyway?

Could you file this on mantis, maybe together with the startup output of 
gnunetd -d -L DEBUG to see what gnunetd is doing?  Oh, and the output of 
gnunet-stats would also probably be helpful.  Clearly the download-process is 
complaining about the other side not taking the requests, but the question 
is, what does gnunetd think about the download process.

Possible errors include:
* AFS protocol module not loaded
* gnunetd denies access (set of trusted IPs incorrect?)
* gnunetd had some startup problem (or is not yet done with it)
* actual bug :-)

What is new in 0.6.2 is that the connection to misbehaving clients is closed 
(instead of ignoring the bad request).  This is a good thing since it 
prevents clients from indefinitely waiting on a reply that will never come 
(if the message is not understood, gnunetd would not know how to reply, so 
the best reply is to close the connection -- the client then typically 
retries after a while).

Christian