Prop 110 revisions

[Nick Mathewson]

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.

Ditto.

>  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
> origin_circuit_t.

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. :/

peace,
-- 
Nick Mathewson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 652 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20070823/9711022a/attachment.pgp>