[or-cvs] r8780: checkpoint some changes as i read diffs (in tor/trunk: . doc src/common src/or)
arma at seul.org
arma at seul.org
Fri Oct 20 19:11:15 UTC 2006
Author: arma
Date: 2006-10-20 15:11:12 -0400 (Fri, 20 Oct 2006)
New Revision: 8780
Modified:
tor/trunk/ChangeLog
tor/trunk/doc/TODO
tor/trunk/doc/control-spec.txt
tor/trunk/doc/dir-spec.txt
tor/trunk/src/common/compat.c
tor/trunk/src/or/connection_edge.c
tor/trunk/src/or/control.c
tor/trunk/src/or/directory.c
tor/trunk/src/or/or.h
tor/trunk/src/or/routerlist.c
tor/trunk/src/or/test.c
Log:
checkpoint some changes as i read diffs
Modified: tor/trunk/ChangeLog
===================================================================
--- tor/trunk/ChangeLog 2006-10-20 17:54:48 UTC (rev 8779)
+++ tor/trunk/ChangeLog 2006-10-20 19:11:12 UTC (rev 8780)
@@ -18,8 +18,8 @@
event format. Also, add additional reason codes to explain why a
given circuit has been destroyed or truncated. (Patches from Mike
Perry)
- - Add a REMOTE_REASON field to CIRC events to tell the controller about
- why a remote OR told us to close a circuit.
+ - Add a REMOTE_REASON field to extended CIRC events to tell the
+ controller about why a remote OR told us to close a circuit.
- There's now a GETINFO ns/... field so that controllers can ask Tor
about the current state of a router.
- Stream events also have REASON and REMOTE_REASON fields, working much
Modified: tor/trunk/doc/TODO
===================================================================
--- tor/trunk/doc/TODO 2006-10-20 17:54:48 UTC (rev 8779)
+++ tor/trunk/doc/TODO 2006-10-20 19:11:12 UTC (rev 8780)
@@ -90,13 +90,6 @@
non-Tor DL when not enough info present.
D Count TLS bandwidth more accurately
- - Improvements to bandwidth counting
-R - look into "uncounting" bytes spent on local connections, so
- we can bandwidthrate but still have fast downloads.
-R - "bandwidth classes", for incoming vs initiated-here conns.
-d - Write limiting; separate token bucket for write
- - Write-limit directory responses (need to research)
-
N - DNS improvements
o Option to deal with broken DNS of the "ggoogle.com? Ah, you meant
ads.me.com!" variety.
@@ -233,6 +226,12 @@
without fetching all statuses. A new URL to fetch I presume?
Deferred from 0.1.2.x:
+ - Improvements to bandwidth counting
+R - look into "uncounting" bytes spent on local connections, so
+ we can bandwidthrate but still have fast downloads.
+R - "bandwidth classes", for incoming vs initiated-here conns.
+d - Write limiting; separate token bucket for write
+ - Write-limit directory responses (need to research)
- Directory guards
- RAM use in directory authorities.
- Memory use improvements:
@@ -278,6 +277,9 @@
- Implement
Minor items for 0.1.2.x as time permits:
+ - some way for the authorities to set BadExit for some nodes manually.
+ - "getinfo fingerprint" controller command
+ - "setevent guards" controller command
- The Debian package now uses --verify-config when (re)starting,
to distinguish configuration errors from other errors. Perhaps
the RPM and other startup scripts should too?
@@ -288,14 +290,14 @@
the descriptor.
- Flesh out options_description array in src/or/config.c
- Don't let 'newnym' be triggered more often than every n seconds.
- - change log_fn() to log() on notice/warn/err logs where we can.
+ o change log_fn() to log() on notice/warn/err logs where we can.
- the deb now uses --verify-config to distinguish between configuration
errors and other errors. Should the rpm, the ports, etc do this too?
X If we try to publish as a nickname that's already claimed, should
we append a number (or increment the number) and try again? This
way people who read their logs can fix it as before, but people
who don't read their logs will still offer Tor servers.
- - Fall back to unnamed; warn user; sent controller event.
+ - Fall back to unnamed; warn user; send controller event.
! - Tor should bind its ports before dropping privs, so users don't
have to do the ipchains dance.
- Rate limit exit connections to a given destination -- this helps
Modified: tor/trunk/doc/control-spec.txt
===================================================================
--- tor/trunk/doc/control-spec.txt 2006-10-20 17:54:48 UTC (rev 8779)
+++ tor/trunk/doc/control-spec.txt 2006-10-20 19:11:12 UTC (rev 8780)
@@ -352,11 +352,11 @@
"ns/id/<OR identity>" or "desc/name/<OR nickname>" -- the latest network
status info for a given OR. Network status info is as given in
dir-spec.txt, and reflects the current beliefs of this Tor about the
- router in question. [First implemented in 0.1.2.3-alpha] Like
- directory clients, controllers MUST tolerate unrecognized flags and
- lines. The published date and descriptor digest are those believed to
- be best by this Tor, not necessarily those for a descriptor that Tor
- currently has.
+ router in question. Like directory clients, controllers MUST
+ tolerate unrecognized flags and lines. The published date and
+ descriptor digest are those believed to be best by this Tor,
+ not necessarily those for a descriptor that Tor currently has.
+ [First implemented in 0.1.2.3-alpha.]
"ns/all" -- Network status info for all ORs we have an opinion about,
joined by newlines. [First implemented in 0.1.2.3-alpha.]
@@ -1064,7 +1064,9 @@
BAD_SERVER_DESCRIPTOR
"dirauth=nickname"
- // dir authorities didn't like my descriptor
+ "reason=string"
+ // dir authorities didn't like my descriptor, e.g. because they
+ // think it's malformed, you're invalid, or wrong key.
Actions for STATUS_SERVER severity ERR events can be as follows:
Modified: tor/trunk/doc/dir-spec.txt
===================================================================
--- tor/trunk/doc/dir-spec.txt 2006-10-20 17:54:48 UTC (rev 8779)
+++ tor/trunk/doc/dir-spec.txt 2006-10-20 19:11:12 UTC (rev 8780)
@@ -669,6 +669,8 @@
it is recommended by at least one networkstatus AND no "better"
descriptor has been downloaded. [Versions of Tor before 0.1.2.3-alpha
would discard descriptors simply for being published too far in the past.]
+ [The code seems to discard descriptors in all cases after they're 5
+ days old. True? -RD]
5.3. Managing downloads
@@ -806,7 +808,7 @@
7.1. HTTP headers
- Servers MAY set the Content-Length header. Servers SHOULD set
+ Servers MAY set the Content-Length: header. Servers SHOULD set
Content-Encoding to "deflate" or "identity".
Servers MAY include an X-Your-Address-Is: header, whose value is the
Modified: tor/trunk/src/common/compat.c
===================================================================
--- tor/trunk/src/common/compat.c 2006-10-20 17:54:48 UTC (rev 8779)
+++ tor/trunk/src/common/compat.c 2006-10-20 19:11:12 UTC (rev 8780)
@@ -257,8 +257,8 @@
/** Replacement for snprintf. Differs from platform snprintf in two
* ways: First, always NUL-terminates its output. Second, always
* returns -1 if the result is truncated. (Note that this return
- * behavior does <i>not</i> conform to C99; it just happens to be the
- * easiest to emulate "return -1" with conformant implementations than
+ * behavior does <i>not</i> conform to C99; it just happens to be
+ * easier to emulate "return -1" with conformant implementations than
* it is to emulate "return number that would be written" with
* non-conformant implementations.) */
int
Modified: tor/trunk/src/or/connection_edge.c
===================================================================
--- tor/trunk/src/or/connection_edge.c 2006-10-20 17:54:48 UTC (rev 8779)
+++ tor/trunk/src/or/connection_edge.c 2006-10-20 19:11:12 UTC (rev 8780)
@@ -1857,12 +1857,12 @@
/* Note: we have to use relay_send_command_from_edge here, not
* connection_edge_end or connection_edge_send_command, since those require
* that we have a stream connected to a circuit, and we don't connect to a
- * circuit unitl we have a pending/sucessful resolve. */
+ * circuit until we have a pending/successful resolve. */
if (!server_mode(get_options()) &&
circ->purpose != CIRCUIT_PURPOSE_S_REND_JOINED) {
log_fn(LOG_PROTOCOL_WARN, LD_PROTOCOL,
- "Relay begin cell at non-server. Dropping.");
+ "Relay begin cell at non-server. Closing.");
end_payload[0] = END_STREAM_REASON_EXITPOLICY;
relay_send_command_from_edge(rh.stream_id, circ, RELAY_COMMAND_END,
end_payload, 1, NULL);
@@ -1872,7 +1872,7 @@
if (rh.command == RELAY_COMMAND_BEGIN) {
if (!memchr(cell->payload+RELAY_HEADER_SIZE, 0, rh.length)) {
log_fn(LOG_PROTOCOL_WARN, LD_PROTOCOL,
- "Relay begin cell has no \\0. Dropping.");
+ "Relay begin cell has no \\0. Closing.");
end_payload[0] = END_STREAM_REASON_TORPROTOCOL;
relay_send_command_from_edge(rh.stream_id, circ, RELAY_COMMAND_END,
end_payload, 1, NULL);
@@ -1881,7 +1881,7 @@
if (parse_addr_port(LOG_PROTOCOL_WARN, cell->payload+RELAY_HEADER_SIZE,
&address,NULL,&port)<0) {
log_fn(LOG_PROTOCOL_WARN, LD_PROTOCOL,
- "Unable to parse addr:port in relay begin cell. Dropping.");
+ "Unable to parse addr:port in relay begin cell. Closing.");
end_payload[0] = END_STREAM_REASON_TORPROTOCOL;
relay_send_command_from_edge(rh.stream_id, circ, RELAY_COMMAND_END,
end_payload, 1, NULL);
@@ -1889,7 +1889,7 @@
}
if (port==0) {
log_fn(LOG_PROTOCOL_WARN, LD_PROTOCOL,
- "Missing port in relay begin cell. Dropping.");
+ "Missing port in relay begin cell. Closing.");
end_payload[0] = END_STREAM_REASON_TORPROTOCOL;
relay_send_command_from_edge(rh.stream_id, circ, RELAY_COMMAND_END,
end_payload, 1, NULL);
@@ -1900,7 +1900,7 @@
if (!tor_strisprint(address)) {
log_fn(LOG_PROTOCOL_WARN, LD_PROTOCOL,
"Non-printing characters in address %s in relay "
- "begin cell. Dropping.", escaped(address));
+ "begin cell. Closing.", escaped(address));
end_payload[0] = END_STREAM_REASON_TORPROTOCOL;
relay_send_command_from_edge(rh.stream_id, circ, RELAY_COMMAND_END,
end_payload, 1, NULL);
@@ -1913,7 +1913,7 @@
* and users who'd be better off with, well, single-hop proxies.
*/
log_fn(LOG_PROTOCOL_WARN, LD_PROTOCOL,
- "Attempt to open a stream on first hop of circuit. Dropping.");
+ "Attempt to open a stream on first hop of circuit. Closing.");
end_payload[0] = END_STREAM_REASON_TORPROTOCOL;
relay_send_command_from_edge(rh.stream_id, circ, RELAY_COMMAND_END,
end_payload, 1, NULL);
@@ -2193,7 +2193,8 @@
if ((err = tor_socketpair(AF_UNIX, SOCK_STREAM, 0, fd)) < 0) {
log_warn(LD_NET,
- "Couldn't construct socketpair (%s). Out of sockets?",
+ "Couldn't construct socketpair (%s). "
+ "Network down? Out of sockets?",
tor_socket_strerror(-err));
connection_edge_end(exit_conn, END_STREAM_REASON_RESOURCELIMIT,
exit_conn->cpath_layer);
Modified: tor/trunk/src/or/control.c
===================================================================
--- tor/trunk/src/or/control.c 2006-10-20 17:54:48 UTC (rev 8779)
+++ tor/trunk/src/or/control.c 2006-10-20 19:11:12 UTC (rev 8780)
@@ -1438,6 +1438,9 @@
"stream-status Status of each current application stream.\n"
"version The current version of Tor.\n");
// XXXX Uptodate!
+ /* This has been hard to keep up to date. Is it worth making
+ * a table with names, descriptions, and functions to call,
+ * so there's only one place to maintain? -RD */
}
/** Lookup the 'getinfo' entry <b>question</b>, and return
Modified: tor/trunk/src/or/directory.c
===================================================================
--- tor/trunk/src/or/directory.c 2006-10-20 17:54:48 UTC (rev 8779)
+++ tor/trunk/src/or/directory.c 2006-10-20 19:11:12 UTC (rev 8780)
@@ -1305,7 +1305,7 @@
connection_write_to_buf(buf, strlen(buf), TO_CONN(conn));
}
-/** Write the header for an HTTP/1.0 response onto <b>conn</b>->outbuf,
+/** Write the header for an HTTP/1.0 response onto <b>conn</b>-\>outbuf,
* with <b>type</b> as the Content-Type.
*
* If <b>length</b> is nonnegative, it is the Content-Length.
Modified: tor/trunk/src/or/or.h
===================================================================
--- tor/trunk/src/or/or.h 2006-10-20 17:54:48 UTC (rev 8779)
+++ tor/trunk/src/or/or.h 2006-10-20 19:11:12 UTC (rev 8780)
@@ -2347,8 +2347,8 @@
void relay_header_pack(char *dest, const relay_header_t *src);
void relay_header_unpack(relay_header_t *dest, const char *src);
int relay_send_command_from_edge(uint16_t stream_id, circuit_t *circ,
- int relay_command, const char *payload,
- size_t payload_len, crypt_path_t *cpath_layer);
+ int relay_command, const char *payload,
+ size_t payload_len, crypt_path_t *cpath_layer);
int connection_edge_send_command(edge_connection_t *fromconn, circuit_t *circ,
int relay_command, const char *payload,
size_t payload_len,
Modified: tor/trunk/src/or/routerlist.c
===================================================================
--- tor/trunk/src/or/routerlist.c 2006-10-20 17:54:48 UTC (rev 8779)
+++ tor/trunk/src/or/routerlist.c 2006-10-20 19:11:12 UTC (rev 8780)
@@ -4164,7 +4164,7 @@
/** If <b>question</b> is a string beginning with "ns/" in a format the
* control interface expects for a GETINFO question, set *<b>answer</b> to a
* newly-allocated string containing networkstatus lines for the appropriate
- * ORs. Return 0 on success, -1 on failure. */
+ * ORs. Return 0 on success, -1 on unrecognized question format. */
int
networkstatus_getinfo_helper(const char *question, char **answer)
{
@@ -4175,7 +4175,7 @@
return 0;
}
- if (!strcmpstart(question, "ns/all")) {
+ if (!strcmp(question, "ns/all")) {
smartlist_t *statuses = smartlist_create();
SMARTLIST_FOREACH(routerstatus_list, local_routerstatus_t *, lrs,
{
@@ -4202,6 +4202,8 @@
*answer = networkstatus_getinfo_helper_single(&status->status);
} else {
*answer = tor_strdup("");
+ /* XXX this should return a 552, not a 250; but handle_getinfo_helper()
+ * isn't set up to handle that. That should be fixed too. :) -RD */
}
return 0;
}
Modified: tor/trunk/src/or/test.c
===================================================================
--- tor/trunk/src/or/test.c 2006-10-20 17:54:48 UTC (rev 8779)
+++ tor/trunk/src/or/test.c 2006-10-20 19:11:12 UTC (rev 8780)
@@ -1218,7 +1218,7 @@
test_streq(mapping->data, "Short file.");
tor_munmap_file(mapping);
- /* Make sure that we fail to map a no-longer-existant file. */
+ /* Make sure that we fail to map a no-longer-existent file. */
mapping = tor_mmap_file(fname1);
test_assert(mapping == NULL);
More information about the tor-commits
mailing list