NetKernel News Volume 6 Issue 1 - HTTP Server Update to Jetty 9, Raspberry Pi2, Holiday Project - Internet of Things Thing

NetKernel News Volume 6 Issue 1

February 6th 2015

Catch up on last week's news here, or see full volume index.

Repository Updates

NOTE: As announced previously, Java 6 is now end-of-life and since January 2015 all modules are built and target Java 7. Do not attempt to install updates if you are still running Java 6.

The following updates are available in the NKEE and NKSE repositories

  • demo-websockets-1.3.1.nkp.jar
    • Updated to use Jetty 9 websocket support (see below)
  • http-client-2.21.1.nkp.jar
    • Improved timeout detection on connected socket.
  • http-server-3.1.1.nkp.jar
    • Major Update to use Jetty 9.2.6
  • json-core-1.8.1.nkp.jar
    • HDS2 transreptors added and javax.json support
  • nkse-control-panel-1.40.1.nkp.jar
    • Styling tweaks
  • nkse-http-fulcrum-backend-3.1.1.nkp.jar
    • Updated to use Jetty 9 configuration
  • nkse-http-fulcrum-frontend-3.1.1.nkp.jar
    • Updated to use Jetty 9 configuration

The following updates are available in the NKEE repository

  • cache-ee-1.8.1.nkp.jar
    • Fixed potential NPE in statistics.
  • nkee-architecture-1.14.1.nkp.jar
  • *
  • nkee-http-fulcrum-backend-3.1.1.nkp.jar
    • Updated to use Jetty 9 configuration
  • nkee-http-server-3.1.1.nkp.jar
    • Updated to use Jetty 9

HTTP Server Update to Jetty 9

Today we have released a major update to the HTTP server stack.

The core HTTP server has moved from the very elderly Jetty 7 to the latest stable and modern Jetty 9.

NOTE: Jetty 9 targets Java 7 and no longer works at all on Java 6. It follows that this update means that it is imperative that you run NetKernel on Java 7.

Jetty 9 is a major step forward and incorporates many improvements over previous generations...

  • Abstracted protocol handling supports HTTP1.1, HTTPS, WebSockets, SPDY and, in future, HTTP2
  • Significant work to manage historical (and future?) JVM-level TLS bugs.
  • Much improved protocol negotiation for protocol upgrades (eg SPDY and HTTP2)
  • Full standards complient HTML5 websockets support.

Accompanying the http-server update are a set of updates to the default front-end and back-end HTTP fulcrums. The changes are necessary in order to provide new HTTPServerConfig.xml using Jetty 9's APIs.

If you have never modified the default fulcrum configurations then the new fulcrums will work seamlessly (of course make sure to install all the updates in one go!)

Custom HTTP Fulcrum Advisory

If you have modified, or have created your own custom HTTP fulcrum then please take note.

The declarative XML configuration for Jetty 9 has changed and so your etc/HTTPServerConfig.xml must be modified to work with the new Jetty 9 libraries.

Fortunately the changes are straightforward and are mostly syntactical - probably the best way to migrate your own configuration is to examine our old and new front-end fulcrum configurations...

One hard won piece of knowledge is that the XML configuration must now declare a DTD declaration (I know I know), so in the new file you will see the first lines now must look like this...

<?xml version="1.0"?>
<!DOCTYPE Configure PUBLIC "-//Jetty//Configure//EN" "">

ROC-Domain / Application Implications

As before, the front-end fulcrum's HTTP configuration is documented inline and comes preconfigured with a commented out TLS socket and NCSA logging options.

Its unfortunate that the configuration has to be changed and we understand if this causes issues - if you need assistance making the necessary changes please get in touch and we'll help out.

We repeat, if you have not changed your existing fulcrums then the update will not affect you.

An interesting observation is that this quite radical re-engineering of the HTTP stack has absolutely no affect on the ROC-domain - the HTTPBridge and RESTOverlay are identical at the resource request level - even though they're now working with a brand new server front-end. This is as expected but serves as a practical example and validation that moving up to the ROC level eliminates system brittleness.

Raspberry Pi 2 - Another great NetKernel server

Last time we were enthusing about the Odroid-C1 as a very low cost and competent NetKernel server. We're delighted to learn that Raspberry Pi has announced the new RPi 2 with quad core and 1GB memory.

Demand has been huge and we've not yet received our units, but based on the spec (Cortex-A7 as opposed to Odroid's Cortex-A5 architecture) then we would expect that this will be a pretty nifty NetKernel server.

As soon as we get the NK-Mark numbers we'll let you know.

My Holiday Project: An Internet of Things Thing

Talking of Raspberry Pi's, here's a little NetKernel/Pi IoT project I completed recently: I reverse engineered my garage door opener and turned it into an "IoT-Thing".

My garage door has a conventional RF-button that toggles the open/close cycle - its very short range and very limited and you never remember to pick it up and take it with you.

So I wanted to make my door an internet device with the objective that I could open and close the door from a button on my phone, which is always with me. Also, if I get a delivery and I'm not home, I can leave a note to call me and I can open the door from work, so the delivery guy can just drop it off inside the garage.

It's only just moved off the prototype bench - so forgive the lack of enclosure and the rats nest of wires - but here is the hardware. A Rasberry Pi Model B and some sensors/actuators...

Here's a view from the business end - a relay for shorting the garage door control pins to ground, a PIR motion detector for automating the light, and (not shown) a reed switch detecting the garage door position. For good measure there's also a DHT-22 temperature and humidity sensor.

The hardware is pretty simple and all the elements are independent...

  • Garage door relay (out)
  • Motion sensor (in)
  • Temperature sensor (in)
  • Door position reed switch sensor (in)

Each one is interfaced (with appropriate pull-up/pull-down resistors) to the RPi GPIO bus. Simple python scripts on the Pi are used to either detect pin interrupts (motion sensor) or apply an action (relay). There is no server platform on the pi. Its just a basic control / event detector.

When an event is detected it calls a NetKernel hosted REST webhook - each webhook is implemented using Tony's latest and greatest Polestar IoT Hub (he's being coy about announcing it so if you go to that link he might have hidden it!). This is the generalisation of his original home monitor "Death-Star" stack which has managed his home with NetKernel for about 8-years.

So I have Polestar sitting as an IoT Hub on my home server. I have available endpoints for controlling LightWaveRF switches - so the motion detector causes a webhook to fire and send a request to the LWRF endpoint which sends a UDP packet to switch the light on - total round trip is amazingly fast (around 100ms).

Polestar provides me with an ROC resource to monitor the state of all the IoT "Things" I am interested in. Here, for example, I have the garage door state (a resource) and the light state (another resource - everything is a resource!)...

On my phone I have a button on my homescreen that, when I press it, plays a beep and makes a REST request to a Polestar WebHook. The WebHook then fires up an NK endpoint that makes an SSH request to the Pi to run the python to toggle the relay to short the pins on the garage door. The result is that my phone is now functionally identical to the RF-button but is using TCP-IP and resource oriented endpoints instead of nasty old analogue RF.

By Tony's standard's I'm a bit of an amateur - but I've got a pretty fancy weather station, our family presence status is available for control and automation of the heating etc etc. Tony has promised that he's soon going to write a full article on his "Death Star 2" so watch this space.

Total cost of my IoT Garage was $45 including the Pi.

Finally, something to think about until next time, how is a lock and key related to the ROC model? More particularly in ROC terms, what is a key?

The next number is always 19

I was delighted to discover the answer to a really annoying situation in maths education that bugged me as a kid. You remember all those maths exams where they give you a sequence of integers and then you are asked to give the next term in the sequence...

1, 1, 2, 3, 5 ...

It used to really really piss me off that you were supposed to follow the rules and give the obvious answer (ie the one where they assume you have identified the context - the Fibonnaci numbers or whatever - and then put down the next one).

It used to annoy me since it seemed like it must be the case that there could be a possibility of another answer - who were these maths examiners to have excluded all other possible viable ways of generating that specific sequence? It was also of course impossible to argue - you just had to put down the obvious answer!

Well I am very pleased to have found out that I was not alone - in his 1972 book Maths made difficult Carl Linderholm dedicates an entire chapter to show that for any sequence of numbers the next number is always 19!

Why? Well because a very well known and utilized mathematical tool is the Lagrange Interpolation polynomial. It will provide a precise polynomial that creates a valid mathematical rule between any sequence of numbers!!

So a perfectly valid mathematical answer to the question in the exam is always...

1, 1, 2, 3, 5, 19

I don't know if its a good idea to explain this to my kids though - I doubt that the teacher/exam markers are going to take kindly to a lagrange polynomial in the answer...

Happy New Year - have a great weekend.


Please feel free to comment on the NetKernel Forum

Follow on Twitter:

@pjr1060 for day-to-day NK/ROC updates
@netkernel for announcements
@tab1060 for the hard-core stuff

To subscribe for news and alerts

Join the NetKernel Portal to get news, announcements and extra features.

NetKernel will ROC your world

Download now
NetKernel, ROC, Resource Oriented Computing are registered trademarks of 1060 Research

© 2008-2011, 1060 Research Limited