Wanted feature / option

[Ringo Kamens]

That was hilarious. Even though I shouldn't condone activity like
that, I laughed about that message all day.
Thanks
Comrade Ringo Kamens

On 5/29/07, Kyle Williams <kyle.kwilliams at gmail.com> wrote:
> 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?
> > >
> >
> >
>
>