architectural proposal & technical problems

[Nick Mathewson]

On Tue, May 01, 2007 at 10:28:00PM +0200, Johannes Renner wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Roger Dingledine wrote:
> > I just added a new config option __DisablePredictedCircuits that
> > should do what you want ..
> > It simply doesn't build the preemptive "extra" circuits, so you don't
> > have random circuits appearing. Is this what you had in mind?
> 
> Yes, that's exactly what I had in mind, thank you for introducing
> this option. Maybe other developers of controllers will also be
> glad to be able to switch this off to take over the construction
> of circuits for client-use.
> 
> BTW: Where can I find a list of all of the "special" config options
> that start with __*? Just to find out if there are more of them that
> could be useful for my purposes, but I don't know about yet?

I just documented them in section 5.4 of control-spec.txt.  Thanks for
the reminder!

> Nick Mathewson wrote:
> > I guess we could have a controller feature that let you set extra
> > flags values in descriptor.  For safety, we'd probably want them to
> > start with "X-", like extension headers in email or http.
> > There is an accepted proposal in progress of implementation that has a
> > separate "extra info" document containing data that most users don't
> > care about. Check out proposal 104 for more info on that.
> 
> That sounds good, I also think that this would be useful for everyone.
> If we had such extra flags, we should eventually also be able to set
> (and reset) them via a controller.

I'll put this stuff in, then.  I think it's small enough not to need a
separate proposal.  I've added a note to dir-spec.txt about it, and
I'll try to get to implementing it all afternoon.

> > For a while, we've been meaning to have _all_ routers, even routers
> > that aren't directory caches, accept BEGIN_DIR commands to retrieve
> > a limited amount of directory information via Tor connections.
> > Caches would serve everything that they would serve normally;
> > non-caches would only serve their own descriptor.
> > Given this, I think you could just make any bandwidth information
> > that you decide it's important to serve a separate document served
> > this way.
>
> I'm not sure if I understood this right. How can you serve a separate
> document with this if you get either a single descriptor or the complete
> network-status document? Do you mean instead of the descriptor in case
> of a non-proxy?

Err, let me rephrase:
  - It may soon be possible to have Tor servers serve descriptor-like
    documents via Tor whether they are directories or not.
  - The underlying protocol is HTTP, so it is easy to add new URLs.
  - If you want to serve a new kind of information, the easiest way
    could be to have that information served at a new URL, rather than
    at a new port.

Though actually, if (as you say) the idea is to have it be
experimental for now to figure out what works, it could be just as
easy to have a separate port for it for the moment.  I don't think I
can form much more of an opinion here until we know more about what's
in the documents, and what's in your actual design.

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/20070503/3bd0c3c6/attachment.pgp>