Gnut Manual: F.A.Q. at MROB
Author: Robert Munafo

Gnut Manual: F.A.Q.

Next Previous Contents

5. F.A.Q.

5.1 Will gnut run on Slackware 4.0?

No. gnut requires glibc2.0, you need to upgrade to this before you can use it.

5.2 Does ggnut (the Gnome graphical-interface front end to gnut) work?

Yes -- Jon Arney has been releasing working versions of ggnut since May 2000. Jon and Robert Munafo are working on combining their work so that gnut and ggnut will once again be part of the same release -- but for now, visit Jon Arney's site if you want to use ggnut. Also, remember that gnut has an HTTP interface, so if you just don't like typing commands you can use your gnut through your web browser.

5.3 How do I change the port in gnut?

Starting with version 0.4.7, you can change the port in two ways: with the -p option on the command line:

`gnut -p 6346`

or by putting a command in your `.gnutrc` file:

`set local_port 6346`

5.4 Does gnut has feature xxx?

Look in this manual, read README, if you don't see it in either place, then the answer is no.

5.4.3 What are the "Virtual Private Network" (VPN) and other special addresses?

Certain IP addresses are only used behind firewalls or within institutional (corporate, educational, government, etc.) private networks. They are called VPN (Virtual Private Network) and APIPA (Automatic Private IP Addressing) addresses. The VPN addresses were originally defined in the Internet document RFC 1597 (later supplanted by RFC 1918); APIPA is most often seen being used by Windows 98 and Windows 2000 systems. Here are the VPN and APIPA ranges:

> 10.0.0.0 to 10.255.255.255 (type A)
> 172.16.0.0 to 172.31.255.255 (type B)
> 192.168.0.0 to 192.168.255.255 (type C)
> 169.254.0.0 to 169.254.255.255 (type P)

Sometimes, depending on the situation, the following addresses are either handled like the above "special" addresses, or are not available for use, or both:

> 208.0.0.0 to 215.255.255.255 (class F)
> 216.0.0.0 to 219.255.255.255 (class G ARIN, RIPE NCC, IANA reserved)
> 220.0.0.0 to 221.255.255.255 (class H)
> 222.0.0.0 to 223.255.255.255 (class K)
> 224.0.0.0 to 239.255.255.255 (class D multicast)
> 240.0.0.0 to 255.255.255.255 (class E reserved)

In addition, there are some ranges that are reserved for testing and other special uses, and can never be used as a normal IP address. These are:

> 0.0.0.0 to 0.255.255.255 (local broadcast)
> 127.0.0.0 to 127.255.255.255 (node loopback)
> 192.0.2.0 to 192.0.2.255 (TEST-NET)

5.4.4 Why do some uploads/downloads appear as "SEND PUSH" or "RCV PUSH" in the info c display?

Uploads and downloads to hosts at VPN addresses (see question 5.4.3) have to use something called a "push request" to establish a connection. This request is sent through the GnutellaNet network, and usually takes a few minutes to get started. If you are within a VPN, all of your uploads will happen by PUSH requests (unless they were requested by others within your institution's network).

5.5.A I'm behind a firewall, and gnut is showing host addresses behind other firewalls. That's not right, is it?
5.5.B I'm not behind a firewall, and gnut is showing host addresses behind firewalls. That's not right, is it?

The "behind firewall addresses" are the VPN addresses described in question 5.4.3 above. We'll refer to all other addresses as "type O". Starting with version 0.4.8, gnut filters addresses in the host list and search results lists to remove hosts that are definitely inaccessible, depending on gnut's local IP address. It cannot remove all inaccessible hosts if the local IP is behind a firewall. Here are the rules gnut uses:

If your address is | gnut can connect to (host list) | and can get files from (search results list)
type O | type O | any (O directly, A+B+C+P through push)
type A | type O (definitely) and A (maybe) | type O (definitely) and A (maybe)
type B | type O (definitely) and B (maybe) | type O (definitely) and B (maybe)
type C | type O (definitely) and C (maybe) | type O (definitely) and C (maybe)
type P | type O (definitely) and P (maybe) | type O (definitely) and P (maybe)

Thus, even if you are not behind a firewall, gnut must show all addresses in search results because files are accessible through push requests.

And even if you are behind a firewall, gnut must show addresses of other hosts whose addresses are of the same type, because they might also be behind your firewall. This is particularly important to users in very large institutions, such as universities. gnut does not test each address to see if it is actually accessible, because that would be very slow and would be a waste of network bandwidth.

5.6 Why does gnut launch 10 copies of itself, and why does it use so much memory?

If you are running Linux and use ps or top to look at the running processes on your machine, you will see many copies (usually about 3 plus the number of active connections, uploads and downloads), all with the same SIZE and RSS (virtual and resident memory) figures. These are actually threads (simultaneous concurrent execution states) running within a single copy of gnut. ps and top display them as separate processes because they are not thread-aware and because of the way the Linux kernel implements threads. Rest assured that they are not each taking up the amount of memory indicated. There is only a fairly low per-thread memory overhead used for the stack and processor state for context switches.

So if you type `ps u` and gnut appears 7 times each with a SIZE of 8400, then your gnut is currently using 8.4 megs of virtual memory.

That 8.4 megs (or whatever number you're seeing) grows as gnut runs, mainly because of the GUID and host lists. These are lists of Gnutella packets that have been seen, host IP addresses, and other things used to route packets in the Gnutella network. When you quit and restart gnut, the memory usage will go down, but it builds up again over time as the packets come in.

There is also a memory leak (bug that causes memory to be allocated and then not de-allocated, causing a buildup of wasted memory). This bug has been around since before version 0.3.29 and I have not been able to find it (yet). Any help would be appreciated.

5.7 Someone is downloading a file "nonsense.mp3" from me, but I have no such file on my computer. What's up?

When you use the info or info t command, gnut displays all transfers and transfer attempts, even those transfers that are not working. Furthermore, the "filename" displayed is the filename they asked for, and the length transferred and percent transferred correspond to the requested data range (which is nonzero if the request is for a resume-in-the-middle transfer). gnut displays this info even when the file is nonexistent because it is often useful to know what is being requested even if you don't have it.

Recently, a spammer on the Gnutella network has been issuing requests for downloads of nonexistent files such as "nonsense.mp3", then letting the connection hang (without acknowledging the error or closing) in an attempt to impede the functionality of your node and other nodes on the network. That's why you see that bogus file transfer.

5.8 I did a search, and I know I'm sharing files that match this search. Why didn't the search show the files I'm sharing?

gnut does not search your own files when you do a search. Searches are for finding things out on the network, not things you already have.

5.9 How can I get the most results from my searches?

- Increase min_connections.
- Set autokill_thres to 10 (see question 5.10 for an explanation).
- Be patient -- it takes about 5 minutes for all search results to arrive.

For more abut the reasons behind this, read section 6.3.

5.10 Why do connections get closed so often?

Some connections close because the other end closed it (usually from the user quitting their Gnutella client) but gnut also implements something called autokill.

Once every 16/min_connections minutes (for example, once per 2 minutes if min_connections is 8), gnut looks through the connection list for the connection with the highest dropped-packets ratio. If its ratio is greater than autokill_thres percent (default 10), the connection is closed and a new connection initated to a randomly-chosen host.

The effect of this action is to spread the connections as far from each other as possible in the Gnutella network. A connection with a high dropped-packets ratio is connected to a node that is "close" (in terms of hop count) to one or more other nodes in the connection list, and furthermore it has a slower propagation delay (inasmuch as the packets are arriving over other links first). Therefore, closing it will not lose much, and opening a new connection to a randomly-selected host elsewhere on the network stands a good chance of reaching a whole new bunch of hosts.

Because the network is always changing, the connection list has to be continually adjusted to maintain maximum coverage. After about 30 minutes this algorithm gets close to the theoretical limit of reaching the greatest possible number of hosts without increasing the TTL or min_connections.

If you don't want gnut to autokill, disable it either by setting autokill_thres to 0 or min_connections to less than 5.

5.11 Why can't I get eval scripts to read gnut's output?

There are three ways to run a shell command (such as a script) within gnut:

      gnut> ! perl script1
      gnut> `perl script1`
      gnut> eval perl script1

All three methods allow you (the user at the keyboard) to interact with the invoked program. In fact, the command takes over -- the gnut command-line will not respond until the command is done.

This was done so that you could interact with a command, like in this example:

      gnut> ! vi tempfile

Your typing on the keyboard goes into the program (vi in this case) and the stuff printed by vi shows up on the screen. When vi is done, you're back in gnut.

In the case of back-quote and eval, gnut reads the stuff printed out and does something with it (executes it as gnut commands). It would seem to make sense to feed gnut's output into the running program so that the program and gnut could have a back-and-forth ongoing conversation.

Unfortunately, this leads to deadlock problems. One problem is starvation, which happens when both processes are waiting for input but neither is supplying anything to the other. Another is buffer overrun, when both programs output so much that the other cannot keep up, until the buffers get full. In both cases, both programs freeze.

If you want to create a script that interacts with gnut, you will have to write your script in expect, or in another language using an expect library, and have your script launch gnut itself and supply all the commands to gnut.

5.12 I cannot get gnut to connect to other hosts. I think it's because of my firewall or my dialin access configuration. How do I fix this?

gnut establishes all of its connections via the standard kernel `socket(2)`, `connect(2)`, `setsockopt(2)` and `bind(2)` calls. For incoming connections it binds to the port specified in your `.gnutrc` local_port configuration variable, and for outgoing connections it connects to the actual IP address and port, for example `12.34.56.78:6346`. gnut does not pay attention to environment variables like telnet_proxy, nor does it attempt to open all its outgoing connections through an intermediate protocol, unless that protocol is automatically provided by the kernel in response to the standard functions just listed. The code that implements this is in `gnut_net.c`.

Therefore, to run gnut (or just about any other program that uses TCP/IP in the standard way), your operating system must be configured in such a way that the standard kernel calls accomplish the correct result without any need for the program to treat your system as a special case. From the program's point of view, your system must appear to have a real Internet connection.

5.13 A download failed after 47 bytes leaving a tiny text file containing an error message like 'server busy'. Please fix this!

This problem is actually caused by a bug in the program at the other end (the server that is supplying the file). When you try to download the file it sends an error message rather than just closing the connection. This is supported by the HTTP transfer protocol but not by the Gnutella protocol specification, and as a result there is no way a program (like gnut) can distinguish that the data sent is part of the "real" data for the requested file or an error message.

However, gnut does contain a partial fix to this problem. If you attempt the download again, and if a previous partially-transferred file already exists, and if that partial file is less than 512 bytes long, then gnut ignores those bytes and starts the download over from the beginning. That means that if the transfer works the second time, it will not have those 47 bytes of error-message text at the beginning.

Next Previous Contents

WWW: http://www.mrob.com/
EMail: mrob at mrob com (If you aren't a spambot you can rewrite this yourself)
Send junk mail to: rpm@mrob.com
© 1996-2000 Robert P. Munafo. 3