- tor-commits - lists.torproject.org

[torspec/master] mention the uint32_t -> tor_addr_t transition too
by arma＠torproject.org 15 Mar '11

15 Mar '11

commit ab2e389479d5db84f9a7de5f0e2cf279934d19c6 Author: Roger Dingledine <arma(a)torproject.org> Date: Tue Mar 15 17:38:28 2011 -0400 mention the uint32_t -> tor_addr_t transition too --- proposals/ideas/xxx-ipv6-plan.txt | 11 +++++++++-- 1 files changed, 9 insertions(+), 2 deletions(-) diff --git a/proposals/ideas/xxx-ipv6-plan.txt b/proposals/ideas/xxx-ipv6-plan.txt index 26a0359..f88c0b0 100644 --- a/proposals/ideas/xxx-ipv6-plan.txt +++ b/proposals/ideas/xxx-ipv6-plan.txt @@ -41,8 +41,15 @@ What needs to change: dual stack of both IPv4 and IPv6 for interconnection seems like a reasonable step towards a fully hybrid v4/v6 Tor network. - Of course, more issues may be discovered as we develop solutions for these - issues, some of which may need to take priority. + One implementation hurdle that will need to get resolved alongside + these changes is to convert uint32_t to tor_addr_t in many more places + in the Tor code, so we can handle addresses being either IPv4 or IPv6. + There are a few cases, e.g. the local router list, where we'll want + to think harder about the resource requirements of keeping tens of + thousands of larger addresses in memory. + + More issues may of course also be discovered as we develop solutions + for these issues, some of which may need to take priority. Designs that we will need to do:

1 0

[torspec/master] Describe optimistic data protocol. (Text from Ian)
by nickm＠torproject.org 15 Mar '11

15 Mar '11

commit ef0bff2ff3c14934a6cd056d8a9d03151741c675 Author: Nick Mathewson <nickm(a)torproject.org> Date: Tue Mar 15 17:23:19 2011 -0400 Describe optimistic data protocol. (Text from Ian) --- tor-spec.txt | 18 ++++++++++++++++-- 1 files changed, 16 insertions(+), 2 deletions(-) diff --git a/tor-spec.txt b/tor-spec.txt index e889431..cb4c70d 100644 --- a/tor-spec.txt +++ b/tor-spec.txt @@ -797,11 +797,25 @@ see tor-design.pdf. their own cached entries after a fixed interval. This prevents certain attacks.] - The OP waits for a RELAY_CONNECTED cell before sending any data. Once a connection has been established, the OP and exit node package stream data in RELAY_DATA cells, and upon receiving such cells, echo their contents to the corresponding TCP stream. - RELAY_DATA cells sent to unrecognized streams are dropped. + + If the exit node does not support optimistic data (i.e. its + version number is before 0.2.3.1-alpha), then the OP MUST wait + for a RELAY_CONNECTED cell before sending any data. If the exit + node supports optimistic data (i.e. its version number is + 0.2.3.1-alpha or later), then the OP MAY send RELAY_DATA cells + immediately after sending the RELAY_BEGIN cell (and before + receiving either a RELAY_CONNECTED or RELAY_END cell). + + RELAY_DATA cells sent to unrecognized streams are dropped. If + the exit node supports optimistic data, then RELAY_DATA cells it + receives on streams which have seen RELAY_BEGIN but have not yet + been replied to with a RELAY_CONNECTED or RELAY_END are queued. + If the stream creation succeeds with a RELAY_CONNECTED, the queue + is processed immediately afterwards; if the stream creation fails + with a RELAY_END, the contents of the queue are deleted. Relay RELAY_DROP cells are long-range dummies; upon receiving such a cell, the OR or OP must drop it.

1 0

[tor/master] Implement server side of Proposal 174 (optimistic data)
by nickm＠torproject.org 15 Mar '11

15 Mar '11

commit bd7721f66ef94d2f3502197bf23a4cf67813eb9f Author: Ian Goldberg <iang(a)cs.uwaterloo.ca> Date: Mon Mar 14 18:05:33 2011 -0400 Implement server side of Proposal 174 (optimistic data) Ian's original message: The current code actually correctly handles queued data at the Exit; if there is queued data in a EXIT_CONN_STATE_CONNECTING stream, that data will be immediately sent when the connection succeeds. If the connection fails, the data will be correctly ignored and freed. The problem with the current server code is that the server currently drops DATA cells on streams in the EXIT_CONN_STATE_CONNECTING state. Also, if you try to queue data in the EXIT_CONN_STATE_RESOLVING state, bad things happen because streams in that state don't yet have conn->write_event set, and so some existing sanity checks (any stream with queued data is at least potentially writable) are no longer sound. The solution is to simply not drop received DATA cells while in the EXIT_CONN_STATE_CONNECTING state. Also do not send SENDME cells in this state, so that the OP cannot send more than one window's worth of data to be queued at the Exit. Finally, patch the sanity checks so that streams in the EXIT_CONN_STATE_RESOLVING state that have buffered data can pass. [...] Here is a simple patch. It seems to work with both regular streams and hidden services, but there may be other corner cases I'm not aware of. (Do streams used for directory fetches, hidden services, etc. take a different code path?) --- src/or/connection.c | 15 +++++++++++++-- src/or/relay.c | 28 +++++++++++++++++++++++----- 2 files changed, 36 insertions(+), 7 deletions(-) diff --git a/src/or/connection.c b/src/or/connection.c index 874e724..ff23646 100644 --- a/src/or/connection.c +++ b/src/or/connection.c @@ -3259,7 +3259,13 @@ _connection_write_to_buf_impl(const char *string, size_t len, return; } - connection_start_writing(conn); + /* If we receive optimistic data in the EXIT_CONN_STATE_RESOLVING + * state, we don't want to try to write it right away, since + * conn->write_event won't be set yet. Otherwise, write data from + * this conn as the socket is available. */ + if (conn->write_event) { + connection_start_writing(conn); + } if (zlib) { conn->outbuf_flushlen += buf_datalen(conn->outbuf) - old_datalen; } else { @@ -3835,7 +3841,12 @@ assert_connection_ok(connection_t *conn, time_t now) tor_assert(conn->s < 0); if (conn->outbuf_flushlen > 0) { - tor_assert(connection_is_writing(conn) || conn->write_blocked_on_bw || + /* With optimistic data, we may have queued data in + * EXIT_CONN_STATE_RESOLVING while the conn is not yet marked to writing. + * */ + tor_assert((conn->type == CONN_TYPE_EXIT && + conn->state == EXIT_CONN_STATE_RESOLVING) || + connection_is_writing(conn) || conn->write_blocked_on_bw || (CONN_IS_EDGE(conn) && TO_EDGE_CONN(conn)->edge_blocked_on_circ)); } diff --git a/src/or/relay.c b/src/or/relay.c index ec8e9ac..19f8d41 100644 --- a/src/or/relay.c +++ b/src/or/relay.c @@ -1031,6 +1031,9 @@ connection_edge_process_relay_cell(cell_t *cell, circuit_t *circ, relay_header_t rh; unsigned domain = layer_hint?LD_APP:LD_EXIT; int reason; + int optimistic_data = 0; /* Set to 1 if we receive data on a stream + that's in the EXIT_CONN_STATE_RESOLVING + or EXIT_CONN_STATE_CONNECTING states.*/ tor_assert(cell); tor_assert(circ); @@ -1050,9 +1053,20 @@ connection_edge_process_relay_cell(cell_t *cell, circuit_t *circ, /* either conn is NULL, in which case we've got a control cell, or else * conn points to the recognized stream. */ - if (conn && !connection_state_is_open(TO_CONN(conn))) - return connection_edge_process_relay_cell_not_open( - &rh, cell, circ, conn, layer_hint); + if (conn && !connection_state_is_open(TO_CONN(conn))) { + if (conn->_base.type == CONN_TYPE_EXIT && + (conn->_base.state == EXIT_CONN_STATE_CONNECTING || + conn->_base.state == EXIT_CONN_STATE_RESOLVING) && + rh.command == RELAY_COMMAND_DATA) { + /* We're going to allow DATA cells to be delivered to an exit + * node in state EXIT_CONN_STATE_CONNECTING or + * EXIT_CONN_STATE_RESOLVING. This speeds up HTTP, for example. */ + optimistic_data = 1; + } else { + return connection_edge_process_relay_cell_not_open( + &rh, cell, circ, conn, layer_hint); + } + } switch (rh.command) { case RELAY_COMMAND_DROP: @@ -1102,7 +1116,9 @@ connection_edge_process_relay_cell(cell_t *cell, circuit_t *circ, log_debug(domain,"circ deliver_window now %d.", layer_hint ? layer_hint->deliver_window : circ->deliver_window); - circuit_consider_sending_sendme(circ, layer_hint); + if (!optimistic_data) { + circuit_consider_sending_sendme(circ, layer_hint); + } if (!conn) { log_info(domain,"data cell dropped, unknown stream (streamid %d).", @@ -1119,7 +1135,9 @@ connection_edge_process_relay_cell(cell_t *cell, circuit_t *circ, stats_n_data_bytes_received += rh.length; connection_write_to_buf((char*)(cell->payload + RELAY_HEADER_SIZE), rh.length, TO_CONN(conn)); - connection_edge_consider_sending_sendme(conn); + if (!optimistic_data) { + connection_edge_consider_sending_sendme(conn); + } return 0; case RELAY_COMMAND_END: reason = rh.length > 0 ?

1 0

[tor/master] Revise prop174 patch: make the circuit sendme calls unconditional.
by nickm＠torproject.org 15 Mar '11

15 Mar '11

commit fe9de9231acdd50dcaac5c7908ea9d29f2b21b48 Author: Nick Mathewson <nickm(a)torproject.org> Date: Mon Mar 14 18:08:27 2011 -0400 Revise prop174 patch: make the circuit sendme calls unconditional. The circuit_consider_sending_sendme call should be unconditional, since the circuit windows can move independent of the state of streams. --- src/or/relay.c | 11 +++++++---- 1 files changed, 7 insertions(+), 4 deletions(-) diff --git a/src/or/relay.c b/src/or/relay.c index 19f8d41..17ce7db 100644 --- a/src/or/relay.c +++ b/src/or/relay.c @@ -1116,9 +1116,7 @@ connection_edge_process_relay_cell(cell_t *cell, circuit_t *circ, log_debug(domain,"circ deliver_window now %d.", layer_hint ? layer_hint->deliver_window : circ->deliver_window); - if (!optimistic_data) { - circuit_consider_sending_sendme(circ, layer_hint); - } + circuit_consider_sending_sendme(circ, layer_hint); if (!conn) { log_info(domain,"data cell dropped, unknown stream (streamid %d).", @@ -1135,9 +1133,14 @@ connection_edge_process_relay_cell(cell_t *cell, circuit_t *circ, stats_n_data_bytes_received += rh.length; connection_write_to_buf((char*)(cell->payload + RELAY_HEADER_SIZE), rh.length, TO_CONN(conn)); + if (!optimistic_data) { - connection_edge_consider_sending_sendme(conn); + /* Only send a SENDME if we're not getting optimistic data; otherwise + * a SENDME could arrive before the CONNECTED. + */ + connection_edge_consider_sending_sendme(conn); } + return 0; case RELAY_COMMAND_END: reason = rh.length > 0 ?

1 0

[tor/master] Add changes file for server-side optimistic data patch
by nickm＠torproject.org 15 Mar '11

15 Mar '11

commit 6a97450cbd764998756386c9e84fa7b887400e74 Author: Nick Mathewson <nickm(a)torproject.org> Date: Mon Mar 14 18:20:56 2011 -0400 Add changes file for server-side optimistic data patch --- changes/prop174_server | 6 ++++++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/changes/prop174_server b/changes/prop174_server new file mode 100644 index 0000000..a2fb39f --- /dev/null +++ b/changes/prop174_server @@ -0,0 +1,6 @@ + o Features: + - Servers now accept and queue data on not-yet-connected + streams. Previously, such data wasn't allowed. This forced + clients to wait for a CONNECTED cell before sending their + data, thus adding a round trip to stream setup. (Patch from + Ian Goldberg; implements the server side of Proposal 174.)

1 0

[tor/master] whitespace fixes to pass 'make check-spaces'
by nickm＠torproject.org 15 Mar '11

15 Mar '11

commit c2775196f79b9dba70d517663004e1783873f35c Author: Roger Dingledine <arma(a)torproject.org> Date: Tue Mar 15 16:59:58 2011 -0400 whitespace fixes to pass 'make check-spaces' --- src/or/connection.c | 10 ++++++---- src/or/relay.c | 24 ++++++++++++------------ 2 files changed, 18 insertions(+), 16 deletions(-) diff --git a/src/or/connection.c b/src/or/connection.c index ff23646..b586b43 100644 --- a/src/or/connection.c +++ b/src/or/connection.c @@ -3264,7 +3264,7 @@ _connection_write_to_buf_impl(const char *string, size_t len, * conn->write_event won't be set yet. Otherwise, write data from * this conn as the socket is available. */ if (conn->write_event) { - connection_start_writing(conn); + connection_start_writing(conn); } if (zlib) { conn->outbuf_flushlen += buf_datalen(conn->outbuf) - old_datalen; @@ -3845,9 +3845,11 @@ assert_connection_ok(connection_t *conn, time_t now) * EXIT_CONN_STATE_RESOLVING while the conn is not yet marked to writing. * */ tor_assert((conn->type == CONN_TYPE_EXIT && - conn->state == EXIT_CONN_STATE_RESOLVING) || - connection_is_writing(conn) || conn->write_blocked_on_bw || - (CONN_IS_EDGE(conn) && TO_EDGE_CONN(conn)->edge_blocked_on_circ)); + conn->state == EXIT_CONN_STATE_RESOLVING) || + connection_is_writing(conn) || + conn->write_blocked_on_bw || + (CONN_IS_EDGE(conn) && + TO_EDGE_CONN(conn)->edge_blocked_on_circ)); } if (conn->hold_open_until_flushed) diff --git a/src/or/relay.c b/src/or/relay.c index 17ce7db..81a6497 100644 --- a/src/or/relay.c +++ b/src/or/relay.c @@ -1031,9 +1031,9 @@ connection_edge_process_relay_cell(cell_t *cell, circuit_t *circ, relay_header_t rh; unsigned domain = layer_hint?LD_APP:LD_EXIT; int reason; - int optimistic_data = 0; /* Set to 1 if we receive data on a stream - that's in the EXIT_CONN_STATE_RESOLVING - or EXIT_CONN_STATE_CONNECTING states.*/ + int optimistic_data = 0; /* Set to 1 if we receive data on a stream + * that's in the EXIT_CONN_STATE_RESOLVING + * or EXIT_CONN_STATE_CONNECTING states. */ tor_assert(cell); tor_assert(circ); @@ -1055,16 +1055,16 @@ connection_edge_process_relay_cell(cell_t *cell, circuit_t *circ, if (conn && !connection_state_is_open(TO_CONN(conn))) { if (conn->_base.type == CONN_TYPE_EXIT && - (conn->_base.state == EXIT_CONN_STATE_CONNECTING || - conn->_base.state == EXIT_CONN_STATE_RESOLVING) && - rh.command == RELAY_COMMAND_DATA) { - /* We're going to allow DATA cells to be delivered to an exit - * node in state EXIT_CONN_STATE_CONNECTING or - * EXIT_CONN_STATE_RESOLVING. This speeds up HTTP, for example. */ - optimistic_data = 1; + (conn->_base.state == EXIT_CONN_STATE_CONNECTING || + conn->_base.state == EXIT_CONN_STATE_RESOLVING) && + rh.command == RELAY_COMMAND_DATA) { + /* Allow DATA cells to be delivered to an exit node in state + * EXIT_CONN_STATE_CONNECTING or EXIT_CONN_STATE_RESOLVING. + * This speeds up HTTP, for example. */ + optimistic_data = 1; } else { - return connection_edge_process_relay_cell_not_open( - &rh, cell, circ, conn, layer_hint); + return connection_edge_process_relay_cell_not_open( + &rh, cell, circ, conn, layer_hint); } }

1 0

[tor/master] Merge remote branch 'arma/optimistic_server'
by nickm＠torproject.org 15 Mar '11

15 Mar '11

commit 415caba967b9b470623ab29230b820b3470a91e6 Merge: 737228e c277519 Author: Nick Mathewson <nickm(a)torproject.org> Date: Tue Mar 15 17:20:41 2011 -0400 Merge remote branch 'arma/optimistic_server' changes/prop174_server | 6 ++++++ src/or/connection.c | 19 ++++++++++++++++--- src/or/relay.c | 29 +++++++++++++++++++++++++---- 3 files changed, 47 insertions(+), 7 deletions(-)

1 0

[tor/master] Merge remote branch 'origin/maint-0.2.2'
by nickm＠torproject.org 15 Mar '11

15 Mar '11

commit 737228ed8e81de6619a29bd039d08d959d4164da Merge: 4dde69a c5ffd44 Author: Nick Mathewson <nickm(a)torproject.org> Date: Tue Mar 15 17:18:29 2011 -0400 Merge remote branch 'origin/maint-0.2.2' changes/bug2756 | 11 +++++++++++ src/or/connection.c | 2 ++ src/or/connection_edge.c | 17 +++++++++++++++++ src/or/connection_edge.h | 1 + src/or/relay.c | 5 +++-- 5 files changed, 34 insertions(+), 2 deletions(-)

1 0

[tor/master] Merge branch 'bug2756_relay' into maint-0.2.2
by nickm＠torproject.org 15 Mar '11

15 Mar '11

commit c5ffd44ccd3c60780143eb384938276522a173c1 Merge: ab41844 a86e27c Author: Nick Mathewson <nickm(a)torproject.org> Date: Tue Mar 15 17:13:07 2011 -0400 Merge branch 'bug2756_relay' into maint-0.2.2 changes/bug2756 | 11 +++++++++++ src/or/connection.c | 2 ++ src/or/connection_edge.c | 17 +++++++++++++++++ src/or/connection_edge.h | 1 + src/or/relay.c | 5 +++-- 5 files changed, 34 insertions(+), 2 deletions(-)

1 0

[tor/master] Consider sending stream-level SENDME cells on partial flushes.
by nickm＠torproject.org 15 Mar '11

15 Mar '11

commit 1d36a8e9ae766f67097f4c5e522c33ff0c4a693f Author: Nick Mathewson <nickm(a)torproject.org> Date: Mon Mar 14 17:48:45 2011 -0400 Consider sending stream-level SENDME cells on partial flushes. Right now, we only consider sending stream-level SENDME cells when we have completely flushed a connection_edge's outbuf, or when it sends us a DATA cell. Neither of these is ideal for throughput. This patch changes the behavior so we now call connection_edge_consider_sending_sendme when we flush _some_ data from an edge outbuf. Fix for bug 2756; bugfix on svn r152. --- changes/bug2756 | 11 +++++++++++ src/or/connection.c | 2 ++ src/or/connection_edge.c | 17 +++++++++++++++++ src/or/connection_edge.h | 1 + 4 files changed, 31 insertions(+), 0 deletions(-) diff --git a/changes/bug2756 b/changes/bug2756 new file mode 100644 index 0000000..0cad515 --- /dev/null +++ b/changes/bug2756 @@ -0,0 +1,11 @@ + o Minor bugfixes (spec conformance, performance): + - We now ask the other side of a stream (the client or the exit) + for more data on that stream when the amount of queued data on + that stream dips low enough. Previously, we wouldn't ask the + other side for more data until either it sent us more data + (which it wasn't supposed to do if it had exhausted its + window!) or until we had completely flushed all our queued + data. Fixing this should improve throughput. Fixes bug 2756; + bugfix on the earliest released versions of Tor (svn commit + r152). + diff --git a/src/or/connection.c b/src/or/connection.c index fd30ac8..86ed45e 100644 --- a/src/or/connection.c +++ b/src/or/connection.c @@ -3245,6 +3245,8 @@ connection_flushed_some(connection_t *conn) r = connection_dirserv_flushed_some(TO_DIR_CONN(conn)); } else if (conn->type == CONN_TYPE_OR) { r = connection_or_flushed_some(TO_OR_CONN(conn)); + } else if (CONN_IS_EDGE(conn)) { + r = connection_edge_flushed_some(TO_EDGE_CONN(conn)); } conn->in_flushed_some = 0; return r; diff --git a/src/or/connection_edge.c b/src/or/connection_edge.c index f02479f..85a5225 100644 --- a/src/or/connection_edge.c +++ b/src/or/connection_edge.c @@ -301,6 +301,23 @@ connection_edge_end_errno(edge_connection_t *conn) return connection_edge_end(conn, reason); } +/** We just wrote some data to <b>conn</b>; act appropriately. + * + * (That is, if it's open, consider sending a stream-level sendme cell if we + * have just flushed enough.) + */ +int +connection_edge_flushed_some(edge_connection_t *conn) +{ + switch (conn->_base.state) { + case AP_CONN_STATE_OPEN: + case EXIT_CONN_STATE_OPEN: + connection_edge_consider_sending_sendme(conn); + break; + } + return 0; +} + /** Connection <b>conn</b> has finished writing and has no bytes left on * its outbuf. * diff --git a/src/or/connection_edge.h b/src/or/connection_edge.h index fa5f91c..0b08dd0 100644 --- a/src/or/connection_edge.h +++ b/src/or/connection_edge.h @@ -23,6 +23,7 @@ int connection_edge_process_inbuf(edge_connection_t *conn, int connection_edge_destroy(circid_t circ_id, edge_connection_t *conn); int connection_edge_end(edge_connection_t *conn, uint8_t reason); int connection_edge_end_errno(edge_connection_t *conn); +int connection_edge_flushed_some(edge_connection_t *conn); int connection_edge_finished_flushing(edge_connection_t *conn); int connection_edge_finished_connecting(edge_connection_t *conn);

1 0