Re: server-to-server protocols

["Hibbs, R Barr (rbhibbs)" <[e-mail]>]

Bob, Kim, Ted, Ralph, et al.--

At 05:09 PM 4/11/97 -0400, I wrote:
>The fundamental question that I am asking is 'Just what is the nature of
>what the server-to-server protocol is trying to accomplish?'  In 
particular,
>are we attempting to synchronize binding information (alone) among servers, 

>or are we attempting to enable one server to take-over from another by
>synchronizing configuration information?
>

To which Bob responded on 4/15/97 -1040:
>I guess I naively assumed both. That is, 1) I started to build an 
interserver
>message that included the full client binding information and
>2) I simply assumed that a goal of the interserver protocol
>was to allow the configuration of a single server of the SG and
>have this propagate throughout the SG.  But you raise a good point
>that I hadn't considered, i.e., that these are seperable.

It is probably a much simpler approach to have a server report the binding 
to other servers in the group than to synchronize the data from which the 
binding is constructed.  The former seems to me to be one of the fundamental 
requirements of a server-to-server protocol, while the latter seems to me to 
be the beginnings of a specification on the internal design of a server.

When we talk of synchronizing binding information, I imagine that we are 
synchronizing the RESULTS of whatever process was used by the server 
offering the binding to a client -- that is, we don't know (or care to know) 
anything about the server's database structure, the resolution of competing 
information about options (suppose the vendor class and user class options 
are both specified and yield different values for another option -- the 
selection of option values in this case may be well-specified, but what 
about other cases not so well-specified?).  To phrase it a different way, we 
are allowing the greatest possible range of server solutions to 
interoperate.

In contrast, if we try to duplicate the PROCESS of creating a binding, I 
believe we are also tacitly specifying much of the database and program 
design of a server, making it more unlikely that servers from different 
vendors will interoperate.

Here I'm looking for guidance.  I think that if a different server offers to 
rebind the client, it is entirely reasonable to assume that the offer may be 
slightly different, simply because the original and rebinding servers may, 
of practical necessity, have slightly different sets of default data and 
server-specific configuration.  And so, while we wouldn't guarantee an 
identical binding to a client, we would be proposing a highly similar one. 
 I think that this may not only be a reasonable approach, it may be the only 
one that will interoperate.

Comments, criticisms, and suggestions are welcomed at this point -- just 
what does the mailing list think?  An implication of the "simple binding 
data" approach is that the client may not get an identical lease when 
rebinding.  But is that really any different from the case where the 
original server has some option default changed which would apply to the 
client during rebinding?

Kim and Ted (and any other implementor) may want to jump in here with 
comments about how the choice of a result-oriented vs. a process-oriented 
model might effect server program design and operation.

 --Barr Hibbs
  Pacific*Bell