Prop 110 revisions
nickm at freehaven.net
Fri Aug 24 01:31:13 UTC 2007
On Wed, Aug 22, 2007 at 08:17:02PM -0600, mrwigglet wrote:
> Sorry if this starts a new thread, I hadn't yet joined the or-dev list
> so I couldn't just hit 'reply'. Anyhow, I just have a few questions
> so that I can hopefully get the patches right for this. Question 1 is
> what exactly you guys want the behavior to be, either the way Nick
> outlines it or the way it is in 'additional complexity'.
I don't think we've actually decided for sure yet; we'll probably
argue for a while and choose something. :)
> Second is
> what the naming should be, RELAY_EARLY or something else.
> Third question
> is about where to put the two fields. Moving the counter for seen
> extend cells to or_circuit_t is fine, but I'm not sure the other can
> be moved to origin_circuit_t. The reason is that the only place I
> can find that the CELL_RELAY type is set is in relay_send_command_from_edge
> and the type of circuit in that function is circuit_t not
This will probably depend on which implementation we wind up doing.
If RELAY_EXTEND cells only originate from the client, then the counter
can go into origin_circuit_t, since every client circuit is an
origin_circuit_t. If other nodes in the circuit decide to sometimes
originate RELAY_EXTEND cells (as they do in the migration phase in my
half-backed idea in my last email in this thread), then everybody
needs a count.
As for implementation. Every origin_circuit_t is also a circuit_t;
use the CIRCUIT_IS_ORIGIN() macro to test whether a circuit_t is an
origin_circuit_t, and use TO_ORIGIN_CIRCUIT() to convert a circuit_t
into an origin_circuit_t. When sending a command from the client
side, you would check and maybe send a RELAY_EXTEND. When sending a
command from the exit side of a circuit, you would never send a
RELAY_EXTEND, since they aren't supposed to travel in that direction.
> So if you could let me know what way that should be handled that'd be great.
> Also, whether or not you guys think this should go along with another
> proposal (105 or other). Other than these few things I think I know
> what is needed so hopefully we can work it all out.
Cool! Sorry for the indecisiveness here; I really wish we had this
all designed well ahead of time. :/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 652 bytes
Desc: not available
More information about the tor-dev