mirror of
https://gitlab.torproject.org/tpo/core/tor.git
synced 2024-11-23 20:03:31 +01:00
directory-level doxygen for "src/core"
This commit is contained in:
parent
607b1ff776
commit
e1cdca2e4f
@ -1,95 +1,6 @@
|
|||||||
|
|
||||||
## Tor's modules ##
|
## Tor's modules ##
|
||||||
|
|
||||||
### Generic modules ###
|
|
||||||
|
|
||||||
`buffers.c`
|
|
||||||
: Implements the `buf_t` buffered data type for connections, and several
|
|
||||||
low-level data handling functions to handle network protocols on it.
|
|
||||||
|
|
||||||
`channel.c`
|
|
||||||
: Generic channel implementation. Channels handle sending and receiving cells
|
|
||||||
among tor nodes.
|
|
||||||
|
|
||||||
`channeltls.c`
|
|
||||||
: Channel implementation for TLS-based OR connections. Uses `connection_or.c`.
|
|
||||||
|
|
||||||
`circuitbuild.c`
|
|
||||||
: Code for constructing circuits and choosing their paths. (*Note*:
|
|
||||||
this module could plausibly be split into handling the client side,
|
|
||||||
the server side, and the path generation aspects of circuit building.)
|
|
||||||
|
|
||||||
`circuitlist.c`
|
|
||||||
: Code for maintaining and navigating the global list of circuits.
|
|
||||||
|
|
||||||
`circuitmux.c`
|
|
||||||
: Generic circuitmux implementation. A circuitmux handles deciding, for a
|
|
||||||
particular channel, which circuit should write next.
|
|
||||||
|
|
||||||
`circuitmux_ewma.c`
|
|
||||||
: A circuitmux implementation based on the EWMA (exponentially
|
|
||||||
weighted moving average) algorithm.
|
|
||||||
|
|
||||||
`circuituse.c`
|
|
||||||
: Code to actually send and receive data on circuits.
|
|
||||||
|
|
||||||
`command.c`
|
|
||||||
: Handles incoming cells on channels.
|
|
||||||
|
|
||||||
`config.c`
|
|
||||||
: Parses options from torrc, and uses them to configure the rest of Tor.
|
|
||||||
|
|
||||||
`confparse.c`
|
|
||||||
: Generic torrc-style parser. Used to parse torrc and state files.
|
|
||||||
|
|
||||||
`connection.c`
|
|
||||||
: Generic and common connection tools, and implementation for the simpler
|
|
||||||
connection types.
|
|
||||||
|
|
||||||
`connection_edge.c`
|
|
||||||
: Implementation for entry and exit connections.
|
|
||||||
|
|
||||||
`connection_or.c`
|
|
||||||
: Implementation for OR connections (the ones that send cells over TLS).
|
|
||||||
|
|
||||||
`main.c`
|
|
||||||
: Principal entry point, main loops, scheduled events, and network
|
|
||||||
management for Tor.
|
|
||||||
|
|
||||||
`ntmain.c`
|
|
||||||
: Implements Tor as a Windows service. (Not very well.)
|
|
||||||
|
|
||||||
`onion.c`
|
|
||||||
: Generic code for generating and responding to CREATE and CREATED
|
|
||||||
cells, and performing the appropriate onion handshakes. Also contains
|
|
||||||
code to manage the server-side onion queue.
|
|
||||||
|
|
||||||
`onion_fast.c`
|
|
||||||
: Implements the old SHA1-based CREATE_FAST/CREATED_FAST circuit
|
|
||||||
creation handshake. (Now deprecated.)
|
|
||||||
|
|
||||||
`onion_ntor.c`
|
|
||||||
: Implements the Curve25519-based NTOR circuit creation handshake.
|
|
||||||
|
|
||||||
`onion_tap.c`
|
|
||||||
: Implements the old RSA1024/DH1024-based TAP circuit creation handshake. (Now
|
|
||||||
deprecated.)
|
|
||||||
|
|
||||||
`relay.c`
|
|
||||||
: Handles particular types of relay cells, and provides code to receive,
|
|
||||||
encrypt, route, and interpret relay cells.
|
|
||||||
|
|
||||||
`scheduler.c`
|
|
||||||
: Decides which channel/circuit pair is ready to receive the next cell.
|
|
||||||
|
|
||||||
`statefile.c`
|
|
||||||
: Handles loading and storing Tor's state file.
|
|
||||||
|
|
||||||
`tor_main.c`
|
|
||||||
: Contains the actual `main()` function. (This is placed in a separate
|
|
||||||
file so that the unit tests can have their own `main()`.)
|
|
||||||
|
|
||||||
|
|
||||||
### Node-status modules ###
|
### Node-status modules ###
|
||||||
|
|
||||||
`directory.c`
|
`directory.c`
|
||||||
|
@ -5,4 +5,16 @@
|
|||||||
The "core" directory has the central protocols for Tor, which every
|
The "core" directory has the central protocols for Tor, which every
|
||||||
client and relay must implement in order to perform onion routing.
|
client and relay must implement in order to perform onion routing.
|
||||||
|
|
||||||
|
It is divided into three lower-level pieces:
|
||||||
|
|
||||||
|
- \refdir{core/crypto} -- Tor-specific cryptography.
|
||||||
|
|
||||||
|
- \refdir{core/proto} -- Protocol encoding/decoding.
|
||||||
|
|
||||||
|
- \refdir{core/mainloop} -- A connection-oriented asynchronous mainloop.
|
||||||
|
|
||||||
|
and one high-level piece:
|
||||||
|
|
||||||
|
- \refdir{core/or} -- Implements onion routing itself.
|
||||||
|
|
||||||
**/
|
**/
|
||||||
|
@ -1,4 +1,8 @@
|
|||||||
/**
|
/**
|
||||||
@dir /core/crypto
|
@dir /core/crypto
|
||||||
@brief core/crypto
|
@brief core/crypto: Tor-specific cryptography
|
||||||
|
|
||||||
|
This module implements Tor's circuit-construction crypto and Tor's
|
||||||
|
relay crypto.
|
||||||
|
|
||||||
**/
|
**/
|
||||||
|
@ -1,4 +1,12 @@
|
|||||||
/**
|
/**
|
||||||
@dir /core/mainloop
|
@dir /core/mainloop
|
||||||
@brief core/mainloop
|
@brief core/mainloop: Non-onion-routing mainloop functionality
|
||||||
|
|
||||||
|
This module uses the event-loop code of \refdir{lib/evloop} to implement an
|
||||||
|
asynchronous connection-oriented protocol handler.
|
||||||
|
|
||||||
|
The layering here is imperfect: the code here was split from \refdir{core/or}
|
||||||
|
without refactoring how the two modules call one another. Probably many
|
||||||
|
functions should be moved and refactored.
|
||||||
|
|
||||||
**/
|
**/
|
||||||
|
@ -1,4 +1,62 @@
|
|||||||
/**
|
/**
|
||||||
@dir /core/or
|
@dir /core/or
|
||||||
@brief core/or
|
@brief core/or: *Onion routing happens here*.
|
||||||
**/
|
|
||||||
|
This is the central part of Tor that handles the core tasks of onion routing:
|
||||||
|
building circuit, handling circuits, attaching circuit to streams, moving
|
||||||
|
data around, and so forth.
|
||||||
|
|
||||||
|
Some aspects of this module should probably be refactored into others.
|
||||||
|
|
||||||
|
Notable files here include:
|
||||||
|
|
||||||
|
`channel.c`
|
||||||
|
: Generic channel implementation. Channels handle sending and receiving cells
|
||||||
|
among tor nodes.
|
||||||
|
|
||||||
|
`channeltls.c`
|
||||||
|
: Channel implementation for TLS-based OR connections. Uses `connection_or.c`.
|
||||||
|
|
||||||
|
`circuitbuild.c`
|
||||||
|
: Code for constructing circuits and choosing their paths. (*Note*:
|
||||||
|
this module could plausibly be split into handling the client side,
|
||||||
|
the server side, and the path generation aspects of circuit building.)
|
||||||
|
|
||||||
|
`circuitlist.c`
|
||||||
|
: Code for maintaining and navigating the global list of circuits.
|
||||||
|
|
||||||
|
`circuitmux.c`
|
||||||
|
: Generic circuitmux implementation. A circuitmux handles deciding, for a
|
||||||
|
particular channel, which circuit should write next.
|
||||||
|
|
||||||
|
`circuitmux_ewma.c`
|
||||||
|
: A circuitmux implementation based on the EWMA (exponentially
|
||||||
|
weighted moving average) algorithm.
|
||||||
|
|
||||||
|
`circuituse.c`
|
||||||
|
: Code to actually send and receive data on circuits.
|
||||||
|
|
||||||
|
`command.c`
|
||||||
|
: Handles incoming cells on channels.
|
||||||
|
|
||||||
|
`connection.c`
|
||||||
|
: Generic and common connection tools, and implementation for the simpler
|
||||||
|
connection types.
|
||||||
|
|
||||||
|
`connection_edge.c`
|
||||||
|
: Implementation for entry and exit connections.
|
||||||
|
|
||||||
|
`connection_or.c`
|
||||||
|
: Implementation for OR connections (the ones that send cells over TLS).
|
||||||
|
|
||||||
|
`onion.c`
|
||||||
|
: Generic code for generating and responding to CREATE and CREATED
|
||||||
|
cells, and performing the appropriate onion handshakes. Also contains
|
||||||
|
code to manage the server-side onion queue.
|
||||||
|
|
||||||
|
`relay.c`
|
||||||
|
: Handles particular types of relay cells, and provides code to receive,
|
||||||
|
encrypt, route, and interpret relay cells.
|
||||||
|
|
||||||
|
`scheduler.c`
|
||||||
|
: Decides which channel/circuit pair is ready to receive the next cell.
|
||||||
|
@ -1,4 +1,8 @@
|
|||||||
/**
|
/**
|
||||||
@dir /core/proto
|
@dir /core/proto
|
||||||
@brief core/proto
|
@brief core/proto: Protocol encoding/decoding
|
||||||
|
|
||||||
|
These functions should (but do not always) exist at a lower level than most
|
||||||
|
of the rest of core.
|
||||||
|
|
||||||
**/
|
**/
|
||||||
|
Loading…
Reference in New Issue
Block a user