this is a good idea. 16k might be even better if it worked reliably
(the usual default is 32 to 64k).
Your information might be somewhat obsolete...
Have a look at my machine (a pretty ordinary recent Linux) connecting
to tor.eff.org:
lanthane.45747 209.237.230.67.www: SWE
On 7/13/07, coderman [EMAIL PROTECTED] wrote:
... updated constrained socket buffers patches:
i've updated the previous patches once again:
- provide a warning when DirPort is set and this option is enabled.
providing cached directory entries exacerbates the TCP buffer resource
contention.
-
On Fri, Jul 13, 2007 at 03:44:49AM +0200, Juliusz Chroboczek wrote:
I'd like to know how this will interact with tor's circuit selection.
Good question. The first answer is it won't change it at all,
but you're right, it may be more complex than that.
If I understand this patch correctly, it
Now the throughput (``bandwidth'') of a TCP connection is limited by
window/rtt. What this means is that with ConstrainedSockets enabled,
your tor server will have basically unlimited throughput on a local
connection, but be limited to roughly 40 kB/s per connection (that's
bytes, not bits)
On 7/13/07, Juliusz Chroboczek [EMAIL PROTECTED] wrote:
...
There is another issue, which doesn't appear in the above. TCP is
extremely sensitive to packet loss when the window is smaller than
4 packets (fast retransmit doesn't work in that case). So could
I suggest a default value for
attached is the constrained sockets patch.
I'd like to know how this will interact with tor's circuit selection.
If I understand this patch correctly, it sets the SO_SNDBUF and
SO_RCVBUF socket options so as to limit the maximum size of the TCP
send and receive windows respectively.
Now the
hi Andrew, all,
attached is the constrained sockets patch. apologies for the delay;
still have DSL problems at home.
to enable this feature set:
ConstrainedSockets 1
in your configuration. this will limit the recv and xmit buffers
associated with TCP sockets to the default 4096 bytes. you
7 matches
Mail list logo
