1. Home
  2. Embedded Programming
  3. Renegotiating "contracts"

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. 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!!
Reply to
Don Y
Loading thread data ...

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
andrews@sdf.lonestar.org
Reply to
Andrew Smallshaw

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

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)

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 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!"

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.

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!

Reply to
Don Y

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
Reply to
Tim Wescott

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.

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?
Reply to
Don Y

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.