From 74f235cd2e3fa3a27463e7afd1a34e1d5dbe5688 Mon Sep 17 00:00:00 2001 From: Arvid Norberg Date: Wed, 11 Nov 2009 07:03:50 +0000 Subject: [PATCH] rebuilt html --- docs/building.html | 39 +++++++++++------------- docs/features.html | 41 +++++++++++++++++++------ docs/make_torrent.html | 69 +++++++++++++++++++++++++++++++----------- docs/manual.html | 21 ++++++++----- 4 files changed, 113 insertions(+), 57 deletions(-) diff --git a/docs/building.html b/docs/building.html index f17bcb223..57c030acb 100644 --- a/docs/building.html +++ b/docs/building.html @@ -328,18 +328,20 @@ sent to and received from UPnP devices. -openssl +encryption @@ -639,16 +641,6 @@ UTF-8 strings in pathnames are converted into UTF-16 before they are passed to the file operations. -LITTLE_ENDIAN -This will use the little endian version of the -sha-1 code. If defined on a big-endian system -the sha-1 hashes will be incorrect and fail. -If it is not defined and __BIG_ENDIAN__ -isn't defined either (it is defined by Apple's -GCC) both little-endian and big-endian versions -will be built and the correct code will be -chosen at run-time. - TORRENT_DISABLE_POOL_ALLOCATOR Disables use of boost::pool<>. @@ -681,10 +673,13 @@ protocol traffic. TORRENT_DISABLE_ENCRYPTION This will disable any encryption support and -the openssl dependency that comes with it. +the dependencies of a crypto library. Encryption support is the peer connection encrypted supported by clients such as -uTorrent, Azureus and KTorrent. +uTorrent, Azureus and KTorrent. +If this is not defined, either +TORRENT_USE_OPENSSL or +TORRENT_USE_GCRYPT must be defined. _UNICODE On windows, this will cause the file IO diff --git a/docs/features.html b/docs/features.html index daa9e4116..026748c13 100644 --- a/docs/features.html +++ b/docs/features.html @@ -53,14 +53,15 @@
  • highlighted features
  • -
  • portability
  • +
  • portability
  • @@ -133,9 +134,6 @@ download speed is high enough from that particular peer.
  • supports gzipped tracker-responses
  • can limit the upload and download bandwidth usage and the maximum number of unchoked peers
  • -
  • implements fair trade. User settable trade-ratio, must at least be 1:1, -but one can choose to trade 1 for 2 or any other ratio that isn't unfair -to the other party.
  • possibility to limit the number of connections.
  • delays have messages if there's no other outgoing traffic to the peer, and doesn't send have messages to peers that already has the piece. This saves @@ -143,8 +141,12 @@ bandwidth.
  • selective downloading. The ability to select which parts of a torrent you want to download.
  • ip filter to disallow ip addresses and ip ranges from connecting and -being connected
  • +being connected.
  • NAT-PMP and UPnP support (automatic port mapping on routers that supports it)
  • +
  • implements automatic upload slots, to optimize download rate without spreading +upload capacity too thin. The number of upload slots is adjusted based on the +peers' download capacity to work even for connections that are orders of +magnitude faster than others.
  • @@ -194,6 +196,25 @@ better with piece sizes.

    algorithm. It clearly shows an increased utilization, which means higher read hit rates or smaller caches with maintained hit rate.

    +
    +

    high performance disk subsystem

    +

    In some circumstances, the disk cache may not suffice to provide maximum performance. +One such example is high performance seeding, to a large number of peers, over a fast +up-link. In such a case, the amount of RAM may simply not be enough to cache disk +reads. When there's not enough RAM to cache disk reads, the disk throughput would +typically degrade to perform as poorly as with no cache at all, with the majority +of the time spent waiting for the disk head to seek.

    +

    To solve this problem, libtorrent sorts read requests by their physical offset on the +disk. They are processed by having the disk read head sweep back and forth over the drive.

    +

    This makes libtorrent very suitable for large scale, high-throughput seeding.

    +disk_access_no_elevator.png +disk_access_elevator.png +

    These plots illustrates the physical disk offset for reads over time. The left plot +is of a run where disk operation re-ordering is turned off and the righ is when it's +turned on. The right one has a relatively smooth sine wave shape whereas the left +one is more random and involves much longer seeks back and forth over the disk.

    +

    True physical disk offset queries are only supported on newer linux kernels and Mac OS X.

    +

    network buffers

    On CPUs with small L2 caches, copying memory can be expensive operations. It is important diff --git a/docs/make_torrent.html b/docs/make_torrent.html index 52fb6c586..3ac9a7945 100644 --- a/docs/make_torrent.html +++ b/docs/make_torrent.html @@ -42,24 +42,25 @@

    +
    +

    add_file

    +
    +
    +void add_file(file_entry const& e);
    +void add_file(fs::path const& p, size_type size);
    +
    +
    +

    Adds a file to the file storage. If more files than one are added, +certain restrictions to their paths apply. In a multi-file file +storage (torrent), all files must share the same root directory.

    +

    That is, the first path element of all files must be the same. +This shared path element is also set to the name of the torrent. It +can be changed by calling set_name.

    +

    The built in functions to traverse a directory to add files will +make sure this requirement is fulfilled.

    +

    create_torrent

    @@ -268,7 +286,7 @@ struct create_torrent bool priv() const; }; -
    +

    create_torrent()

    @@ -315,6 +333,23 @@ entry generate() const;
     generate the flat file, use the bencode() function.

    It may be useful to add custom entries to the torrent file before bencoding it and saving it to disk.

    +

    If anything goes wrong during torrent generation, this function will return +an empty entry structure. You can test for this condition by querying the +type of the entry:

    +
    +file_storage fs;
    +// add file ...
    +create_torrent t(fs);
    +// add trackers and piece hashes ...
    +e = t.generate();
    +
    +if (e.type() == entry::undefined_t)
    +{
    +        // something went wrong
    +}
    +
    +

    For instance, you cannot generate a torrent with 0 files in it. If you don't add +any files to the file_storage, torrent generation will fail.

    set_comment()

    diff --git a/docs/manual.html b/docs/manual.html index 28181dcb6..b06321690 100644 --- a/docs/manual.html +++ b/docs/manual.html @@ -930,7 +930,7 @@ struct session_status int unchoke_counter; int dht_nodes; - int dht_cache_nodes; + int dht_node_cache; int dht_torrents; int dht_global_nodes; std::vector<dht_lookup> active_requests; @@ -970,11 +970,11 @@ be assigned a torrent yet.

    seconds until the next optimistic unchoke change and the start of the next unchoke interval. These numbers may be reset prematurely if a peer that is unchoked disconnects or becomes notinterested.

    -

    dht_nodes, dht_cache_nodes and dht_torrents are only available when +

    dht_nodes, dht_node_cache and dht_torrents are only available when built with DHT support. They are all set to 0 if the DHT isn't running. When the DHT is running, dht_nodes is set to the number of nodes in the routing table. This number only includes active nodes, not cache nodes. The -dht_cache_nodes is set to the number of nodes in the node cache. These nodes +dht_node_cache is set to the number of nodes in the node cache. These nodes are used to replace the regular nodes in the routing table in case any of them becomes unresponsive.

    dht_torrents are the number of torrents tracked by the DHT at the moment.

    @@ -2716,14 +2716,14 @@ while (num_resume_data > 0) std::auto_ptr<alert> holder = ses.pop_alert(); - if (dynamic_cast<save_resume_data_failed_alert const*>(a)) + if (alert_cast<save_resume_data_failed_alert>(a)) { process_alert(a); --num_resume_data; continue; } - save_resume_data_alert const* rd = dynamic_cast<save_resume_data_alert const*>(a); + save_resume_data_alert const* rd = alert_cast<save_resume_data_alert>(a); if (rd == 0) { process_alert(a); @@ -4566,9 +4566,14 @@ or upload rate.

    Every alert belongs to one or more category. There is a small cost involved in posting alerts. Only alerts that belong to an enabled category are posted. Setting the alert bitmask to 0 will disable all alerts

    -

    When you get an alert, you can use typeid() or dynamic_cast<> to get more detailed -information on exactly which type it is. i.e. what kind of error it is. You can also use a -dispatcher mechanism that's available in libtorrent.

    +

    When you get an alert, you can use alert_cast<> to attempt to cast the pointer to a +more specific alert type, to be queried for more information about the alert. alert_cast +has the followinf signature:

    +
    +template <T> T* alert_cast(alert* a);
    +template <T> T const* alert_cast(alert const* a);
    +
    +

    You can also use a dispatcher mechanism that's available in libtorrent.

    All alert types are defined in the <libtorrent/alert_types.hpp> header file.

    The alert class is the base class that specific messages are derived from. This is its synopsis: