W3C home > Mailing lists > Public > public-cloud@w3.org > November 2011

Engaging a cloud service

From: Russell Potter <russell.potter3@gmail.com>
Date: Wed, 30 Nov 2011 14:56:16 +1100
Message-ID: <CAF+nh-G47=wDZ6szGoFnsubhdctdq-Cmn6-=0jiw0-nUtERJ9A@mail.gmail.com>
To: public-cloud@w3.org
I'm working on an idea in which a
"client" (a process requiring some
cloud computation) "engages"
(uses)  a cloud service by sending
a multi-cast message to "224,0.0.1"
(the reserved "all routers" address),
indicating a requirement for work,

I;m thinking the client would then
wait for some appropriate time-out
period to elapse (the delay sho-
uldn't be too costly since this is a
one-off initialisation step) for resp-
onses from waiting cloud services,
which would each consist of an ont-
ology of the service's charging
regime.

The client would then choose the
most appropriate service  to "engage"
(from amongst those responding) ,
based on its needs

the client could,itself,be a cloud ser-
vice, in which case the service being
engaged would be a sub-cloud per-
forming some sub-set of the cloud
processing

My questions are:would this process
requiring a cloud service responding
to each client's  initial request for work
with an ontology over-tax the service?
(although I suppose this would depend
on the size of the ontology, and the resp-
onse load could always be spread across
multiple machines  ... )

and, since I'm not very conversant with
multi-casting, is the coding for sending
of a multi-cast network message the same
as with sending a "normal" message,
but to the "special"  multi-cast address ?

And. since multi-casting is relatively new,
is it implemented commonly enough that
its requirement for this idea to narrow its
up=take too much?

Russell
Received on Wednesday, 30 November 2011 03:56:45 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 30 November 2011 03:56:46 GMT