mirror of
https://gitlab.torproject.org/tpo/core/tor.git
synced 2024-11-11 05:33:47 +01:00
directory-level documentation for feature/*
This commit is contained in:
parent
e1cdca2e4f
commit
a33d1dce8a
@ -1,4 +1,4 @@
|
|||||||
/**
|
/**
|
||||||
@dir /feature/api
|
@dir /feature/api
|
||||||
@brief feature/api
|
@brief feature/api: In-process interface to starting/stopping Tor.
|
||||||
**/
|
**/
|
||||||
|
@ -1,4 +1,7 @@
|
|||||||
/**
|
/**
|
||||||
@dir /feature/client
|
@dir /feature/client
|
||||||
@brief feature/client
|
@brief feature/client: Client-specific code
|
||||||
|
|
||||||
|
(There is also a bunch of client-specific code in other modules.)
|
||||||
|
|
||||||
**/
|
**/
|
||||||
|
@ -1,4 +1,10 @@
|
|||||||
/**
|
/**
|
||||||
@dir /feature/control
|
@dir /feature/control
|
||||||
@brief feature/control
|
@brief feature/control: Controller API.
|
||||||
|
|
||||||
|
The Controller API is a text-based protocol that another program (or another
|
||||||
|
thread, if you're running Tor in-process) can use to configure and control
|
||||||
|
Tor while it is running. The current protocol is documented in
|
||||||
|
[control-spec.txt](https://gitweb.torproject.org/torspec.git/tree/control-spec.txt).
|
||||||
|
|
||||||
**/
|
**/
|
||||||
|
@ -1,4 +1,6 @@
|
|||||||
/**
|
/**
|
||||||
@dir /feature/dirauth
|
@dir /feature/dirauth
|
||||||
@brief feature/dirauth
|
@brief feature/dirauth: Directory authority implementation.
|
||||||
|
|
||||||
|
This module handles running Tor as a directory authority.
|
||||||
**/
|
**/
|
||||||
|
@ -1,4 +1,8 @@
|
|||||||
/**
|
/**
|
||||||
@dir /feature/dircache
|
@dir /feature/dircache
|
||||||
@brief feature/dircache
|
@brief feature/dircache: Run as a directory cache server
|
||||||
|
|
||||||
|
This module handles the directory caching functionality that all relays may
|
||||||
|
provide, for serving cached directory objects to objects.
|
||||||
|
|
||||||
**/
|
**/
|
||||||
|
@ -1,4 +1,9 @@
|
|||||||
/**
|
/**
|
||||||
@dir /feature/dirclient
|
@dir /feature/dirclient
|
||||||
@brief feature/dirclient
|
@brief feature/dirclient: Directory client implementation.
|
||||||
|
|
||||||
|
The code here is used by all Tor instances that need to download directory
|
||||||
|
information. Currently, that is all of them, since even authorities need to
|
||||||
|
launch downloads to learn about relays that other authorities have listed.
|
||||||
|
|
||||||
**/
|
**/
|
||||||
|
@ -1,4 +1,9 @@
|
|||||||
/**
|
/**
|
||||||
@dir /feature/dircommon
|
@dir /feature/dircommon
|
||||||
@brief feature/dircommon
|
@brief feature/dircommon: Directory client and server shared code
|
||||||
|
|
||||||
|
This module has the code that directory clients (anybody who download
|
||||||
|
information about relays) and directory servers (anybody who serves such
|
||||||
|
information) share in common.
|
||||||
|
|
||||||
**/
|
**/
|
||||||
|
@ -1,4 +1,10 @@
|
|||||||
/**
|
/**
|
||||||
@dir /feature/dirparse
|
@dir /feature/dirparse
|
||||||
@brief feature/dirparse
|
@brief feature/dirparse: Parsing Tor directory objects
|
||||||
|
|
||||||
|
We define a number of "directory objects" in
|
||||||
|
[dir-spec.txt](https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt),
|
||||||
|
all of them using a common line-oriented meta-format. This module is used by
|
||||||
|
other parts of Tor to parse them.
|
||||||
|
|
||||||
**/
|
**/
|
||||||
|
@ -1,4 +1,16 @@
|
|||||||
/**
|
/**
|
||||||
@dir /feature/hibernate
|
@dir /feature/hibernate
|
||||||
@brief feature/hibernate
|
@brief feature/hibernate: Bandwidth accounting and hibernation (!)
|
||||||
|
|
||||||
|
This module implements two features that are only somewhat related, and
|
||||||
|
should probably be separated in the future. One feature is bandwidth
|
||||||
|
accounting (making sure we use no more than so many gigabytes in a day) and
|
||||||
|
hibernation (avoiding network activity while we have used up all/most of our
|
||||||
|
configured gigabytes). The other feature is clean shutdown, where we stop
|
||||||
|
accepting new connections for a while and give the old ones time to close.
|
||||||
|
|
||||||
|
The two features are related only in the sense that "soft hibernation" (being
|
||||||
|
almost out of ) is very close to the "shutting down" state. But it would be
|
||||||
|
better in the long run to make the two completely separate.
|
||||||
|
|
||||||
**/
|
**/
|
||||||
|
@ -1,4 +1,5 @@
|
|||||||
/**
|
/**
|
||||||
@dir /feature/hs
|
@dir /feature/hs
|
||||||
@brief feature/hs
|
@brief feature/hs: v3 (current) onion service protocol
|
||||||
|
|
||||||
**/
|
**/
|
||||||
|
@ -1,4 +1,5 @@
|
|||||||
/**
|
/**
|
||||||
@dir /feature/hs_common
|
@dir /feature/hs_common
|
||||||
@brief feature/hs_common
|
@brief feature/hs_common: Common to v2 (old) and v3 (current) onion services
|
||||||
|
|
||||||
**/
|
**/
|
||||||
|
@ -1,4 +1,5 @@
|
|||||||
/**
|
/**
|
||||||
@dir /feature/keymgt
|
@dir /feature/keymgt
|
||||||
@brief feature/keymgt
|
@brief feature/keymgt: Store keys for relays, authorities, etc.
|
||||||
|
|
||||||
**/
|
**/
|
||||||
|
@ -1,4 +1,4 @@
|
|||||||
/**
|
/**
|
||||||
@dir /feature/nodelist
|
@dir /feature/nodelist
|
||||||
@brief feature/nodelist
|
@brief feature/nodelist: Download and manage a list of relays
|
||||||
**/
|
**/
|
||||||
|
@ -1,4 +1,6 @@
|
|||||||
/**
|
/**
|
||||||
@dir /feature/relay
|
@dir /feature/relay
|
||||||
@brief feature/relay
|
@brief feature/relay: Relay-specific code
|
||||||
|
|
||||||
|
(There is also a bunch of relay-specific code in other modules.)
|
||||||
**/
|
**/
|
||||||
|
@ -1,4 +1,5 @@
|
|||||||
/**
|
/**
|
||||||
@dir /feature/rend
|
@dir /feature/rend
|
||||||
@brief feature/rend
|
@brief feature/rend: version 2 (old) hidden services
|
||||||
|
|
||||||
**/
|
**/
|
||||||
|
@ -1,4 +1,12 @@
|
|||||||
/**
|
/**
|
||||||
@dir /feature/stats
|
@dir /feature/stats
|
||||||
@brief feature/stats
|
@brief feature/stats: Relay statistics. Also, port prediction.
|
||||||
|
|
||||||
|
This module collects anonymized relay statistics in order to publish them in
|
||||||
|
relays' routerinfo and extrainfo documents.
|
||||||
|
|
||||||
|
Additionally, it contains predict_ports.c, which remembers which ports we've
|
||||||
|
visited recently as a client, so we can make sure we have open circuits that
|
||||||
|
support them.
|
||||||
|
|
||||||
**/
|
**/
|
||||||
|
Loading…
Reference in New Issue
Block a user