Wanted feature / option

[Kyle Williams]

I was testing a spam-reply script and or-talk at freehaven.net got into it
somehow.

My bad, sorry.

On 5/29/07, Kyle Williams <kyle.kwilliams at gmail.com> wrote:
>
> FIRST AND FINAL WARNING!!!!
> You have 48 hours to remove me from your mailing list.
> If you do NOT remove me, I will DDOS (Distributed Denial of Service) your
> server until you are broke.
>
> Try me, I got 10 OC192's, 15 OC48's, and 8 OC12's just waiting for shit
> like this...and I'm getting pissed.  If you are working for yourself or some
> spam king, either way the "customer" who is paying you to "advertise" will
> NOT be happy when they spent their money to be only be attacked in return.
>
> Remove me or else I remove your source of revenue.
>
> Again, FIRST AND FINAL WARNING!!!!
>
> Have a nice day and get a real fucking job.
>
>
> On 5/26/07, Michael_google gmail_Gersten <keybounce at gmail.com> wrote:
> >
> > I finally realized what feature I'd like to see.
> > CircuitMinimumBandwidth.
> >
> > Have a config option to tell Tor how much CPU time it can expect to
> > give to processing onions (which will tell it how many active
> > connections it can handle) (Or tell it directly how many active ones
> > it can handle).
> >
> > Tor knows the total bandwidth it has to use.
> > There's good heuristics for telling how much bandwidth a connection
> > will need. (Most will need a high initial push, and then occasional,
> > intermittent spikes; if a connection needs a lot for more than <N>
> > seconds, it's likely to need a lot for a while longer. Etc.)
> > There's a way to tell when the CPU limit will prevent any more data
> > transmission.
> >
> > Combined, this would allow a node to refuse non-specific node requests
> > (normal circuits would be blocked if the tor server is busy, but a
> > ".node.exit" would still be allowed).
> >
> > This would also eliminate any perceived "slowness" of tor -- no longer
> > would I see 22 MB nodes in my path, yet dialup users could still use
> > them. If I have a 1300 MB node in my path, I know it can handle my 150
> > request, and not be either so swamped that I'm only seeing 15, or so
> > overloaded that it's past it's CPU limit. Equally, I know that I can
> > tell tor (without having to use "nice") not to steal all my CPU while
> > I'm using my computer.
> >
> > Potential problems? What would we do if we could not find a viable
> > circuit? What if every node is asked and reports "Busy" -- how do we
> > tell the user that "Tor is full", or should a lowspeed connection be
> > made anyways?
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-talk/attachments/20070529/cf448de9/attachment.htm>