summaryrefslogtreecommitdiff
path: root/src/or/command.c
diff options
context:
space:
mode:
authorNick Mathewson <nickm@torproject.org>2016-10-14 20:08:51 -0400
committerNick Mathewson <nickm@torproject.org>2016-10-17 10:16:59 -0400
commitaae034d13e458dfe82b503d3a1b54b0e5200b6b8 (patch)
treef2f69832a97045fbe2384e7320c73d3ea7c86ba8 /src/or/command.c
parent55c468c5211d5b74acb677767f14d91cd0304771 (diff)
downloadtor-aae034d13e458dfe82b503d3a1b54b0e5200b6b8.tar.gz
tor-aae034d13e458dfe82b503d3a1b54b0e5200b6b8.zip
Write a bunch of module documentation.
This commit adds or improves the module-level documenation for: buffers.c circuitstats.c command.c connection_edge.c control.c cpuworker.c crypto_curve25519.c crypto_curve25519.h crypto_ed25519.c crypto_format.c dircollate.c dirserv.c dns.c dns_structs.h fp_pair.c geoip.c hibernate.c keypin.c ntmain.c onion.c onion_fast.c onion_ntor.c onion_tap.c periodic.c protover.c protover.h reasons.c rephist.c replaycache.c routerlist.c routerparse.c routerset.c statefile.c status.c tor_main.c workqueue.c In particular, I've tried to explain (for each documented module) what each module does, what's in it, what the big idea is, why it belongs in Tor, and who calls it. In a few cases, I've added TODO notes about refactoring opportunities. I've also renamed an argument, and fixed a few DOCDOC comments.
Diffstat (limited to 'src/or/command.c')
-rw-r--r--src/or/command.c20
1 files changed, 20 insertions, 0 deletions
diff --git a/src/or/command.c b/src/or/command.c
index 5ad92bed1e..5866c386e4 100644
--- a/src/or/command.c
+++ b/src/or/command.c
@@ -7,6 +7,26 @@
/**
* \file command.c
* \brief Functions for processing incoming cells.
+ *
+ * When we receive a cell from a client or a relay, it arrives on some
+ * channel, and tells us what to do with it. In this module, we dispatch based
+ * on the cell type using the functions command_process_cell() and
+ * command_process_var_cell(), and deal with the cell accordingly. (These
+ * handlers are installed on a channel with the command_setup_channel()
+ * function.)
+ *
+ * Channels have a chance to handle some cell types on their own before they
+ * are ever passed here --- typically, they do this for cells that are
+ * specific to a given channel type. For example, in channeltls.c, the cells
+ * for the initial connection handshake are handled before we get here. (Of
+ * course, the fact that there _is_ only one channel type for now means that
+ * we may have gotten the factoring wrong here.)
+ *
+ * Handling other cell types is mainly farmed off to other modules, after
+ * initial sanity-checking. CREATE* cells are handled ultimately in onion.c,
+ * CREATED* cells trigger circuit creation in circuitbuild.c, DESTROY cells
+ * are handled here (since they're simple), and RELAY cells, in all their
+ * complexity, are passed off to relay.c.
**/
/* In-points to command.c: