Renegotiating "contracts"

Hi,

I employ a client-server model evermore extensively in my
designs. Practically everything is a client/actor/service.

Many services are touch-and-go -- but, many other relationships
are long standing: a client connects to a service and uses
it for very long periods of time (e.g., a display service).

Since I can't know what all clients will require over the
length of a session -- nor the lifetime of the product -- I
allow clients and servers to *negotiate* their contracts
at the start of each session. If a service can't provide
the characteristics that the client requires, the client
balks and refuses to run (at that time).

Services are shared, of course. So, the characteristics that
a service is able/willing to provide to a particular client
can change -- based on what other clients' requirements are
current.

A negotiated level of service is NEVER REDUCED during a session (!).

The interesting case comes when a level of service has the potential
of being *elevated* during a session. Persistent clients can often
want to take advantage of those extra capabilities -- "renegotiate"
their contracts (though still not giving up the level of service
previously agreed upon!).

The problem is determining the most appropriate way to notify
existing clients [1] of the possibility for service improvements.

One scheme is to just tag subsequent requests made of the service
with some sort of status field ("Oh, by the way, we're currently
running a sale on men's shoes. Contact a sales agent for more
details...".) This has a relatively low overhead and requires no
*additional* mechanisms beyond those already present (add an IN/OUT
to each service request?).

It doesn't address clients who are not presently connected to the
service (see [1]). And, it relies on clients transacting with
the service "often enough" to get timely notifications. ("Gee,
we're sorry but the men's shoe sale expired some time ago...")
I.e., it effectively requires the clients to *poll* the service
if they want this status (imagine if they have no real needs
for the *service*, presently, but just want to check to see if
the service might be *improvable*!)

Another scheme is to implement an upcall from the service to the
client(s). Neglecting the "unclean" feeling that comes with
this, it suffers from the fact that it doesn't allow unconnected
clients to be notified (again, [1]). And, opens the service up
to an *unbounded* obligation on behalf of the client! (ignoring
the security implications, etc.)

A variation on this is something akin to an ASR issued on the client
by the service -- let the *client* incur the cost of this obligation!

Any "callback" mechanism is complicated by RPC (one of the C-S
models's biggest assets!).

And, of course, I've not even mentioned how fairness and priorities
can be implemented. Nor race avoidance issues, etc. <frown>
Before I head down that path, I'd like to see if there are any other
techniques I may have overlooked?

---

[1] You also have to consider potential clients that have previously
"balked" at the lack of availability of a particular service level
and are not presently connected to the service!!

On 2012-04-11, Don Y <> wrote:
>
> Since I can't know what all clients will require over the
> length of a session -- nor the lifetime of the product -- I
> allow clients and servers to *negotiate* their contracts
> at the start of each session. If a service can't provide
> the characteristics that the client requires, the client
> balks and refuses to run (at that time).

I suspect you are trying to overengineer this - thowing too much
into one basket. It seems to me that this problem has two distinct
elements: firstly negotiating the parameters for an individual
session and secondly advertising new capbilities to clients that
may or may not be connected.

The first case is well understood by looking at prior art - the
Telnet protocol's "do, don't, will, won't" system for example is
fairly simple, robust and easily understood.

The second element doesn't really need to go into detail - it's
enough to simply state "The options available have now changed"
and let the clients perform an exploratory connect to investigate
whether the services on offer are now available. If you want to
cut down the number of investigatory connects you can always
summarise the options (or just the changes) in the rest of the
packet - there's no reason it can't just contain "will, won't"
messages that leverage the existing options negotiating code. In
that case problems of resource contention can be alleviated simply
be a change in semantics - options advertised are advisory until
such time as they are actually committed to in a particular session.

As for how to get this message to the client, obviously a lot
depends on the circumstances. Personally I wouldn't be too keen
on any "subscriptions" to receive updates if you can avoid it simply
because that open up so many more cans of worms. It would seem to
me that multicast would be the cleanest way by far, but of course
that limits you to a single subnet unless you want to jump through
more hoops.

--
Andrew Smallshaw

Hi Andrew,

On 4/11/2012 4:18 PM, Andrew Smallshaw wrote:
> On 2012-04-11, Don Y<> wrote:
>>
>> Since I can't know what all clients will require over the
>> length of a session -- nor the lifetime of the product -- I
>> allow clients and servers to *negotiate* their contracts
>> at the start of each session. If a service can't provide
>> the characteristics that the client requires, the client
>> balks and refuses to run (at that time).
>
> I suspect you are trying to overengineer this - thowing too much
> into one basket. It seems to me that this problem has two distinct
> elements:

Yes -- though they are intimately related. E.g., one of the
approaches I am exploring, currently, leverages this fact.

> firstly negotiating the parameters for an individual
> session and secondly advertising new capbilities to clients that
> may or may not be connected.

But, you don't (necessarily) want to "advertise" to *everyone*.
Only to those that are likely to be potential clients. (Advertising
to *everyone* could be expensive and unduly burdensome on those
not interested in what you're peddling)

> The first case is well understood by looking at prior art - the
> Telnet protocol's "do, don't, will, won't" system for example is
> fairly simple, robust and easily understood.

Already have the "ability" (avoiding the term "capability", here)
issue sorted out. The biggest problem is that each service has
different issues/constraints/characteristics that apply to its
service.

E.g., a display service might offer constraints on color depth vs.
"resolution". Or, resolution vs. frame rate. Or...

OTOH, a "computational service" may constrain precision vs.
timeliness. Or, footprint...

A single lexicon won't apply.

> The second element doesn't really need to go into detail - it's
> enough to simply state "The options available have now changed"
> and let the clients perform an exploratory connect to investigate
> whether the services on offer are now available. If you want to
> cut down the number of investigatory connects you can always
> summarise the options (or just the changes) in the rest of the
> packet - there's no reason it can't just contain "will, won't"
> messages that leverage the existing options negotiating code. In

The telnet model is inappropriate for service offerings.
Or, at the very least, is pretty poor at explaining
anything more than a *single* constraint independent of
the others.

E.g., like a display service saying "1600x1280" (max resolution),
"32b" (max color depth), "120Hz" (frame rate) whereas, in practice,
you might not be able to get any *two* of those at the same time
(i.e., 1600x1280 @ 1bpp & 60Hz vs. 640x480 @ 32bpp & 60Hz vs.
320x200 @ 4bpp @ 120Hz vs. ...)

Add to that the fact that each service's constraints differ and
the "notifications" become impractical -- about all they effectively
do is say, "something has changed; if you're interested, contact me!"

> that case problems of resource contention can be alleviated simply
> be a change in semantics - options advertised are advisory until
> such time as they are actually committed to in a particular session.

Of course. As is the case when two clients approach the service at
two different times -- you can never be assured that what you
"want/need" will be available.

> As for how to get this message to the client, obviously a lot
> depends on the circumstances. Personally I wouldn't be too keen
> on any "subscriptions" to receive updates if you can avoid it simply
> because that open up so many more cans of worms. It would seem to
> me that multicast would be the cleanest way by far, but of course
> that limits you to a single subnet unless you want to jump through
> more hoops.

Note that you also have to (efficiently) deal with "local" clients.

I'm going to see if I can exploit some hooks that I have in my OS
to make this a more deterministic process -- so you can better
model how a piece of code is going to behave in a given context.
This should work for "declared interested parties" quite well
(but not at all for "The Unwashed Masses" :< )

Thx!

On Wed, 11 Apr 2012 10:16:20 -0700, Don Y wrote:

> Hi,
>
> I employ a client-server model evermore extensively in my designs.
> Practically everything is a client/actor/service.
>
> Many services are touch-and-go -- but, many other relationships are long
> standing: a client connects to a service and uses it for very long
> periods of time (e.g., a display service).
>
> Since I can't know what all clients will require over the length of a
> session -- nor the lifetime of the product -- I allow clients and
> servers to *negotiate* their contracts at the start of each session. If
> a service can't provide the characteristics that the client requires,
> the client balks and refuses to run (at that time).
>
> Services are shared, of course. So, the characteristics that a service
> is able/willing to provide to a particular client can change -- based on
> what other clients' requirements are current.
>
> A negotiated level of service is NEVER REDUCED during a session (!).
>
> The interesting case comes when a level of service has the potential of
> being *elevated* during a session. Persistent clients can often want to
> take advantage of those extra capabilities -- "renegotiate" their
> contracts (though still not giving up the level of service previously
> agreed upon!).
>
> The problem is determining the most appropriate way to notify existing
> clients [1] of the possibility for service improvements.
>
> One scheme is to just tag subsequent requests made of the service with
> some sort of status field ("Oh, by the way, we're currently running a
> sale on men's shoes. Contact a sales agent for more details...".) This
> has a relatively low overhead and requires no *additional* mechanisms
> beyond those already present (add an IN/OUT to each service request?).
>
> It doesn't address clients who are not presently connected to the
> service (see [1]). And, it relies on clients transacting with the
> service "often enough" to get timely notifications. ("Gee, we're sorry
> but the men's shoe sale expired some time ago...") I.e., it effectively
> requires the clients to *poll* the service if they want this status
> (imagine if they have no real needs for the *service*, presently, but
> just want to check to see if the service might be *improvable*!)
>
> Another scheme is to implement an upcall from the service to the
> client(s). Neglecting the "unclean" feeling that comes with this, it
> suffers from the fact that it doesn't allow unconnected clients to be
> notified (again, [1]). And, opens the service up to an *unbounded*
> obligation on behalf of the client! (ignoring the security
> implications, etc.)
>
> A variation on this is something akin to an ASR issued on the client by
> the service -- let the *client* incur the cost of this obligation!
>
> Any "callback" mechanism is complicated by RPC (one of the C-S models's
> biggest assets!).
>
> And, of course, I've not even mentioned how fairness and priorities can
> be implemented. Nor race avoidance issues, etc. <frown> Before I head
> down that path, I'd like to see if there are any other techniques I may
> have overlooked?
>
> ---
>
> [1] You also have to consider potential clients that have previously
> "balked" at the lack of availability of a particular service level and
> are not presently connected to the service!!

I'm not sure of just what sorts of systems you're trying to make, here.

In the systems that I'm used to, turning the system on, having it say
"OK, I'm ready", then having it fail later on when I try to use an
advertised feature is a much worse failure than turning it on and having
it say "I'm sorry, your system as configured does not have enough
resources to operate correctly", which is, in turn, much worse than
ordering a system from the factory and having them say "Oops -- that
combination won't work; you either need to trim off A, or you need to
upgrade B".

It seems like your basic scheme leaves the door open for creeping
failure, while your modification rolls out a red carpet and assigns a
door man to welcome failure in.

--
My liberal friends think I'm a conservative kook.
My conservative friends think I'm a liberal kook.
Why am I not happy that they have found common ground?

Tim Wescott, Communications, Control, Circuits & Software
http://www.wescottdesign.com

Hi Tim,

On 4/12/2012 9:58 AM, Tim Wescott wrote:

> I'm not sure of just what sorts of systems you're trying to make, here.
>
> In the systems that I'm used to, turning the system on, having it say
> "OK, I'm ready", then having it fail later on when I try to use an
> advertised feature

It wouldn't do that -- unless you were trying to do something that
the system was *not* designed to do!

E.g., trying to *operate* a machine while simultaneously trying to
perform *maintenance* on it.

> is a much worse failure than turning it on and having
> it say "I'm sorry, your system as configured does not have enough
> resources to operate correctly", which is, in turn, much worse than
> ordering a system from the factory and having them say "Oops -- that
> combination won't work; you either need to trim off A, or you need to
> upgrade B".

Isn't this what we do with existing technology?
- "Your PC is too slow, you need to upgrade memory/processor."
- "I'm sorry, I can't play full motion videos *and* place a phone
call at the same time WHILE UPDATING my firmware"
- "Sorry, I can't steer the boat while you calibrate the compass"
The difference is how and where you implement the constraint
checking. And, *if* any checking is done at all (instead of
simply "not working" or "not working WELL")

---

You're viewing a radiograph. You want a very high resolution GRAYSCALE
"visual". It's a "still picture" so you can tolerate low frame rates
to get that higher resolution.

You want to view a video of your kid's soccer practice. That low
frame rate is ill-suited to the motion content of the "video".
And, you'd undoubtedly want to see your kid in "living color" -- not
drab greyscale.

Is the machine *broken*? Or, are you trying to operate it incorrectly?

How are *you* going to prevent the user from trying to view radiographs
and color video simultaneously? Are you going to HARD CODE this in
the user interface? I.e.,

if (viewing_radiograph == TRUE) {
disable(view_live_video_feature);
}
if (viewing_live_video == TRUE) {
disable(view_radiograph_feature);
}
...

Should we sell you a very high resolution, high frame rate, color
display system so you can view high resolution greyscale images
while *also* viewing "live, color video"? Should the user be sold
two separate systems -- one targeted for each type of application?

--

You have a scale (i.e., mass-measuring device) that can be operated
in several different ranges to get varying accuracies/resolutions.
An application has configured the scale for 0-20 pounds with 1g
resolution (e.g., to measure the weight of newborns/infants).
Another application wants to weigh an adult male -- 150-250 pounds
with ~3oz resolution.

Is the system broken? Should the customer purchase *two* separate
systems -- one for infants and another for adults? Even though
one of them will (probably) be idle always? Should the system,
instead, have 1g resolution over the *entire* 0-250 pound range?

Again, how do you *prevent* the user from attempting to use the
system in this way? Hard code *all* of the potential conflicting
operating criteria? Peek inside each "applet" and/or operating mode
of each application to see what requirements it has AND what
constraints it imposes on the "system" -- then, codify them in one
central location?

Can you see the maintenance mess this poses? Did you remember to
re-enable featureX when activityZ was finished? Or, is the user
complaining that suddenly he can't weigh infants anymore:
"It was working fine yesterday -- right before that morbidly
obese patient came in and we used the 'High Weight' range for
the first time..."

--

Instead, have each "client"/application take/request the resources
that it requires. If it can't obtain them, then something about the
environment is inconsistent with its needs -- are you trying to
"run" the machine while "calibration" is being performed (which
places limits on some mechanism that the "run" state requires).

If you want to implement an "uninspired but predictable" configuration,
have main() instantiate the N features that you want to be able to run
at all times. They take/constrain the resources that they will
eventually need. And, the user will never be able to do anything
that *can't* coexist with these activities -- EVEN IF NONE OF THEM
ARE ACTUALLY TAKING PLACE! Now you have a product that is just as bad
as your competitors'! :>

> It seems like your basic scheme leaves the door open for creeping
> failure, while your modification rolls out a red carpet and assigns a
> door man to welcome failure in.

It allows the *user* to decide what he wants the system to do for him
and the system complies -- to the extent possible. Do you complain if
your cell phone doesn't let you watch a movie, play a game *and* make
a phone call simultaneously -- *while* downloading a file? Does
your phone simply *prevent* you from trying to do more than one thing
at a time? Or, does it publish a list of possible combinations that
can peacefully coexist and PREVENT you from trying to invoke any
others that aren't among these "approved combinations"?

You want to weigh that ~200 pound "adult male"? Then have the
"infant monitor" application release its resource claims on the
scale. A morbidly obese patient comes in and the 150-250 pound
range is insufficient? Switch to the 200-400 pound "High Weight"
range (at 1/2 pound resolution).

Find this annoying/tedious? Great! Buy *two* (or three) systems.
IDENTICAL. Run the "adult male" application on one and the "infant"
on the other. A much better solution than buying an "infant only"
system and an "adult only" system. We'll gladly sell them to you
as the same, "standard" product! If it makes you feel better about
your purchase, we can probably arrange to charge you an extra fee
for <whichever> -- so you think of it as "special". :>