On Mon Mar 06 12:01 2000 -0500, Chris Calabrese wrote:
> > I definitely agree that the verification mechanism should have as
> > little impact on performance as possible. It might be useful to
> > mention some possible mechanisms for accomplishing this (either here
> > or in the "Resource Utilization Considerations" section), such as an
> > ACK window size determined in the handshaking phase.
>
> I disagree. This is a requirements document.
> Implementation considerations of this level
> belong in a different document.
That makes sense. I wasn't thinking about the context when I wrote
that. :)
> > I'm not sure what you mean by saying that the verifyable delivery
> > mechanism doesn't need to be "perfectly accurate". It seems to me
> > that if it's not accurate, it doesn't do any good.
>
> Proper guarantee of exactly one copy of
> every message is very difficult and expensive
> (two phase commit with roll-back and that
> sort of stuff). It's also not necessary for system
> logs, IMO.
[...]
OK, now I see what you mean. I agree that preventing duplicate
messages isn't a priority. I was thinking of "perfectly accurate" in
terms of verifying that at least one copy was delivered, rather than
as a reference to not guarunteeing the absence of duplicate messages.
This probably boils down to a semantic argument. :)
> The problem is that an ACK window size
> of 1 is a real performance killer, and you don't
> want your service to shut down just because
> messages are getting generated just a little bit
> faster during peaks than your log server can
> handle them when it's still much slower on average.
>
> Also, only a very few messages sent by a very
> few applications have the TSEC requirement
> to cause a server shutdown, so you definitely
> don't want to set the entire stream to require
> instant ACKing.
>
> Instead, I think the mechanism I described above
> is the best. This way, applications can block
> if they want to, but the overall stream keeps moving.
Oh, so you're saying that the application CAN request an immediate
ACK, but doesn't HAVE to. Re-reading the relevant section now, I see
that it does say that the protocol "should not require" senders to
wait for the ACK. It might be a good idea to also explicitly state
that the protocol should allow the sender to request an immediate ACK,
subject to whether the server is configured to allow it.
Anyway, sorry for the confusion. That's what I get for responding to
something on a Sunday morning. ;)
--
Mark D. Roth <[EMAIL PROTECTED]>
http://www.feep.net/~roth/
