Derek Price wrote:
One thought is to combine my original idea with #3 above, so that the
server hands out sequence-ids with every connection but decrements the
max-sequence-id counter when a client disconnects without using the id
for a commit. This would require a little bit of complex code including
locks, DBM use, and additional cleanup handlers, but should be doable
and fairly fast on the server end.
One fly in this ointment is how to handle overlapping operations, e.g.:
client A connects
server issues sequence-id 1
client B connects
server issues sequence-id 2
client A starts a read-only op
client B starts commit
client B ends commit
client A ends its operation
Sequence ID 1 is unused, but 2 is used, so the server can't decrement
the counter. It wouldn't be too difficult to mount a DoS attack on this
scenario.
I suppose there probably won't be more than a few (dozen? hundred?)
users accessing the repository simultaneously, so it shouldn't be _too_
difficult to keep track of unused ids. And, of course, this means the
numbers won't necessarily be sequential.
Another possibility would be to add a new request/response command to
the protocol, so a client explicitly requests a commit id. OTOH, this
is, if anything, even more vulnerable to a DoS attack.
How does CVSNT generate its commit-id?
<sigh> Why can't people just play nicely together? :=)
--
Jim
_______________________________________________
Bug-cvs mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/bug-cvs
