[PING][MERGE] Waiting on locks

[Matthieu Moy]

John Arbash Meinel <john at arbash-meinel.com> writes:

> I agree, though I would include a maximum delay. Possibly something like
> 1/min or maybe 1/5min. I wouldn't want the delay inbetween to grow
> without bound.

Depending on other factors, but the bound is anyway half the timeout.

>> Additionnaly, there might be some firewall qos policy that blacklists
>> the client temporarily if it does repeated attempts. For example, my
>> french lab's firewall does "if an ip connects more than 5 times in a
>> minute, block it for one minute (and any retry extends the block
>> period)". So, any sufficiently stupid brute-force attack is blocked
>> forever, but still, nmap can scan the machine (because it has a
>> strategy of not retrying too often when it sees it's locked).
>
> Well, then bzr is already going to have a hell of a time going through
> this firewall anyway.

I was giving this as an example, but I don't have any problem with it
(It's for the ssh access, and the connection is established only once
anyway).

To make it short: repeated attempts with a small period is the
behavior of an attacker, and we shouldn't do that ;-)

> Yeah. With the LockDir format, we can peek() at the contents of the
> lock, which should tell us who has the lock. This also brings a big
> point about wanting to cap the maximum time between attempts. Because if
> you do have a heavily loaded server, I think we might want to reset the
> time inbetween queries whenever the lock changes hands.

I'd say "make it smaller", but maybe not as small as the first
attempt. If you missed the window between two request, it's a sign
that there is already a queue, and that you should be nice with your
server.

-- 
Matthieu