Gnutizen has moved to it's own site on SourceForge!

2004, 04 06

I updated CVS yesterday for the first time in months yesterday. I may have fixed a (memory) segmentation violation. I also made qhmax a variable so it would only have to be define in one place (OK, two places). I made com_info() more verbose. The download progress report seemed to be off when there were multiple downloads so I fixed that as well.

What next for Gnutizen?

#1 would be to remove bugs. What are those?
- on a FreeBSD when starting it fails from a broken pipe often
- On FreeBSD after:
70 minutes, 199 queryhits and 150000+ cached queries
40 minutes, 199 queryhits and 75000+ cached queries
The message "this should not happen in command_loop...in gogogo, this should not happen" appears and the program halts
- On a FreeBSD: threads start dying - but the process keeps running with the main thread plus 1-4 threads. The main process seems to spend most of it's time polling, and when not that then doing activities on the "live" threads. Finds will shows error if done, for example you'll get "find test...test...ERROR sending query".
- On an OpenBSD: The cache file will be said to have run out even if it didn't. This may be because Gnutizen is using way too much file I/O when more hosts should be in memory. This will have to be addressed at some point.

#2 would be what is needed to stay connected to the network

- read, parse and cache X-Try: headers (if I can use them)
- implement QRP to connect to (and be) an Ultrapeer

#3 would be new features

- allow incoming connections to a port
- share files
- HUGE to do sha1 and tigertree hashing
- multiple downloads of same hashed source
- different user interfaces (Windows, command line, UNIX graphical)

In terms of my connecting to hosts with vanilla Gnutella 0.6 headers, I seem to be rejected from the latest versions of some popular programs like LimeWire with "GNUTELLA/0.6 503 Service unavailable" and then often an "X-Try-Ultrapeers:" or the like. This is what happens most often.

I also get "GNUTELLA/0.6 500 Invalid Handshake" once in a while, both times I've seen from a BearShare 4.3.5.4 servent. I'm going to have to implement a read, parse and cache of X-Try: headers (and eventually implement QRP).

I'm currently fine connecting to: Bearshare (2.4.4 - 4.0.5), Mutella (0.4 - 0.4.1), Gnucleus (1.8.4.0), Morpheus (2.0.1.7 - 2.0.2.2), gtk-gnutella (0.90-0.93) and Xolox (1.5.7.1)

Off a fresh batch of good hosts I'm guessing 9% of sent pongs are good hosts, good meaning I can connect and receive pongs and/or queries. Some of the sent hosts do the modern Limewire "GNUTELLA/0.6 500 Invalid Handshake", thus making it a bad host currently for me. I have to start reading X-Try's.

I should mod it so it can compile with different Windows IDE's as well.

The two routines called the most are readandparse() and interpret_query(). About half as much, main_loop() is called.