This is not *entirely* related, but I'm typing it here before I forget,
which can happen quite suddenly at times! My question is: I've picked
up that Tor compression has been considered, at least in passing,
before. What algorythms were considered? Just gzip or something else?
I've used Guttman and VanSomebodyOrOther algorythms, at least in the
context of ethernet frames/TCPIP and it gains about 8-10x more
throughput on avarage. The problem is that they require all the routers
in the path to actually support compression, which doesn't often
happen.
I guess the bottom line here is: Can plain old generic SSL be
compressed, or is that functionality specific to the SSh toolset itself
and not the SSL protocol proper?
~Andrew
Roger Dingledine wrote:
On Tue, Aug 30, 2005 at 04:06:27PM -0700, Tor Operator wrote:
I submitted a bug to the torcp bugtracker about the
AllowUnverifiedNodes setting, but wasn't sure what the correct syntax
would be for allowing no unverified nodes.
Is it just "AllowUnverifiedNodes "on a line by itself for none? I
tried "AllowUnverifiedNodes None" and "AllowUnverifiedNodes Null",
but tor doesn't like any of those lines. It accepts
"AllowUnverifiedNodes ", but I don't know if that just reverts to the
default of "middle, rendezvous" or does it actually mean none.
Thanks for spotting this bug.
In the upcoming 0.1.1.6-alpha release, there will be a new controller
command "RESETCONF AllowUnverifiedNodes" which will return it to its
default ("middle,rendezvous").
The command "SETCONF AllowUnverifiedNodes" will set it to "".
You will also be able to set it to "" in your torrc by putting the
line "AllowUnverifiedNodes" by itself in your torrc.
Thanks,
--Roger
|