Hmm lets try Ascii, hope line wrapping doesn't wreck it.
|<----------------------| Multicast request
Multicast | |
response |---------------------->| Connection & auth
| | to discovered address
RPCSEC_GSS |<----------------------|
auth |---------------------->| RPCSEC_GSS Auth
| | success, request
| | bytes containing
| | service proxy
| Register service |
| proxy & attributes |------------------->| Registration
| Mange reg lease |<-------------------|
| | |
| | Match
|<-----------------| Lookup
| |
|----------------->|
| |
| | Authenticate Iot Service
| |
| | with bootstrap proxy
| |
| | Grant permission to download
| Auth client
|<--------------------------------------| and deserialize service proxy.
| Return service proxy
|-------------------------------------->|
| |
| | Prepare service proxy
|<--------------------------------------------------------------|
execute RPC function call
Function
|-------------------------------------------------------------->| with
constraints
| |
| |
IoT Device IoT Service Service
Registrar Client
On 5/11/2016 3:48 PM, Peter wrote:
Ok, will come back to the ascii art, I'll first attempt to attach a png.
There's an existing Java RPC implementation LGPL, with a maven build
tag => oncrpc4j-2.6.0
https://github.com/dCache/oncrpc4j
The implementation above supports /RPCSEC_GSS/ for security, although
there's a client side bug at present, but fixing it will be a lot less
work than reimplimenting it.
Basically RPC is the C equivalent of Java RMI.
Cheers,
Peter.
On 5/11/2016 10:32 AM, Niclas Hedhman wrote:
Sorry, I get the feeling that too much detail thinking is still in your
head. Hard for me to follow your thought process. A simple picture
(ascii
art would do) would go a long way...
Niclas
On Sat, Nov 5, 2016 at 8:04 AM, Peter<j...@zeus.net.au> wrote:
Thinking about C and power constrained devices, how about the
following:
* Write an ONC RPC java compiler, to create java code (instead of C)
client stubs.
* Provide support for TLS and constraints.
* Provide an IPv6 constrained device announcement (C) and discovery
(Java)
utilities. Create a standard so other languages can be supported by
others.
* Write a java utility and service that manages proxies, registers
discovered constrained devices with a lookup service and manages it's
lease. This utility can generate attributes (from Configuration) and
provide a bootstrap proxy (service) to allow clients to authenticate
and
obtain the smart proxy used to communicate directly with the device.
* Provide an interface for clients to notify the utility service when a
device is down.
Regards,
Peter.
Sent from my Samsung device.
Include original message
---- Original message ----
From: Zsolt Kúti<la.ti...@gmail.com>
Sent: 03/11/2016 05:37:45 pm
To: dev@river.apache.org
Subject: Re: River revamp
A small footprint implementation of Jini's lookup service written in C,
fully JCK compliant.
http://www.psinaptic.com/link_files/PsiNapticTelematics.pdf
A few years ago being involved in developing a streelighting management
system I tried to access them to no avail.
On Thu, Nov 3, 2016 at 8:09 AM, Peter<j...@zeus.net.au> wrote:
I've been conaidering that. It should be possible to implement
service
discovery in C, any serialized java bytes required for a proxy
could be
stored on the device.
So these devices are services, but not clients.
Will respond with more soon
Regards,
Peter.
Sent from my Samsung device.
Include original message
---- Original message ----
From: Niclas Hedhman<nic...@hedhman.org>
Sent: 03/11/2016 12:39:33 pm
To: dev@river.apache.org
Subject: Re: River revamp
"IoT" is a term that for this discussion is a bit too wide. The
"thermostat" runs with a kB-sized microcontroller and is
struggling to get
security features in at all, and the "home router" is typically
(still)
running from a 4-8MByte flash, which is impossible to even get a
Java ME
onto, so there is a lot of challenges when using "IoT"
as a blanket term.
So, I think a couple of concrete, do-able, use-cases
need to be highlighted
as examples, maybe a kind of "blue print" paper on how to
do it with River.
I totally agree that the "mothership" model is
outrageous from a consumer's
perspective, a nasty vendor lock-in, that all vendors are
pushing for and
all consumers/users need to fight the best we can.
A very active home automation project is called "OpenHAB", a flurry of
activity, connecting just about everything from your thermostat to
your
dog's toys. I have not looked closely at it, don't even know if it
is a
Java project as such, but it is one of the most active projects in the
field of Home IoT.
Cheers
Niclas
On Wed, Nov 2, 2016 at 10:41 PM, Patricia Shanahan<p...@acm.org>
wrote:
I think for this to work it is necessary to find out
where IoT people hang
out, and discuss it there Do they already have a plan for a secure
framework?
As a potential IoT user I'm looking for two things:
1. Security.
2. Server independence.
I don't want my thermostat to stop working if a server I don't
control
goes down or is taken out of service for any reason.
I think River may be a good basis for those features.
On 11/2/2016 7:22 AM, Bryan Thompson wrote:
I look at this as open source for secure IoT. The
need for security in
IoT
has been aptly demonstrated by recent DDOS
attaches based on compromised
devices.
I do feel that interop is critical to success here.
Do we have any lurkers from the IoT manufacturing
space here? People or
companies willing to invest time and resources for
a secure IOT platform?
Bryan
On Wednesday, November 2, 2016, Peter<j...@zeus.net.au> wrote:
Utilising most of the existing discovery code, we could use ipv6
multicast, for an exported remote object (service).
Then create a new class called RemoteDiscovery to discover a
service
dynamically, based on a name
So you export a service and it becomes dynamically discoverable.
It's not going to step on any Jini discovery lookup
stuff and it's going
to be easily deployed by new users.
Then once users realise there's more on offer they
can take advantage as
their understanding develops.
Cheers,
Peter.
Sent from my Samsung device.
Include original message
---- Original message ----
From: Niclas Hedhman<nic...@hedhman.org<javascript:;>>
Sent: 02/11/2016 05:31:26 pm
To: dev@river.apache.org<javascript:;>
Subject: Re: River revamp
To put a bit more meat on Peter's condensed list...
I put forward a proposal to sever the ties between
River and Jini itself,
and instead re-focus River to be a a secured network transport,
with
optional discovery. Starting point is of course the JERI
module and Peter's
work to secure this transport, but in the longer
term look at alternative
transport formats and eventually bindings to other
languages, which I think
will be the major hurdle for long term acceptance (no one is Java-
only
nowadays).
Jini's services, Reggie and so on, carries a lot of
negative connotation
among people who were around back then, and except
for where it has been
adopted, I doubt that there will be any new uptake,
so instead of making
Jini (and its specs) the focal point of River, make it
to "Examples of what
River can be used for".
Another example of what can be done with River could
eventually include
connectors for popular platforms, such as Zookeeper,
which could open
avenues for new blood coming to River
Concrete things; Apache Karaf is also a very small
community, yet they have
managed to put together a very exciting website, and I think River
community could "borrow" a lot of that work, making itself more
appealing,
promoting the new focus. I don't think much coding is
needed to get this
going, but packaging might be "fixed" to make
consumption of the core
functionality as easy as possible, preferably easier than that.
Once that is up-and-running starting the "reach
out" to other projects,
individuals and press releases.
I hope that this will inspire some to more action.
Niclas
On Wed, Nov 2, 2016 at 2:25 PM, Peter Firmstone<
peter.firmst...@zeus.net.au<javascript:;>
wrote:
A discussion recently ignited on river private
about revamping the project.
For the benefit of the wider developer community can we restate
the
suggestions here, feel free to reword, correct, reject or
suggest It was
along the lines of:
* Website revamp
* Remove Jini focus, with a historical section...
* Focus on new security features.
* Make getting started simple, with just the bare
bones basics, Extensible
remote invocation with secure serialization.
* Services, Javaspaces etc, become examples of what
can be done with
River, not what River is.
Regards,
Peter.
Sent from my Samsung device.
--
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java
--
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java
