First, four high level comments. Then detailed section-by-section
comments. Since this set of comments has ended up getting long, and
since I am cc'ing the mailing list, I will break this into five
messages (each of the high level comments + detailed comments) to make
a threaded discussion more managable.
BTW, anyone interested in this discussion may also want to look at a
draft a group of colleagues and I at UT just completed:
http://www.cs.utexas.edu/users/dahlin/papers/olympics-consistency.pdf
It is a first draft, so there are some rough edges. We also would
appreciate any feedback (send them to me please, they probably
don't need to go to this mailing list, although you are welcome to send
comments here too...).
-mike
High level comments (notes.11.20.2000b.txt --
draft-danli-wrec-wcip-00.txt)
-------------------
1. The "channel lifetime" parameter seems unnecessary. It is not
required for semantics. And, given that it is a performance
optimization, I'm not sure it has the right definition.
In particular, the mechanism for the server to release state is there:
a server (or client) can release the TCP connection at any time
(From earlier mail on this point Dan Li writes:)
>>>> just to clarify, "client must periodically re-register" is when
the
"channel lifetime" expires and the iserver is about to release the state
of
the client. The client should better re-register before the channel
expires.
>>>> but I think you are probably right that this is not really needed.
If
the iserver wants to release the state, it can simply close the
connection.
Perhaps we'd provide a message for the iserver to indicate it's about to
drop the connection, or it's about to drop the targeted service, etc.
>>>> then what about "channel lifetime" which now gives the iserver a
way
to cut out the channel. ...
An alternative is to eliminate the signalling as a mechanism. An
example policy that we've simulated: a server keeps a per-client
"last-contact-time" that is updated whenever a client registers a new
object callback. The server disconnects from a client when this time
is X seconds in the past.
This is appealing for two reasons. First, it makes the protocol
simpler by getting rid of a message type. Second, it does not
prescribe a particular policy: servers can drop connections using time
as I just described, they can keep a fixed number of connections and
drop them with LRU,FIFO, or random. A fixed number of connections may
be attractive for scalability/bounding worst case performance.
The main disadvantage, probably, is that we make refreshing this
interval implicit rather than explicit. (I can see an argument either
way on this point.)
Another point (whether it is a disadvantage or advantage is a matter
of taste) is that if the server uses a LRU or time-based replacement
protocol, a client can refresh its interval (to avoid getting dropped)
by periodically renewing its lease for "/". This is either an ugly
hack or an elegant extension of the protocol...
I don't feel terribly strongly either way, but my inclination would be
toward the simpler protocol unless there is a strong reason to add a
new message.
This archive was generated by hypermail 2b29 : Thu Nov 18 2004 - 11:21:29 MST