| |
David Eaton wrote:
>
> In lugnet.market.theory, Frank Filz writes:
> > The car analogy isn't perfect. One thing they can do is not respond to
> > more than one query per second or some such from a given IP address,
> > though that would screw companies with firewalls.
>
> 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).
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).
> > 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.
FUT lugnet.off-topic.debate
--
Frank Filz
-----------------------------
Work: mailto:ffilz@us.ibm.com (business only please)
Home: mailto:ffilz@mindspring.com
|
|
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
|
|
|
|
