1. This forum section is a read-only archive which contains old newsgroup posts. If you wish to post a query, please do so in one of our main forum sections (here). This way you will get a faster, better response from the members on Motherboard Point.

Renegotiating "contracts"

Discussion in 'Embedded' started by Don Y, Apr 11, 2012.

  1. Don Y

    Don Y Guest

    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!!
     
    Don Y, Apr 11, 2012
    #1
    1. Advertising

  2. 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
     
    Andrew Smallshaw, Apr 12, 2012
    #2
    1. Advertising

  3. Don Y

    Don Y Guest

    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!
     
    Don Y, Apr 12, 2012
    #3
  4. Don Y

    Tim Wescott Guest

    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
     
    Tim Wescott, Apr 12, 2012
    #4
  5. Don Y

    Don Y Guest

    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". :>
     
    Don Y, Apr 13, 2012
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. pcdude28
    Replies:
    5
    Views:
    277
  2. Guest
    Replies:
    1
    Views:
    204
    chrisv
    Jun 2, 2005
  3. edde

    Hitman Contracts fx5900

    edde, Apr 27, 2004, in forum: Nvidia
    Replies:
    11
    Views:
    477
  4. edde

    Hitman Contracts Post Filter

    edde, May 4, 2004, in forum: Nvidia
    Replies:
    0
    Views:
    307
  5. John Smith
    Replies:
    5
    Views:
    380
    DaveW
    Feb 23, 2005
Loading...

Share This Page