Ok, so this is more or less classic "surrogate" setup with JINI, right, with some additional SEC stuff, right?
And that is a cool way to achieve interoperability with smaller devices without ability to run a JVM, especially the original dream where devices don't know about each other ahead of time (except by some interface) I also see value where "IoT Service" doesn't bother with "Service Registrar" in the "Jini sense" and the "IoT Device" only participate in "Discovery" and then get a secure/trusted channel, onto which a light-weight protocol, such as MQTT or CoAP, can be funneled in either direction. On Sat, Nov 5, 2016 at 2:26 PM, Peter <[email protected]> wrote: > 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<[email protected]> 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<[email protected]> >>>> Sent: 03/11/2016 05:37:45 pm >>>> To: [email protected] >>>> 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<[email protected]> 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<[email protected]> >>>>> Sent: 03/11/2016 12:39:33 pm >>>>> To: [email protected] >>>>> 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<[email protected]> >>>>> 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<[email protected]> 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<[email protected]<javascript:;>> >>>>>>>> Sent: 02/11/2016 05:31:26 pm >>>>>>>> To: [email protected]<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< >>>>>>>> [email protected]<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 >>>>> >>>>> >>>>> >>>> >>> >> > -- Niclas Hedhman, Software Developer http://zest.apache.org - New Energy for Java
