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
Attachment:
pgpaIdzgubpQL.pgp
Description: PGP signature