I guess it's useful to describe some of the changes to Gtk-Gnutella
which have been applied during the last few days and weeks. Some of
these concern only the Gtk+ 2.x front-end and others may still be
incomplete or slightly buggy. I also post this to the users' list
because you might be interested in Gtk-Gnutella from SVN as well or
just be curious what will be available in the next release of
The gtk-gnutella executable supports a couple of command-line options
$ gtk-gnutella --help
to see a list of all supported options. There might be implicitely
more which are only understood and used by GLib or Gtk+ e.g.,
--g-fatal-warnings. Therefore unknown command-line options are
The option "--version" causes gtk-gnutella to print its user-agent
string which also holds the version information and then terminate.
The option "--ping" allows you check whether gtk-gnutella is currently
running. For example, you could use the following to suppress startups
warnings when you (accidently) try to start gtk-gnutella twice as from
a cron job or a window manager menu:
gtk-gnutella --ping || gtk-gnutella
If you use the option "--daemonize", gtk-gnutella becomes a daemon.
That means it detaches from the terminal (if started from one) and
fork itself into the background. It also changes it working directory
to the root directory i.e., "/" so that it doesn't block a mount point
for example. This is mainly meant for Topless mode but you can also
use it if the Gtk+ GUI is enabled. For example, if you do not start
gtk-gnutella from a terminal but from a window manager menu, there's
little reason to not daemonize gtk-gnutella. Thus you might want to
add the --daemonize option in this case. As daemon all output which is
normally send to the standard output and standard error output
(usually your terminal or a common log file such as
~/.xsession-errors), is sent to /dev/null. Thus if you still want to
see log output, use the next two options.
The options "--log_stderr" and "--log_stdout" allow you to log
everything which is written to stderr respectively stdout to some
files. A typical use would look like this:
gtk-gnutella --daemonize \
--log_stderr ~/logs/gtkg.stderr \
Redirecting these log messages also works without --daemonize. Of
course, log files can become large and you might want to archive them.
Therefore, you can sent gtk-gnutella a SIGHUP signal. gtk-gnutella
will catch the signal and reopen these log files.
Finally, gtk-gnutella supports --geometry as well. This is useful to
force the main window of the GUI to a certain location on your screen
and/or give it certain dimensions. For example, the following would
position the window in the lower left corner with a width of 800
pixels and a height of 600 pixels:
gtk-gnutella --geometry 800x600-0-0
Note that none of this can be guaranteed, your window manager has the
last word on this. This option is a traditional command-line switch
supported by most X11 applications.
gtk-gnutella also has a command-line option "--shell" now which will
connect to the current gtk-gnutella process over a local unix domain
socket. This socket is located at "$GTK_GNUTELLA_DIR/ipc/socket", thus
normally "~/.gtk-gnutella/ipc/socket". The socket is only accessible
by the user running gtk-gnutella which is enforced by filesystem
permissions. The socket is in a dedicated directory because apparently
not all systems honor the access permissions on sockets as seen
through the filesystem.
You can disable this feature by setting the property
"enable_local_socket" to FALSE. It is recommendable to use this local
socket whenever possible instead of the TCP socket to access the shell
interface remotely. The reason is that the authentication token is
passed non-encrypted over the network and everyone who can sniff the
network is able to connect to the remote shell. This may not matter
over the loopback interface or a LAN, but it's a bad idea to use this
over the Internet.
Thus, ssh into your box (if it's not local) and use "gtk-gnutella
--shell" to access its shell. The property "enable_shell" (this should
have been named "enable_remote_shell" does not affect this local
socket. You can always initiate a shell session on the local socket
by typing "HELO<enter>" after connecting. In contrast to the remote
shell, the local shell does not use any authentication token.=20
Note that the local sockets behaves exactly like the TCP socket
otherwise i.e., you can actually upload and download files through it.
See doc/other/remote-shell.txt for further documentation
regarding the shell interface.
In case you wonder what's it good for anyway: It is, for example,
possible to initiate a search or even download through this
interface by passing a magnet. Consider the following simple
search add $magnet
} | gtk-gnutella --shell
Note that this script is a bit naive i.e., you have to make sure
that the magnet link (the first parameter passed to the script)
does not contain any line-breaks. Otherwise, it is possible to
inject commands. Therefore, you shouldn't use it as-is without
making sure that the magnet is safe.
For this reason, I'll also add a dedicated command-line option
(maybe --magnet) that will properly escape its argument and
then send these commands over the shell, so that you don't have
to worry about this.
Anyway, the shell has also a "shutdown" command now - not to be
confused with "quit" - which initiates a shutdown of gtk-gnutella.
Mainly useful for Topless but works with the GUI enabled just as well.
This is cleaner than using "pkill gtk-gnutella".
Another new shell command is "nodes" which displays a list of all
connected Gnutella nodes. The output can be quite long, so you might
want to use "screen" or at least "tee" when using the shell.
The Full Disk Problem
Gtk-Gnutella does now stop downloading if it cannot flush its download
buffers. I've re-added the "Freeze Queue" button to the download
interface in the Gtk+ 2.x front-end. If your disk fills up whilst
downloading, you'll have to press this button to thaw the queue after
making some space on the affected partition. Before, Gtk-Gnutella
would keep trying to download and waste the bandwidth during that time
because it had no other choice than discarding the unflushed
Colouring of Search Results
Search results are now displayed with distinct colours under certain
Result is considered spam (or another item in the same set) -> red
Result from hostile host -> purple
Result was never requested -> orange/brown
File is being downloaded or queued -> green
File has been downloaded before or is shared -> gray
This information is also visible from additional columns. These are
disabled by default though as they take a good amount of screen
space. See "Prerences->Configure columns" in the *context* menu.
By default spam, hostile results and results without a SHA-1 are
discarded (i.e., never displayed). Click on "Show settings" and
disable the relevant options. Mind you, there is *a lot* of spam.
In order to use the spam filter, do the following.
Add a symlink from the SVN repository (assumed to be located in
/svn/gtk-gnutella in the examples) of Gtk-Gnutella to your private
$ ln -s /svn/gtk-gnutella/extra_files/spam.txt ~/.gtk-gnutella/
The same can be done for the hostiles list:
$ ln -s /svn/gtk-gnutella/extra_files/hostiles.txt ~/.gtk-gnutella/
Once a while - maybe weekly - you can update these files from SVN:
svn up /svn/gtk-gnutella/extra_files
Gtk-Gnutella will automagically reload this files, so you don't
have to restart it to make the changes effective. This is especially
recommended for Ultrapeers because it will keep the Gnutella
network a bit cleaner, safe a good amount of traffic and also
improve the quality of search results. As spam.txt is quite big,
svn is one of the most efficient ways to keep it up-to-date. Do
not periodically download the complete file! If there's demand,
this file can be mirrored elsewhere.
Less For More
When downloading a single file from several sources at the same time,
there is only 1 (or 2 under some circumstances) open file descriptor
for the file. Previously, Gtk-Gnutella naively opened the file for
each download. Now all downloads for a file share the same file
descriptor. Furthermore, with partial file sharing this descriptor is
also shared with upload transfers. Thus, the amount of open file
descriptors is heavily reduced under those circumstances and hitting
the file descriptor limit is less likely now.