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

Groups > comp.arch.embedded > #30282

Re: RPC/RMI in heterogeneous environments

Show all headers | View raw

>> You guys keeping safe?  I've spent the day documenting the
>> vaccination process for my neighbors.  Sure would have been
>> nice if that information was *published*!  (moronic IT
>> people making process decisions...)
> 
> Arrgh!  They're saying here perhaps by May.  According to the news and
> the various national vaccination tracking sites, this state ranks near
> the bottom for percentage of existing doses administered (~40%).
> 
> Right now, they're giving out only Pfizer's 2-dose vaccine, and there
> is major controversy over whether to give out more 1st doses vs
> completing the series for full immunization.  And nobody knows how
> long the immunity will last anyway ... this may turn into a yearly
> thing like the flu.

We have Moderna and Pfizer available, locally.  WHERE you choose to
receive the dose influences the choice.  E.g., most "drive thru"
sites are Moderna only.  But, many walk-in sites are both.

However, I don't see a way to determine/pick which you are going to get.
If, however, you notice the timing of the second dose (you get TWO
appointments when you register), you can largely deduce which it will
be (i.e., if the second dose is >3, <4 weeks after the first, it is
LIKELY Pfizer; >4 is likely Moderna)

I fully expect this to be yet another annual vaccination (or, crap
shoot if you prefer to go without).  It's now endemic and we'll be
hearing about it in terms much like The Hong Kong Flu, etc.

> They are strictly limiting who even can get 1st doses: right now its
> limited to hospital workers, first responders and cowardly politicians
> [somehow almost the entire state legislature managed to get itself
> vaccinated].  They can't seem to decide what to do about 2nd doses and
> so far have left the decision to the individual hospitals that have
> vaccine to give.

There are all sorts of categories and sub-categories and sub-sub-categories,
here.  It's like looking at a classic *outline* structure:  I.A.1.a....

And, there's no real priority implied by that designation!  <shrug>

I *think* hospitals (a couple of the sites, here, are in/at hospitals;
others are "sports arena", "convention center", etc.) are trying to
plan for the second shots instead of just pushing whatever they have
into folks' arms.  We'll see in a few weeks...

> They've made no provisions for people to register and be notified when
> they are eligible - they're counting on doctors to notify their own
> patients !?!  When was the last time your doctor called to remind you
> about a flu shot?

The "registration" part of this was the most f*cked.  The state has
"their way" and, of course, our county has decided that THEY have a
*better* way (dunno how much is politics, NIH, etc.).

You must register with the county, first.  And, fill out a survey/questionnaire
from which they sort out when you *should* be vaccinated.  SOME TIME LATER
(i.e., NOT "just after you have completed the survey" as would be typical
if you'd done any OTHER on-line transaction and expected confirmation of
your actions), they invite you to register for an account at the local
hospital (patient portal) -- no idea how it is handled at other sites.

[The patient portal seems like a hack just to get a system in place
quickly without having to build from scratch]

Because there is no immediate feedback/confirmation, folks try to register
a second time.  Or, call the phone registration hotline (for luddites).
I.e., the absence of the EXPECTED sort of confirmation actually increases
the cost of running the program and increases folks' anxiety about it.
I have friends who have waited more than a week and still not seen any
indication that their initial registration hasn't fallen into a black hole!

Once "invited" to create an account, you can do so on the *hospital's*
web site.  Of course, it was designed with patient support in mind;
not tens of thousands of connection attempts!  (20,000 appointments
were made in the first 2 hours)

And, of course, typical IT-dweeb has *his* notion of how users should
interact with "his" site.  So, email address is required.  As is home
phone.  As is cell phone.  As is street address.  Gender.  SSN, etc.
("Gee, what if I don't *have* a home phone?  Or email??")

Having created an account, you can now login and schedule a vaccination
appointment.

Here's where things REALLY fall down...

FIRST, you pick a pair of appointments (you have no choice as to the
timing of the second; if you pick THIS first appointment, then you get
THAT second appointment).  Fine.  One less thing for folks to screw up!

Then, you are asked a series of questions -- one per screen.  I.e.,
you spend a fair bit of time getting through the process.

And, at the very end, when you opt to "schedule your appointment",
invariably, you discover taht the time(s) you selected are "sorry, not
available"!

[You can understand why]

But, to compound the idiocy, instead of just offering you a new list of
AVAILABLE appointments, it sends you all the way back to the beginning
(which was where you originally selected the appointment times).

And, you progress through the same series of screens -- none of
your prior answers remembered.

So, invariably, is the other schmuck who got screwed out of his
appointment time and is now hoping to pick the time YOU just picked
as a "second choice".

This continues until you realize what's happening and jump forward
a few days (instead of always trying to get the "next available"
times) and HOPE.

> I suppose I shouldn't be surprised: even in the best of times, its a
> rare day that the "establishment" can find its arse with both hands.
> These are hardly the "best of times".

The actual administration (sounds wrong in this context) of the
vaccine was, by contrast, incredibly efficient!  Instead of heeding
the instructions to park in the remote lot and take the shuttle
bus in (with a bunch of other folks packed into that small space),
we drove directly to the entrance (C having worked there for many
years, we are intimiately familiar with the layout of the campus,
which lots are inaccessible, which often have available spots,
what time of day is best, etc.).

Security verifies your ID and appointment time (can't show up
more than 15 minutes prior to your appointment).  A pair of
staff at a table ask you about allergies -- esp medications
(they are only interested in IF you have any, not the details).
Folks with allergies are given a tag with "30" written on it,
else "15".

Next desk has a couple more staff who decide to which "vaccinator"
you should be routed and marks your tag accordingly.  A guy escorts
you to that (socially distanced) line -- no doubt to keep things
moving along; I estimate 10-15 seconds between visitors.

When your turn, nurse marks the time on your tag as she makes the
injection.  Gives you a vaccination card and instructions to keep
it with you (at least until the followup shot has been administered;
presumably, you won't be given the second shot if you can't prove
you've had the first -- they also put a sticker on the card
and want to be sure you have yours available!)

Then, take a seat and wait the 15 (or 30) minutes prescribed.

Meanwhile, a small army of staff circulate through the seated
guests verifying everyone is OK.  At the end of the required
interval, you're sent out (where MOST folks would again board
the kiddie bus for a drive back to their vehicles)

In our case, vaccine administered exactly *1* minute after
scheduled appointment.  And, we were back in the car 34 minutes
after that (having had to wait the 30 minutes, "supervised")

>> *Snow* (dusting) expected tomorrow.  Yay!  Maybe a break
>>from the allergies!!  (though sad news for the citrus <shrug>)
> 
> We've been at or below freezing for several days and we're expecting
> 1-2 inches of snow tonight (Tue -> Wed).  We're way behind on snowfall
> this season.

Last snowfall, here, in the valley, was 2 years ago.  As then,
we could see it falling (big fluffy flakes) but nothing "sticks".
Apparently at least 18 inches on the mountain so they'll be hoping
to open the ski slopes (obtrivia:  southernmost ski resort in
the US)

>>> Or it means choosing a particular 'server' before marshalling the
>>> data.  Although nowadays heterogenous hardware is handled with
>>> agnostic protocols, in the past it was not unusual to use a 3-way
>>> handshake when dealing with varying hardware.  The 2 sides could
>>> negotiate the protocol rather than it being fixed.
>>
>> The client has no control over the server; wherever the object is
>> "backed" is where the RMI was be destined.  It would be like
>> having the ability to pick which server handles your bank
>> account...
> 
> Understood.  My point was about how replicated services  ... ie. the
> same service provided by multiple servers ... are handled.  The client
> doesn't know which server will respond to its call.
> 
> In a modern system, the RPC protocol would be self describing and
> architecture agnostic - so it doesn't matter which server answers.

Yes.  But those weren't designed as *integrated* "systems".  They
offered services to anyone who came along.  My approach is to
pull apart a system that would have resided in a big machine, had I/Os
and MIPS been more accommodating.

> However, in older systems it was not uncommon for clients to negotiate
> the protocol with whatever server responded, and for data in the
> resulting messages to be sent in the native format of one side or the
> other (or both, depending).  Whether the client or the server (or
> both) did some translation was one of the points that was negotiated.

I've not considered defering that decision to run-time.  I
make sure that the targeted node for a service CAN support the
data types that its clients require.  Then, the question is
whether to do the conversion client- or server- -side.

>> The goal in all this is to minimize the performance hit for the
>> "local" case; if everything an app needs resides on the local
>> node, then it shouldn't be encumbered by all this extra mechanism;
>> just the cost of a streamlined /I/PC!
> 
> Which goes back to identifying the server's host before trying to
> communicate.

I can identify local vs. remote relatively easily.  And, "local"
means very little payload processing so there's minimal risk
of the service NOT being local when that processing is complete.

But, "remote" has further complications as to *where* it is
located.  And, how to perform the conversion (if done before
transport).

E.g., if the targeted node is of the same "type" as the current
node, then it is effectively the same sort of processing as the
local case -- but for the introduction of the transport delay
(which increases the potential for a migration to hose things up).

OTOH, if the targeted node is of a different "type", the conversion
costs can be higher -- more time (remember, you don't OWN the processor
exclusively) and more opportunity for the world to change beneath your
feet!

I don't want to get into a situation where (potentially), an RMI
stalls in the outbound stack because it is repeatedly massaged to
adapt to a "target in motion".

>>> But [architecture agnostic] means either using a self describing
>>> binary protocol that encodes the type and width of each value (and
>>> also endianess if relevant) so the receiver knows what to do with
>>> it.  Or it means falling back on a text-based protocol.  Either
>>> way it means parsing on both sides.
>>
>> I have a dictionary of data types.  Instead of just picking from
>> a (relative) few, I let each API decide what is appropriate.
>> The thinking being that you wouldn't FORCE an application
>> talking to "itself" to adopt a particular subset of all available
>> types; so, why force parts of a DECOMPOSED version of that application
>> to adopt a similar set of constraints?
> 
> Well ... RPC generally needs to be language independent.  If my
> language has 2-3-4 tree (or, as below, "big rational") as a native
> type, that does not mean the RPC protocol can or should support it.

That's the case if you're exporting a generic sort of service.
Imagine taking an Xacto knife you your existing codebase and
deciding that THIS function will be remoted, but not THAT.
Do you then want to have to refactor the design so the
gazintas and cumzoutas are more "language neutral"?  How will
that impact performance?

[I know of an app that treats all numerics as ASCII strings for
interchange.  When profiled, it spends 90+% of its time converting
to and from int/float/text!]

>> In my example, a servant only needs to know how to convert
>> all compatible incoming formats *to* the formats used by the methods
>> it has exported.  The workload manager won't migrate an object/process
>> to a node for which converters are unavailable.
>>
>> E.g., Big Endian SPARC floating point likely won't have a
>> converter to Little Endian Intel Big Rational.  So, any ABI that
>> relies on BESPARC will likely be constrained to reside on a SPARC!
>>
>> Unfortunately, none of the language bindings are sufficiently specific
>> to automate these type descriptions.  int_t, bcd_t, Q5_3_t, etc.
>> may all map to the same fundamental type and, thus not gain any
>> protections from the language.
> 
> Unless you design a protocol that distinguishes them.

But then you can't expose them as raw types for the programmer to
make use of.

>>> https://en.wikipedia.org/wiki/Comparison_of_data-serialization_formats
>>>
>>>> The process obviously mirrors for return value(s) conversions.
>>>
>>> In a heterogenous system, the burden of "converting" - whatever that
>>> entails - usually is placed on the more powerful processor.  Of
>>> course, ordinarily the 'server' would be the more powerful processor -
>>> but in your system that's not necessarily the case.
>>>
>>> With self-describing data, each receiver can figure out what to do
>>> with what it receives.  But that's going to put additional burden on
>>> low power processors ...
>>
>> ...as well as overtaxed "high power" processors.  If, OTOH, a datum
>> is just tagged as "format #123" and is already known to be a valid
>> representation of a #123 datum on the originating client, then
>> the servant can just blindly invoke the (#123,clientflavor) to
>> (#123,serverflavor) routine.  The "parsing" is implicit.
> 
> To a point.  Absolutely, you can streamline by encoding structures and
> other collection types rather than individual data items.  But you
> still have to ensure the data makes sense: e.g., that floats are not
> NaN or IND, that arrays have all their elements initialized, that
> references to nodes in serialized graphs/trees are valid, etc.

Yes.  That was the point of "checking" the data in the client-side stub;
but deferring the conversion to the server-side stub.

Your implementation language wouldn't let you pass a float where an
int was required.  So, the RPC mechanism shouldn't let you PASS
a *value* that exceeds a Q11.5 representation *if* that is what
the IDL declares for that parameter.

>>>> [I haven't, yet, considered if anything undesirable "leaks" in either
>>>> of these approaches]
>>>
>>> What kind of "leaks" are you concerned with?
>>
>> A process shouldn't be able to determine much about how/where
>> it is executing *or* its affect on the rest of the system.
>> The system decides when/where/if you should execute.  And,
>> can change those decisions without forewarning.  So, anything
>> that you think you've sussed out NOW can be invalid moments
>> later.  Or, you may cease to exist those moments later!
>>
>> Granted, a process could (would!) know the processor family on
>> which it is executing (by compiling some machine-specific
>> datum into it's image -- which might even be the command
>> line used to invoke the compiler).  If it did this frequently,
>> it *might* be able to deduce that it has been migrated
>> ("Hmmm... I was running on Intel and now I appear to
>> be running on ARM") -- *if* the migration is to a different
>> processor family (or build environment).
>>
>> But, it shouldn't be able to deduce its relative priority,
>> the demand it may/maynot be placing on its hosting node,
>> whether an object invocation is actually serviced locally
>> or remotely, infer the load factor of the node backing that
>> object, etc.
> 
> If there's no way to ask ...
> 
> ISTM that much of the user programming was being done in a managed
> language.  If so, it should be (relatively) straightfoward to prevent
> tasks from learning about their environment.

Yes, that's true of USERLAND code.  But, developers can create
services that aren't in that language (for efficiency and
more implementation freedom).

A user can't (shouldn't) need to know if such a service is
a potential security risk before opting to install it.
(I don't want a closed ecosystem; and definitely don't
want to have to "vet" applications).

So, I try to observe behaviors at run-time and punish/ban
apps that don't play well with others.

This was one of the reasons I opted for the capability implementation
that I chose -- instead of making services responsible for validating
credentials (a bad actor could create nonsense credentials just
to consume server resources; in my scheme, that happens on the
"bad actor's" dime!)

>> E.g., passing bad data could leak the "localness" of the targeted
>> node because it would incur a transport delay before being
>> "validated" (if the checking was done in the servant).
> 
> Not if there *always* is a random "transport" delay.

But you want to be able to host a service locally to gain efficiency;
you wouldn't want to deliberately insert a (variable) delay just
to make the client THINK it might be interacting with a remote
server.

Of course, the fact that that server can *move* means any information
you glean from your interactions NOW may be invalid a moment later.

>> It could also leak the types of processes currently active on the
>> targeted node as its request vs those seen on the "local" node.
> 
> Only if different errors are possible and are directly due to the
> difference in host.

Hence the checking on client side.

E.g., if I can pass 199999Q44 to an RPC that expects a Q10.2
datum -- knowing it is invalid -- and get a response that I can
KNOW incurs a transport delay (because I know that the
checking is done at the server end), then I can profile the
transport delay.

If, OTOH, that error is generated locally BEFORE transport,
then there's no point in throwing bogus values at it.

Note that I can't "see" anything happening in the stubs.
So, I can't see if you're being an *sshole and take measures
to counter your actions.

Once something passes through the transport layer, the far-side
server can see the action and decide to drop the endpoint
(effectively barring you from using its services).  So,
if you try to hammer on a service, the service can just
stop responding to your actions -- effectively blocking
your execution (sync calls).

Back to comp.arch.embedded | Previous | Next — Previous in thread | 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