Subject: RE: Multiple paths in DPD

From: Hal Lockhart <[email-masked]>
Date: Fri, 26 Apr 2002 14:46:22 -0400

Russ Housley said:

> > I am strongly opposed to an approach that would require the 
> server to 
> > maintain state.  Unless other people are willing to speak 
> up and support 
> > such an approach, I am not willing to make changes in this 
> area.  In my 
> > view, the current consensus is for a stateless server.
> > 
 
Peter Sylvester responded,
 
> the server does not need to maintain a state. That had been
> discussed between Steve farrele and me some yearsz ago, in
> order to clarify the meaning of what Mike calls 'state token'.
> 
> A server which returns a 'state token' does not turn it into one
> that MUST in a stateful mode. When the 'next request after token'
> comes it, the server sets up it state from the data that had been 
> return by the 'cookie'.

The extent to which this is true depends on how easily the server can go
from the token to some persistent storage. (We are actually debating volatle
state, not state per se.)

In Mike's specific proposal, the server has to constuct multiple paths
relevant to a given request, in some order and be able to produce the "next"
on demand. It seems unlikely that this can be done without remembering the
list or at least the contents of the last response. Handling this protocol
when the information used to construct the paths changes between requests
seems particularly challenging to me.

Hal

---

From: "Michael Myers" <[email-masked]>
Date: Fri, 26 Apr 2002 12:15:49 -0700

Hi Hal,

A few comments below.

Mike
-----Original Message-----
From: Hal Lockhart [mailto:[email-masked]]
Sent: Friday, April 26, 2002 11:46 AM

> The extent to which this is true depends on how easily
> the server can go from the token to some persistent
> storage. (We are actually debating volatle state, not
> state per se.)

That was my conclusion.  I'm pretty sure there'll be abundant
state on that machine anyway.

> In Mike's specific proposal, the server has to constuct
> multiple paths relevant to a given request,

Which is must do anyway in the maxPath design scenario.

> in some order and be able to produce the "next" on demand.

As in "next record" for an SQL type query.  Which is sort
of my point.  DPD is just a tailored database access
mechanism.  And database machines have been doing this
for years.

> It seems unlikely that this can be done without remembering
> the list or at least the contents of the last response.

That is the key, to be sure.  What's the "next" record/path
to be returned?

> Handling this protocol when the information used to
> construct the paths changes between requests seems
> particularly challenging to me.

No.  One of the underlying assumptions is that no
paramters change from the client.  The client is
seeking a path compliant to a given set of parameters.
As it may turn out, the server may have several
such that qualify.  The iterative approach enables
a client to acquire these in serial query fashion
until it either finds the precise record/path
it's looking for or the server runs out of data.

Hal