| |
In lugnet.off-topic.geek, Frank Filz writes:
> David Eaton wrote:
> > Well, assuming the theory works, yes, you could say no more than 10 calls
> > per second or something, but perhaps a better approach would be to make it
> > smarter-- if someone makes 10 calls per second or something, their IP gets
> > put on a "watch out" list-- and if they keep it up for more than 5 minutes
> > or something, you can be pretty sure that it's some sort of automated thing
> > calling pages, and prevent connections from that site...
> >
> > Of course, that brings up my question on this issue-- wouldn't that method
> > still not work? In order to reject the query at all, you'd need to know
> > something about the query itself (the IP address or cookie data or
> > something), so you need to examine each query... hence, making 1,000 calls a
> > second, you still need to examine each call, meaning you're still getting
> > your CPU pinned, just not as much as if you accepting and performing each
> > call... But then again, this would all probably be a webserver issue, and
> > I'm not too sure about how much they can take in that regard... anyway,
> > that's my uniformed concern...
>
> Well, it could be handled on a very gross basis by the router/firewall.
> If it keeps track of the top IP sources of packets, it can just start
> discarding packets from certain IP addresses. It could also recognize
> large company firewalls to reduce the possibility of starting to ignore
> IBM or something like that (of course it would need something to protect
> against spoofed traffic).
Yep, that sounds like exactly what I'd want to do-- keep tabs on who's sending
the most requests and if they look suspicious, deny them access, rather than
have a flat "no more than X transactions per Y time", seeing as how you might
get random spikes here and there (especially with firewalls)... hence continued
activity picks up as dangerous and is stopped, and there's less chance of
blocking bona fide users...
> But the problem in eBay's case is that the querys take a lot of
> processing time, if the requests were rejected earlier, it might add
> some small overhead to each request, but block those expensive querys.
> Another thing which would help is to cache queries (if you cached them
> for say 5 seconds, you would essentially not affect the user making the
> query since the data isn't going to be very stale).
Ok, as long as the problem is performing the queries themselves rather than the
numerous connections getting instantiated, then there shouldn't be any problem
whatsoever with the above (at least from my still rather uninformed
perspective)
> > > What we need to do very soon is start charging per packet. It could be
> > > kept very cheap, but that would trim SPAM and most of these denial of
> > > service activities.
> >
> > Eww! I wouldn't want to pay for HTTP requests I send out, etc... perhaps I
> > would suggest paying on excessive packets (if your packets exceed X per day,
> > you pay for 'em or something) But then you'd have to work that out with
> > ISP's etc...
>
> Why shouldn't you have to pay directly for the bandwidth you use? Right
> now, almost everyone who is paying $19.95 per month is subsidizing the
> SPAM. This is an extremely good example of the problem with shotgun
> approaches (like taxes) to pay for things. There is NO incentive for
> people to conserve bandwidth, so SPAMers SPAM, people quote entire news
> articles or e-mails to say "I agree" or "me too", etc. Bandwidth is not
> free. It is close to it, but not free.
Well, you're in essence correct in that bandwidth should be charged for, but I
just don't like the per-packet idea... I think that per-packet charges should
come in only for those who "need" it, or those who abuse it (as a fine, rather
than a service) My only real issue on this is that people in general (myself
included, certainly) make a lot of repeated clicks, etc... I go out and reload
a page (Netscape does it automatically sometimes) very frequently.. or I'll
click around a whole lot, back to pages I've already seen for reference, etc.
Charging per-packet means I'd be paying for those casual random clicks, despite
the fact that I'm not really causing a problem or anything... and hence I don't
want to pay for it (like any red-blooded American! :) )... Instead I like the
idea of paying for excessive bandwidth-- hence, you can charge people who try
and overload sites, people who send excessive amounts of spam, etc... Of course
major servers would be expected to pay more, and things like AOL would have to
keep track of it, but then again, they're perfectly welcome (even at present)
to charge whatever they want for individual packets.... Anyway, that's my
general feeling, based on the American dream of getting something for nothing,
but hey, I can still want it, right? That's why they call it the American
"dream"!
DaveE
|
|
Message has 2 Replies:
 | | Re: eBay nailed?
|
| Charging per packet, and blocking packets both sound good in practice, and I support them in theory. They are problematic though, the way the internet is currrently engineered. Packet headers are too easy to spoof. The internet is built on the (...) (25 years ago, 9-Feb-00, to lugnet.off-topic.debate)
| | | Re: eBay nailed?
|
| (...) I don't think your random clicks will be a problem when time comes to charge per packet. I expect that the rates will be so miniscule that casual browsing will be free (the problem might be that it won't do enough to spam because it won't cost (...) (25 years ago, 9-Feb-00, to lugnet.off-topic.debate)
|
Message is in Reply To:
| | Re: eBay nailed?
|
| (...) Well, assuming the theory works, yes, you could say no more than 10 calls per second or something, but perhaps a better approach would be to make it smarter-- if someone makes 10 calls per second or something, their IP gets put on a "watch (...) (25 years ago, 9-Feb-00, to lugnet.market.theory)
|
13 Messages in This Thread:
 
  
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
