diff --git a/docs/index.html b/docs/index.html index 9c4fd6128..f1aecc5b1 100755 --- a/docs/index.html +++ b/docs/index.html @@ -4,13 +4,12 @@
-libtorrent is a C++ library that aims to be a good alternative to all the -other bittorrent implementations around. It is a +other bittorrent implementations around. It is a library and not a full featured client, although it comes with a working example client.
The main goals of libtorrent are:
diff --git a/docs/index.rst b/docs/index.rst index 76949fe2d..95f80ef4e 100755 --- a/docs/index.rst +++ b/docs/index.rst @@ -1,8 +1,8 @@ -========== -libtorrent -========== +.. image:: logo.png +.. class:: menu + =================== ============== ============== =========== =============== `sourceforge page`_ documentation_ `report bugs`_ screenshot_ `mailing list`_ =================== ============== ============== =========== =============== @@ -14,12 +14,10 @@ libtorrent .. _mailing list: http://lists.sourceforge.net/lists/listinfo/libtorrent-discuss libtorrent is a C++ library that aims to be a good alternative to all the -`other bittorrent implementations`__ around. It is a +other bittorrent implementations around. It is a library and not a full featured client, although it comes with a working example client. -__ links.html - The main goals of libtorrent are: * to be cpu efficient diff --git a/docs/manual.html b/docs/manual.html index 41f5d0fe5..83fae92e4 100755 --- a/docs/manual.html +++ b/docs/manual.html @@ -13,63 +13,63 @@libtorrent is a C++ library that aims to be a good alternative to all the -other bittorrent implementations around. It is a +other bittorrent implementations around. It is a library and not a full featured client, although it comes with a working example client.
The main goals of libtorrent are:
@@ -132,7 +132,7 @@ boost.filesystem, boost.date_time and various other boost libraries as well as zlibtorrent is released under the BSD-license.
Whwn building in release mode you need to define NDEBUG in order to avoid all asserts and invariant checks within libtorrent. Developer studio does this by default.
@@ -167,7 +167,7 @@ loop scope" and "treat wchar_t as built-in type" to Yes.TODO: more detailed build instructions.
The interface of libtorrent consists of a few classes. The main class is the session, it contains the main loop that serves all torrents.
The basic usage is as follows:
@@ -194,7 +194,7 @@ the session, it contains the mEach class and function is described in this manual.
The session class has the following synopsis:
class session: public boost::noncopyable @@ -255,7 +255,7 @@ change in the future to give more control of the listen-port.For information about the pop_alert() function, see alerts.
The torrent files are bencoded. There are two functions in libtorrent that can encode and decode bencoded data. They are:
@@ -294,7 +294,7 @@ entry e = bdecode(buf, buf + data_size); it will throw invalid_encoding.
The entry class represents one node in a bencoded hierarchy. It works as a variant type, it can be either a list, a dictionary (std::map), an integer or a string. This is its synopsis:
@@ -375,7 +375,7 @@ if (i != dict.end()) exists.The torrent_info has the following synopsis:
class torrent_info @@ -462,7 +462,7 @@ object, representing the time when this torrent file was created. If there's no in the torrent file, this will return a date of january 1:st 1970.
You will usually have to store your torrent handles somewhere, since it's the object through which you retrieve infromation about the torrent and aborts the torrent. Its declaration looks like this:
@@ -520,7 +520,7 @@ torrent. If you set this to -1, there will be no limit. is suitable for being bencoded. For more information about how fast-resume works, see fast resume. It may throw invalid_handle if the torrent handle is invalid.status() will return a structure with information about the status of this torrent. If the torrent_handle is invalid, it will throw invalid_handle exception. It contains the following fields:
@@ -609,7 +609,7 @@ all peers. The rates are given as the number of bytes per second.total_done is the total number of bytes of the file(s) that we have.
get_download_queue() takes a non-const reference to a vector which it will fill information about pieces that are partially downloaded or not downloaded at all but partially requested. The entry in the vector (partial_piece_info) looks like this:
@@ -641,7 +641,7 @@ When a piece fails a hash verification, single blocks may be redownloaded to see may pass then.get_peer_info() takes a reference to a vector that will be cleared and filled with one entry for each peer connected to this torrent, given the handle is valid. If the torrent_handle is invalid, it will throw invalid_handle exception. Each entry in @@ -750,19 +750,19 @@ of bytes of this block we have received from the peer, and < the total number of bytes in this block.
Returns a const reference to the torrent_info object associated with this torrent. This reference is valid as long as the torrent_handle is valid, no longer. If the torrent_handle is invalid, invalid_handle exception will be thrown.
Returns true if this handle refers to a valid torrent and false if it hasn't been initialized or if the torrent it refers to has been aborted.
The address class represents a name of a network endpoint (usually referred to as IP-address) and a port number. This is the same thing as a sockaddr_in would contain. Its declaration looks like this:
@@ -795,7 +795,7 @@ while it does the DNS lookup, it returns a string that points to the address repip() will return the 32-bit ip-address as an integer. port() returns the port number.
You have some control over tracker requests through the http_settings object. You create it and fill it with your settings and the use session::set_http_settings() to apply them. You have control over proxy and authorization settings and also the user-agent @@ -835,7 +835,7 @@ uncompressed (given your limit is lower than 2 megs). Default limit is 1 megabyte.
Both the peer_id and sha1_hash types are typedefs of the class big_number. It represents 20 bytes of data. Its synopsis follows:
@@ -856,7 +856,7 @@ public:The iterators gives you access to individual bytes.
This class creates sha1-hashes. Its declaration looks like this:
class hasher @@ -880,7 +880,7 @@ call reset() to reinitialize i For more info, see src/sha1.c.
The fingerprint class represents information about a client and its version. It is used to encode this information into the client's peer id.
This is the class declaration:
@@ -931,7 +931,7 @@ sure not to clash with anybody else. Here are some taken id's: version of your client. All these numbers must be within the range [0, 9].to_string() will generate the actual string put in the peer-id, and return it.
There's a function, in the header libtorrent/identify_client.hpp, that can be used to extract a string describing a client version from its peer-id. It has the following declaration:
@@ -942,7 +942,7 @@ std::string identify_client(const peer_id& id);The pop_alert() function on session is the interface for retrieving alerts, warnings, messages and errors from libtorrent. If there hasn't occured any errors (matching your severity level) pop_alert() will @@ -1023,7 +1023,7 @@ have a severity leve that can be used to sort them or present them to the user in different ways.
The specific alerts, that all derives from alert, are:
This alert is generated on tracker time outs, premature disconnects, invalid response or a HTTP response other than "200 OK". From the alert you can get the handle to the torrent the tracker belongs to. This alert is generated as severity level warning.
@@ -1038,7 +1038,7 @@ struct tracker_alert: alertThis alert is generated when a finished piece fails its hash check. You can get the handle to the torrent which got the failed piece and the index of the piece itself from the alert. This alert is generated as severity level info.
@@ -1058,7 +1058,7 @@ struct hash_failed_alert: alertThis alert is generated when a peer sends invalid data over the peer-peer protocol. The peer will be disconnected, but you get its peer-id from the alert. This alert is generated as severity level debug.
@@ -1073,7 +1073,7 @@ struct peer_error_alert: alertThie is a debug alert that is generated by an incoming invalid piece request.
struct invalid_request_alert: alert @@ -1093,7 +1093,7 @@ struct invalid_request_alert: alert
This alert is generated when you receive a chat message from another peer. Chat messages are supported as an extension ("chat"). It is generated as severity level critical, even though it doesn't necessarily require any user intervention, it's high priority @@ -1115,16 +1115,16 @@ struct chat_message_alert: alert
There are a number of exceptions that can be thrown from different places in libtorrent, here's a complete list with description.
This exception is thrown when querying information from a torrent_handle that hasn't been initialized or that has become invalid.
@@ -1135,7 +1135,7 @@ struct invalid_handle: std::exception
This is thrown by session::add_torrent() if the torrent already has been added to the session.
@@ -1146,7 +1146,7 @@ struct duplicate_torrent: std::exception
This is thrown by bdecode() if the input data is not a valid bencoding.
struct invalid_encoding: std::exception @@ -1156,7 +1156,7 @@ struct invalid_encoding: std::exception
This is thrown from the accessors of entry if the data type of the entry doesn't match the type you want to extract from it.
@@ -1167,7 +1167,7 @@ struct type_error: std::runtime_error
This exception is thrown from the constructor of torrent_info if the given bencoded information doesn't meet the requirements on what information has to be present in a torrent file.
@@ -1179,9 +1179,9 @@ struct invalid_torrent_file: std::exception
This is an example of a program that will take a torrent-file as a parameter and print information about it to std out:
@@ -1245,7 +1245,7 @@ int main(int argc, char* argv[])
This is a simple client. It doesn't have much output to keep it simple:
#include <iostream> @@ -1297,7 +1297,7 @@ int main(int argc, char* argv[])
The fast resume mechanism is a way to remember which pieces are downloaded and where they are put between sessions. You can generate fast resume data by calling torrent_handle::write_resume_data() on torrent_handle. You can then save this data @@ -1310,7 +1310,7 @@ will skip the time consuming checks. It may have to do the checking anyway, if t fast-resume data is corrupt or doesn't fit the storage for that torrent, then it will not trust the fast-resume data and just do the checking.
The file format is a bencoded dictionary containing the following fields: