3. I would suggest adding a separate subsection about reconnection in
section 3. This would provide a place to talk about a bunch of the
subtle issues all in one place: first connection, reconnection,
incremental connection, using legacy headers while waiting for
connection, ...
Some additional features to optimize reconnection may be warranted.
(3.1)
First, I think it is worth stating precisely the per-object FSM:
(In writing this, I'm catching some bugs in my understanding at least;
I suspect other people might also benefit from explicitly including
this in the draft.) I would bet that at least some one in this
discussion will say "I don't think it works like you described" and
they might be right; either way, this would be an indication that it
is worth writing it down so we can argue about how it works in
concrete terms...
Each object has two parts to its state:
1) Synchronization established/lost for object --> are we guaranteed
to receive an invalidation if the current version of the object changes?
2) Current version cached/not cached --> a version of the object is
cached that may be current (no invalidations have been received for
it). If the synchronization is established, then it IS current;
otherwise, it may be, but cache control directives apply.
Notice that because of server-driven reconnection, we can be
synchronized for an object even if we don't currently cache that
object.
Read
synch established <--- synch established
current version cached ----> current not cached
| /|\ recv | /|\
| | inval | |
| connect | current | connect |
current
| lost | version # | lost | version
| | recvd | | #
recvd
\|/ | Read \|/ |
sync not established <----- synch not established
current version cached ------> current not cached
Recv
inval
Action on READ:
sync established
current version cached:
return data
sync established
current not cached:
Request newest version from origin server
Recv newest version from origin server
state = Sync estab; current cached
sync not established
current version cached:
if legacy headers allow read, then
if (server supports targeted inval)
send "register" to inval server
return read data
else
set state "sync not estab; current not cached" and follow
those rules for READ
sync not established
current not cached:
Request newest version from origin server
Recv newest version from origin server
if(inval server supports targeted inval)
send "register" to inval server
set state "sync not established; current cached"
Action on CONNNECT LOST
set "sync not established"
Action on CURRENT VERSION # RECVD
set "sync established"
Notice that this may be received either in response to explicit
client request to resynchronize or because server periodicaly sends
out current version numbers?
Action on INVAL RECVD
current version = no current version
POSSIBLE BUG/OPTIMIZATION: does inval hold current version number
and therefore always allow you to go to "sync established, no
current version"?
(3.2)
Second, as mentioned in previous message (main comment #2 in
notes.11.20.2000b.txt), the idea described for server-driven
resynchronization for multicast seems like it can be/should be
explicilty generalized:
(Most of these features are implicit in the current draft; all I'm
really suggesting here is to make them explicit.)
The following seem to be defined:
server-driven resynchronization: servers periodically send out all
of the current version numbers for all of the objects (currently
defined for multicast sync/resync case)
client-driven resynchronization: clients ask for the current
version numbers of the objects they cache (currently defined for
the unicast resync case).
But it is worth noting that server-driven/client-driven
resynchronization are extreme points in a continuum. In the
client-driven case, it is not necessary to re-establish
synchronization on everything at once (but it may be desirable to
establish synchronization on some subset of data you think you will
soon use).
Note that the same mechanisms/rules apply for resynchronization after a
reconnection and for establishing synchronization when a new object is
read. Also, the only difference between targeted service and
untargeted service is just one message: in either case, a client gets
synchronized when it receives a message from the server indicating the
current version number; the only difference is that in targeted
service, the client has to ask for such a message whereas in
untargeted service, such messages periodically appear. (Put another
way, revalidation messages have no semantic meaning -- they may be
lost, reordered, or spontaneously appear at any time; they are just a
hint that "now" might be a good time for the server to send
a current version number to a client.) Finally, this
framework cleanly separates mechanism from policy: e.g., on
resynchronization under targeted service, a client may choose to
register all cached objects, no cached objects (make them all "sync
not established"), or a subset of cached objects (e.g., do a "bulk
re-register" on index.html and all inlined images; then do a
background re-register of all other cached objects from that
channel). E.g., a client may establish a callback on an object the
first time it reads the object or the first time it revalidates the
object and the object didn't change~\cite{dilley}.
To support this, the protocol should explicitly state whether a client
may contact a server to resynchronize an object. This is implicit in
the "no-target" header. This section and section 5.2.2 should make
this rule explicit. (Or should there be a separate header field?)
This archive was generated by hypermail 2b29 : Thu Nov 18 2004 - 11:21:29 MST