159 lines
6.6 KiB
Text
159 lines
6.6 KiB
Text
=head1 About ncdc
|
|
|
|
|
|
=head2 What about other text-mode clients?
|
|
|
|
L<microdc2|http://corsair626.no-ip.org/microdc/> - A rather nice client, yet
|
|
not exactly there. It's limited to connecting to a single hub, hasn't been
|
|
updated since 2006, and the readline interface is slightly awkward to use.
|
|
|
|
L<nanodc|http://sourceforge.net/projects/nanodc/> - Can't comment much on this,
|
|
except maybe that rocket science is perhaps easier than getting nanodc to
|
|
compile.
|
|
|
|
LDCC - Uses DCTC as backend and an interface based on TurboVision. All
|
|
mentioned projects are dead: neither LDCC, DCTC nor TurboVision are seeing any
|
|
recent development.
|
|
|
|
L<ShakesPeer|http://shakespeer.bzero.se/> - Appears to have a commandline
|
|
interface as well. I haven't personally tried it, but have not heard many
|
|
positive things about it. Has not seen any recent development, either.
|
|
|
|
|
|
=head2 Why did you start from scratch? Why not use the DC++ core?
|
|
|
|
There are several reasons why I chose not to use code from existing projects,
|
|
but the two most important reasons are the following: 1) I am a control freak,
|
|
and 2) personal preferences.
|
|
|
|
B<Control freak:> I have no idea how to create an interface to a protocol if I
|
|
don't know the overall design and all the tiny details of the actual protocol
|
|
I'm working with. And what's a better way to get used to a protocol than by
|
|
writing everything yourself? Then there's some other advantages to
|
|
reimplementing everything: I get to choose the library dependencies and the
|
|
memory/CPU efficiency trade-offs, and I am not limited by an existing
|
|
implementation that needs quite a few modifications to achieve what I want.
|
|
Most of the "special features not commonly found in other clients" mentioned on
|
|
the L<homepage|http://dev.yorhel.nl/ncdc> are a direct result of this.
|
|
|
|
B<Personal preferences:> These are simple: I rather dislike C++ and working
|
|
with other people's code. Working with other people's C++ code isn't exactly
|
|
something I wish to spend my free time on.
|
|
|
|
|
|
=head2 What protocol features does ncdc support?
|
|
|
|
For ADC: BASE, RF, TIGR, BZIP, ADCS, KEYP and SUDP.
|
|
|
|
For NMDC: NoGetINFO, NoHello, UserIP2, MiniSlots, XmlBZList, ADCGet, TTHL and TTHF.
|
|
|
|
ncdc also supports TLS-enabled connections for both hub connections and
|
|
client-to-client connections on both ADC and NMDC protocols. Note that ncdc
|
|
does not support some of the older NMDC protocol features, like $Get,
|
|
$GetZBlock, $CHUNK, $Cancel or non-XML file lists. I am not aware of an other
|
|
up-to-date client that still uses any of these features.
|
|
|
|
|
|
|
|
|
|
=head1 Troubleshooting
|
|
|
|
=head2 This "Generating certificates..." is taking ages!
|
|
|
|
When starting up ncdc for the first time, it will need to generate a TLS
|
|
certificate. If you're on Linux, older versions of GnuTLS may use
|
|
C</dev/random> to obtain random bytes. Unfortunately, this can be horribly
|
|
slow, and in extreme cases it may take several hours before the certificate has
|
|
been generated. GnuTLS does not provide a way to use a faster but less secure
|
|
alternative, so here are some tips to speed it up or cheat a little.
|
|
|
|
B<Speed it up:> If you're on a desktop, the general advise is to do something
|
|
else on the background so that Linux can generate more data. For example, move
|
|
your mouse around a bit, go do some web surfing or play a game. Any activity
|
|
might help. If you're on a server, you could try transferring some large data
|
|
over the network.
|
|
|
|
B<Cheat:> If you have root access, you can probably trick GnuTLS by temporarily
|
|
replacing C</dev/random> with something else. For example, run C<mv /dev/random
|
|
/dev/random.old && ln /dev/urandom /dev/random> as root, then start ncdc as you
|
|
normally would, let it generate the certificates, and then restore your
|
|
modifications with C<mv /dev/random.old /dev/random>.
|
|
|
|
|
|
=head2 Ncdc crashes a lot!
|
|
|
|
Since version 1.13, the following crash is still possible:
|
|
|
|
=over
|
|
|
|
=item * You're using an old GnuTLS version (< 3.0, you can check this with
|
|
C<ncdu --version>), and you have tls_policy enabled. To fix this, upgrade
|
|
GnuTLS or use C</set tls_policy disabled>. (Bug
|
|
L<#11|http://dev.yorhel.nl/ncdc/bug/11>).
|
|
|
|
=back
|
|
|
|
If you're running an older version of ncdc, please upgrade! If your ncdc is up
|
|
to date and you still have a crash not described here, please report a bug.
|
|
|
|
|
|
=head2 Ncdc uses too much disk space!
|
|
|
|
First, look where this disk space goes to (hint: use
|
|
L<ncdu|http://dev.yorhel.nl/ncdu>). If it's the log files: you can safely
|
|
delete or rotate them (see next question).
|
|
|
|
The I<db.sqlite3> file can also grow quite large in certain situations. If you
|
|
modify or rename a lot of files in your share and ncdc re-hashes them, the old
|
|
hash data associated with the files is not removed from the database, resulting
|
|
in wasted disk space. The C</gc> command in ncdc can be used to clean up this
|
|
unused data. Be warned, however, that this command needs roughly twice the size
|
|
of the old db.sqlite3 file for temporary storage, so make sure you have enough
|
|
space available. (Note that this behaviour is not specific to ncdc, most other
|
|
DC clients do the same.)
|
|
|
|
|
|
=head2 Why doesn't ncdc rotate log files automatically?
|
|
|
|
Because you can easily do that yourself. You can either use logrotate or a
|
|
simple script that runs from a cron. For an example of the latter option,
|
|
L<this is the script I use|http://p.blicky.net/s7132>, which is run as a
|
|
monthly cron job.
|
|
|
|
|
|
|
|
=head1 Can ncdc...
|
|
|
|
|
|
=head2 Can ncdc use the hash data or configuration from an existing DC++ installation?
|
|
|
|
No, ncdc uses its own configuration and hash storage directory. However, on
|
|
popular demand I could write a conversion utility to transfer the hash data
|
|
from other clients to ncdc's format. (Contrary to my expectations, there hasn't
|
|
been much interest in such a tool ever since I wrote this FAQ entry a year ago.
|
|
So I guess this isn't really a FAQ).
|
|
|
|
|
|
=head2 Can ncdc run in the background / as a daemon?
|
|
|
|
As with most ncurses applications: no. At least, it does not have this
|
|
functionality built-in. Ncdc is designed to be used in combination with a
|
|
separate terminal multiplexer or detach utility to handle this. Have a look at
|
|
L<GNU screen|http://www.gnu.org/s/screen/>,
|
|
L<tmux|http://tmux.sourceforge.net/> or L<dtach|http://dtach.sourceforge.net/>.
|
|
|
|
|
|
=head2 Does ncdc support UPnP?
|
|
|
|
Not natively. However, it is possible to use L<this
|
|
script|http://www.howtoforge.com/administrating-your-gateway-device-via-upnp>
|
|
and manually keep a port open using a cron job. I have no experience with this
|
|
myself, though. I just run ncdc directly on my router. :-)
|
|
|
|
|
|
=head2 Are there any programs available for analyzing the transfers.log file?
|
|
|
|
Nothing like that is included in the release yet, but there is a simple Perl
|
|
script available: L<ncdc-transfer-stats|http://p.blicky.net/agolr>, and a short
|
|
Go program: L<ncdc-share-report|http://p.blicky.net/h25z8>.
|
|
|