[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Help-gnunet] gnunet-download faulty server connection
From: |
Christian Grothoff |
Subject: |
Re: [Help-gnunet] gnunet-download faulty server connection |
Date: |
Thu, 6 May 2004 16:12:45 -0500 |
User-agent: |
KMail/1.6.2 |
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