Access Controls

[Derek Atkins]

linas@linas.org writes:

> corba provides an asynchronous event mechanism that soap lacks, and I
> beleive onc-rpc lacks.  We could e.g. do this:

Onc-rpc short-of lacks this, but I've been building an ONC-RPC system
that would do what we want.  Indeed, I _JUST_ got it working this
morning (and I think I've just worked out all the race conditions).

> clienta->server
>    "gimme records 1-100"
> server: notes clienta has 1-100.  If clientb changes record 52, then
>    server notes that clienta must be notified, delivers async event. 
> 
> clienta listens for events, updates when it gets one.

In my solution, we would define two RPC programs, the forward
(client->server) program which would be all the client-originated
requests and server responses, and the callback/event (server->client)
program, which would be the event notification.  Then all we do is
build the network connection, add any transport-level encryption we
want, and then apply the forward service on the server side, and the
callback service on the client side.  All data is multiplexed across
the single TCP connection.  It's kinda neat! :)

> For rpc or xml/soap, which don't have events, I don't know how to 'roll
> our own', it seems complicated. Firewalls mess things up. I've never

See above; I've solved this problem (at least for ONC-RPC ;) -- the
client always initiates connections to the server (so you can get
through a NAT or firewall), and callbacks come back on that (single)
TCP transport.

> Again, traditionally, the server just sends out a 'your data is now
> invalid' message, allowing the client to figure out if it wants to
> refresh or move on to other things.  The most polite message is 
> 'records 1, 23 and 42 are invalid', rather than 'everything you know is
> wrong'.

The latter is certainly the better thing to do.

> Choice B:
>    server tries to track client's state.  It only delivers info
>    about what it thinks the client posseses.
> 
>   server->client
>         "I know that once upon a time ask for record 23, and since
>         since we last spoke, record 23 have changed.  
>         (no mention of 1 or 42 is made).
> 
> 
> Choise A doesn't scale well for very busy systems; however, its easier
> cleaner to impelment, far less likely to be buggy.  Choice B is prone
> to nasty bugs.  I vote for A.

I vote for B.  Indeed, let the CLIENT decide what it cares about: let
it register a callback for particular data that it cares about.  This
way the server doesn't even have to watch what the client requests,
but only what the client claims it wants to know about.  As you said,
A doesn't scale well.  B may be "prone to nasty bugs" but bugs are
easy to fix; scaling problems are not.  And I'm not at all convinced
that A is any easier to implement.

One way to approach B would be to have object version numbers; every
time an object gets updated, bump the version.  That way a client can
basically as the server if it's version is correct by version skew.
Also, for registering callbacks, you can request a callback for object
id X version Y, and that way you could get an immediate callback if Y
isn't current.  Hmm, this means that you could request a callback when
you try to edit data, and get an immediate callback if it's not
current.  But I'm not sure we'd want to do only that.

I guess the question is, how "live" do we want client data to be?

> --linas

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord@MIT.EDU                        PGP key available