[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: Wanted feature / option



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@xxxxxxxxx> wrote:
I was testing a spam-reply script and or-talk@xxxxxxxxxxxxx got into it
somehow.

My bad, sorry.



On 5/29/07, Kyle Williams <kyle.kwilliams@xxxxxxxxx> 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@xxxxxxxxx> 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?
> >
>
>