On Sat, Feb 12, 2005 at 05:36:40PM -0600, Mike Perry wrote:
> So I'm considering trying to hack conn->outbuf to be a priority queue
> based on the idea I presented in
> http://archives.seul.org/or/talk/Feb-2005/msg00042.html. I'm thinking
> that the best place to implement this is by modifying
> connection_write_to_buf and connection_handle_write to use a priority
> queue (or maybe four or five buckets) for conn->outbuf instead of
> doing the memcpy and sending the whole thing at once.
>
> Relay cells could be dispatched by the priority encoded in the length
> field, and all other traffic can be given a priority as high as or
> higher than interactive relay traffic.
This sounds like a good idea, and I'd like to see how it would work in
practice. Here are some possible issues with your actual proposal:
- You'd want to put the information into the priority queues
_before_ you encrypted it, since you can't re-order the relay cells
in a circuit once they're encrypted.
- Using the high bits of the length field will probably not work;
remember, they are encrypted and decrypted along with the rest
of the body of the relay cell, so the intermediate servers won't
see them. Maybe it would make more sense to have specific
circuits have QoS set, rather than doing it at the cell level.
- There are probably anonymity issues here that need to get
thought about.
> So is this patch desired? Does the tor project even accept patches? It
> seems I'm not getting much feedback to my offers to help.. If my past
> patch or this idea is lacking in some way, please don't hesitate to
> let me know what I could do to meet your standards.
Sure, we accept patches, and do so often. One issue is that we get
way more design ideas than we get patches, so we don't always assume
that people are going to work on their designs. If you want to get a
significant design feature into the main tor distribution, it's
usually a good idea to submit a patch to tor-spec.txt first, so we can
talk about the actual details of the design before you spend too much
time on the implementation.
So by all means, please feel free to lend a hand! We're not ignoring
you; we're just very very very hosed. :)
Hope this helps,
--
Nick Mathewson
Attachment:
pgp3kZwOsYzXX.pgp
Description: PGP signature