Projects/Replay cache improvements
The current implementation has the following possible issues with correctness:
- Existing race condition when creating (or replacing on corruption). [krbdev.mit.edu #3498]
- Possible file corruption due to lack of locking and not using O_APPEND [krbdev.mit.edu #1671]. Probable mechanism is two processes nearly simultaneously writing at the same file offset, which will cause overlapping writes unless O_APPEND is set.
- Once a replay cache handle is open, entries written by other processes will not be detected.
- If another process does an expunge, the current process will not notice, and will continue to write entries to an unlinked file.
- Use of fsync() can cause performance problems. [krbdev.mit.edu #372]
- Fix the file creation race somehow
- Start using O_APPEND and detect when other processes have written entries
- Detect expunges by other processes
- Start using file locking
- New file-based replay cache, possibly hash table based
- IPC-based replay cache for higher performance
- Revise protocols to not require replay caches for security