Commit 0459db2c authored by Roger Dingledine's avatar Roger Dingledine
Browse files

checkpoint some changes as i read diffs


svn:r8780
parent b27cb38d
......@@ -18,8 +18,8 @@ Changes in version 0.1.2.3-alpha - 2006-10-??
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
......
......@@ -90,13 +90,6 @@ R - option to dl directory info via tor
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 @@ d - need to figure out how to fetch status of a few servers from the BDA
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 @@ Deferred from 0.1.2.x:
- 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 @@ Minor items for 0.1.2.x as time permits:
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
......
......@@ -352,11 +352,11 @@ $Id$
"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 @@ $Id$
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:
......
......@@ -669,6 +669,8 @@ $Id$
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 @@ $Id$
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
......
......@@ -257,8 +257,8 @@ tor_munmap_file(tor_mmap_t *handle)
/** 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
......
......@@ -1857,12 +1857,12 @@ connection_exit_begin_conn(cell_t *cell, circuit_t *circ)
/* 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 @@ connection_exit_begin_conn(cell_t *cell, circuit_t *circ)
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 @@ connection_exit_begin_conn(cell_t *cell, circuit_t *circ)
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 @@ connection_exit_begin_conn(cell_t *cell, circuit_t *circ)
}
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 @@ connection_exit_begin_conn(cell_t *cell, circuit_t *circ)
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 @@ connection_exit_begin_conn(cell_t *cell, circuit_t *circ)
* 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 @@ connection_exit_connect_dir(edge_connection_t *exit_conn)
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);
......
......@@ -1438,6 +1438,9 @@ list_getinfo_options(void)
"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
......
......@@ -1305,7 +1305,7 @@ write_http_status_line(dir_connection_t *conn, int status,
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.
......
......@@ -2347,8 +2347,8 @@ int circuit_receive_relay_cell(cell_t *cell, circuit_t *circ,
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,
......
......@@ -4164,7 +4164,7 @@ networkstatus_getinfo_helper_single(routerstatus_t *rs)
/** 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 @@ networkstatus_getinfo_helper(const char *question, char **answer)
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 @@ networkstatus_getinfo_helper(const char *question, char **answer)
*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;
}
......
......@@ -1218,7 +1218,7 @@ test_mmap(void)
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);
......
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment