Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #30277

RPC/RMI in heterogeneous environments

Show all headers | View raw

I postpone automatic type conversion to the *servant*, rather
than embedding it in the client-side stub.  My reasoning is
that this allows a wider window for the targeted node to change
*after* the RPC/RMI invocation and before it's actual servicing.

I.e., it would be silly to convert arguments for a target node
of type X, marshall them and then, before actual transport,
discover that the targeted *service* now resides on node Y
(which is of a different "character" than X).  That would require
unmarshalling the already converted arguments (the originals having
been discarded after the first conversion), converting them from X
to Y representations, remarshalling and facing the same potential
"what if it moves, again?"

However, this defers actual *checking* the data until after
transport.  It also means transport errors take a higher priority
than data type errors (cuz the data aren't checked until they've
actually been transported!)

Discussing this with colleagues, it seems a smarter approach might
be to split the activities between client- and server- side stubs.
E.g., check the data in the client-side stub so any errors in it
can be reported immediately (without waiting or relying on transport
for that to occur).  Then, let the servant sort out the details of
conversion KNOWING that the data are "valid"/correct.

[The downside of this is the servant must bear the cost of the
conversion; so, targeting an action to a resource-starved node is
costlier than it might otherwise have been.]

The process obviously mirrors for return value(s) conversions.

[I haven't, yet, considered if anything undesirable "leaks" in either
of these approaches]

Back to comp.arch.embedded | Previous | Next — Next in thread | Find similar | Unroll thread

Thread

RPC/RMI in heterogeneous environments Don Y <blockedofcourse@foo.invalid> - 2021-01-21 18:38 -0700
  Re: RPC/RMI in heterogeneous environments George Neuner <gneuner2@comcast.net> - 2021-01-25 01:58 -0500
    Re: RPC/RMI in heterogeneous environments Don Y <blockedofcourse@foo.invalid> - 2021-01-26 00:06 -0700
      Re: RPC/RMI in heterogeneous environments George Neuner <gneuner2@comcast.net> - 2021-01-26 13:23 -0500
        Re: RPC/RMI in heterogeneous environments Don Y <blockedofcourse@foo.invalid> - 2021-01-26 13:39 -0700
          Re: RPC/RMI in heterogeneous environments George Neuner <gneuner2@comcast.net> - 2021-01-28 21:08 -0500
            Re: RPC/RMI in heterogeneous environments Don Y <blockedofcourse@foo.invalid> - 2021-01-31 11:44 -0700
              Re: RPC/RMI in heterogeneous environments George Neuner <gneuner2@comcast.net> - 2021-02-01 15:50 -0500
                Re: RPC/RMI in heterogeneous environments Don Y <blockedofcourse@foo.invalid> - 2021-02-03 21:19 -0700
  Re: RPC/RMI in heterogeneous environments upsidedown@downunder.com - 2021-01-29 20:33 +0200
    Re: RPC/RMI in heterogeneous environments Don Y <blockedofcourse@foo.invalid> - 2021-01-31 12:37 -0700
      Re: RPC/RMI in heterogeneous environments upsidedown@downunder.com - 2021-02-01 08:50 +0200
        Re: RPC/RMI in heterogeneous environments Don Y <blockedofcourse@foo.invalid> - 2021-02-03 20:53 -0700
  Re: RPC/RMI in heterogeneous environments upsidedown@downunder.com - 2021-01-31 21:39 +0200
    Re: RPC/RMI in heterogeneous environments Don Y <blockedofcourse@foo.invalid> - 2021-01-31 15:21 -0700

csiph-web