Re: Atomicity in network protocols

On Sat, 16 Jul 2011 23:46:44 -0700, Don Y <nowhere@xxxxxxxx> wrote:

Hi Robert,

On 7/16/2011 11:34 PM, Robert Wessel wrote:
On Sat, 16 Jul 2011 21:08:34 -0700, Don Y<nowhere@xxxxxxxx> wrote:

I was suggesting altering the protocol to something along the lines of
how you'd implement many of the lock-free algorithms in multi-threaded
applications. IOW, by providing a robust way for the client to see
that another update has happened, it can then retry. Obviously that

Ah, OK. But, the client will still *infer* that something has
changed simply because his SET failed.

While I don't know if this applies in your situation, that would not
usually be adequate. Consider the case where the client knows the
server is in state A, and therefore wishes to set state B. In the
mean time, another client sets the server to state C. Setting the
server from C to B may be perfectly valid (thus not generating an
error), but might not be what the first client actually wanted. The
idea being that the update works if the server was in the state
expected by the client, and only then.

Not the case, here.

The server is always in a "valid" state (i.e., if you equate the
configuration that the server is imposing on the actual "device"
as being the state of the server).

SETs can only move the server to another valid state (else they
fail).

SETs can bring the server to a more restricted or *less* restricted
state. I.e., if a client changes *his* current configuration to
one that is more tolerant (e.g., changing from 1% accuracy to 5%)
then the server (device) can (possibly) move from a more tightly
defined state to a more permissive one (e.g., at 5% accuracy, the
range of measurable data values might be greater than it was at 1%).

Note that actions of another client can never invalidate the *current*
configuration for any of the connected clients. E.g., if client1
wants 1% accuracy and the other clients want 5%, then the device
still operates at 1% even though "most" of the clients don't need/want
that accuracy.

However, if one of those clients has dropped his accuracy to 5%
in the hope of increasing the measurement range to something larger,
that SET RANGE can be denied -- because the device might be forced to
remain in a narrower range in order to satisfy the needs of the "1%"
client.

A "problem" with this whole scheme is that clients are deliberately
isolated from the needs of other clients. Instead, the responsibility
of coordinating their requirements lies with the system designer.
I.e., if you designed a (single CPU) system with multiple consumers
of a particular data, it would fall to you to ensure each consumer had
the right data, with the right accuracy, timeliness, etc. -- even *if*
those consumers all knew about each other.


Then instead of letting the client set a server's state, let a client
tell the server its requirements. The server then keeps track of what
each client wants, and adjusts its behavior appropriately. If a
client specifies requirement that are incompatible with what the
server can do (presumably because conflicting requirements have
already been set), you'd have to fail them at that point.

Add a periodic poll to make sure each client still existed, so that
you can delete requirements when a client dies. Obviously if the
client told you it was going away, you'd do the same.
.

Relevant Pages

  • Re: OpenVPN server mode usage?
    ... But an openvpn configuration shouldn't be depending upon dynamic dns. ... Have your dynamic IP client contact your server. ...
    (Debian-User)
  • Problem joining Windows domain from remote VPN/PPTP box
    ... server OK with administrator rights (configured via Routing and Remote ... On client there exists static route for remote network that points to ... following information can help you troubleshoot your DNS configuration. ...
    (microsoft.public.windows.server.active_directory)
  • Re: What doesnt lend itself to OO?
    ... >> proxy and instructs the server to constuct the real object. ... rather than client code. ... If 'clock' is instantiated in the server, ... > for the server interface at the OOA level. ...
    (comp.object)
  • Re: Outlook -> remote exchange -> always wants a password
    ... I have my server set to use Integrated Windows authentication over SSL. ... almost certainly "break" your existing users if the client setup does not ... Close out of these configuration dialogs, ...
    (microsoft.public.windows.server.sbs)
  • Re: 70-294 next week
    ... to another DNS ... server for at least ... client, which then ... configuration on the client. ...
    (microsoft.public.cert.exam.mcse)