> i was trying to point out that if you try to > ignore the issue by removing flush from the > protocol, you'll get a system that doesn't work so smoothly.
your failure cases seem to rely on poorly chosen tags. i wasn't suggesting that flush be eliminated. i was thinking of ways of keeping flush self-contained. if the tag space were enlarged so that we could require that tags never be reused, flushes that do not flush anything could be remembered. the problem with this is it could require a large memory of unprocessed flushes. there are lots of potential solutions to that problem. one could allow the server to stall if too many martian flushes were hanging about and allow clients to declare they will reuse part of the tag space and asserting that nothing within reused portion is outstanding. you could then keep the current definition of tag, though 16 bits seems a bit small to me. - erik
