[ic] Possible bug: Too many new ID assignments for this IP address
list_subscriber at yahoo.co.uk
Wed Aug 24 17:47:42 EDT 2005
On Wednesday, August 24, 2005 10:18 PM, mike at perusion.com wrote:
> Quoting John1 (list_subscriber at yahoo.co.uk):
>> On Wednesday, August 24, 2005 5:57 PM, mike at perusion.com wrote:
>>> Should not happen. Since you don't assign a new session, and the
>>> counter gets incremented only at that time, after an hour of no new
>>> session you can get one.
>> But, what I am saying is that it appears that all UK AOL customers
>> appear at our server on only a handful of IP addresses, i.e. the IP
>> addresses of their proxy servers (and similarly for the major cable
>> operator NTL).
> That doesn't matter -- NONE of them will get a new session from that
> IP, so at the end of the hour they are back in.
> Unless you can show me in code how the counter will get incremented
> from that IP address, I am done with this.
As I confessed in my last post I wasn't thinking straight on one account - I
was thinking that the mtime would still be updated even when the request for
a new sessionid was denied. But, I now understand that mtime will remain
untouched during the lockout period.
So I now see that the lockout will end after time robot_expire.
However, as AOL and NTL implement a NAT proxy set up it does mean that your
suggestion of a low "limit robot_expire" (in conjunction with say RobotLimit
of say 100) is essential for moderately busy sites.
I am trying a limit robot_expire 0.002 as you suggest - Hopefully this will
be sufficient as you say, but I will let you know if I still get lockouts
appearing in the error log.
Sorry if it's taken me a while to realise this solution should work.
More information about the interchange-users