> Next, who's master of how big the difference between received and ACK'd
> messages ? If I buffer ~1000 messages before calling fsync(), locally,
> do I want to have some remote daemon telling me I must commit after every
> message, making the buffer 1 and killing my performance ?
This would, ideally, be configurable locally but not remotely.
The bottom line is there's not really any way to guarantee delivery. You
could have a buffer as big as a new hard drive but if your WAN link went
down for several hours or days you'd have to delete the queue at some
point.
The question is how much should be done to re-attempt delivery. A
lightweight protocol would simply note that the remote site has not ACKed
and queue a single "X messages dropped" message.
A more heavyweight protocol would do some buffering, preferably a
configurable amount, but would also need to deal with the problem
above when a remote loghost was unavailable for longer periods.
Personally, I vote for the lightweight protocol. Add too many bells
and whistles and the risk that admins won't learn them increases
exponentially. SNMPv2, CMIP, ATM, X.400, X.500, and BGP are a few
examples.
--
Roger Marquis
Roble Systems Consulting
http://www.roble.com/
