Month: April 2014

GnatMQ nel Cloud : un broker MQTT su Microsoft Azure

Nel corso di questo post, vedremo come sia semplice eseguire GnatMQ, il broker MQTT per il .Net Framework, nel Cloud utilizzando la piattaforma Microsoft Azure. L’esecuzione del broker può essere avviata attraverso un Worker Role che rientra tra i “Cloud Services” offerti da Microsoft.

Creazione del Cloud Service

Nel “Server Explorer”, clicchiamo con il tasto destro su “Windows Azure” e su “Connect to Windows Azure…” ed eseguiamo il login utilizzando le nostre credenziali di accesso di Azure (quelle che usiamo nel management portal online).

0825.01_thumb_4E4E2CA1

Il “Server Explorer” si aggiorna e visualizza tutti i servizi “Windows Azure” attualmente attivi con il nostro account (Cloud Services per web role e worker role, Service Bus con relativi namespace, Virtual Machines e così via).

4527.02_thumb_22312FB0

Poiché il nostro obiettivo è quello di eseguire il broker GnatMQ in un worker role, dobbiamo creare un nuovo “Cloud Services”, cliccando con il tasto destro su di esso e selezionando “Create Cloud Service…”. Selezioniamo la subscription a cui associare il nuovo servizio, il nome e la regione in cui esso sarà eseguito.

7178.03_thumb_131A50D6

La creazione di un nuovo “Cloud Services” può essere eseguita anche online utilizzando il management portal nella sezione “Compute”, “Cloud Service” e “Quick Create”; le informazioni richieste sono le medesime di Visual Studio a meno della sottoscrizione che è implicita avendo fatto il login online.

5826.04_thumb_27336D5F

Creazione del Worker Role

Utilizzando Visual Studio, creiamo un nuovo progetto di tipo “Windows Azure Cloud Service” incluso nel template “Cloud”, assegnandogli un nome (es. AzureGnatMQ).

8750.05_thumb_4609E13D

Un “Cloud Service” può ospitare uno o più servizi tra Web Role, per applicazioni ASP.NET e servizi WCF, e Worker Role tipicamente per operazioni di backend talvolta strettamente legate anche al Service Bus. Nel nostro caso, aggiungiamo solo un Worker Role assegnandogli il nome GnatMQWorkerRole e creiamo il corrispondente progetto.

7673.06_thumb_1744289B

La prima operazione da fare consiste nello scaricare da CodePlex i sorgenti del broker GnatMQ in modo da aggiungere il progetto MqttBroker all’interno della solution appena generata e successivamente come reference al progetto GnatMQWorkerRole; nulla vieta di compilare il broker separatamente e poi aggiungere direttamente un riferimento all’assembly.

La solution AzureGnatMQ sarà costituita dai seguenti progetti :

  • AzureGnatMQ con tutte le impostazioni relative al “Cloud Service” necessarie per il deploy su Azure;
  • GnatMQWorkerRole con il Worker Role che dovrà ospitare il broker MQTT;
  • MqttBroker che implementa GnatMQ;

1616.07_thumb_08997CB6

GnatMQ in esecuzione nel Worker Role

Apriamo il file sorgente relativo al Worker Role e creiamo un campo privato di tipo MqttBroker; nel metodo OnStart() istanziamo la classe MqttBroker ed eseguiamo su di essa il metodo Start(). Con questi due semplicissimi step abbiamo creato ed avviato l’esecuzione di GnatMQ nel Worker Role !

public override bool OnStart()
{
 // Set the maximum number of concurrent connections
 ServicePointManager.DefaultConnectionLimit = 12;

 // For information on handling configuration changes
 // see the MSDN topic at http://go.microsoft.com/fwlink/?LinkId=166357.

 this.broker = new MqttBroker();
 this.broker.Start();

 return base.OnStart();
}

Come sappiamo, il broker MQTT utilizza la porta 1883 per accettare le connessioni TCP in ingresso (non SSL); per questo motivo, dobbiamo renderlo accessibile dall’esterno aggiungendo un EndPoint al Worker Role.

Per farlo, apriamo le proprietà del Worker Role stesso (non il progetto ma l’istanza che si trova nella sottocartella “Roles” di “AzureGnatMQ”) e la tab “Endpoints”. Aggiungiamo un nuovo EndPoint con le seguenti caratteristiche :

  • nome “MQTT” (oppure uno qualsiasi);
  • di tipo Input;
  • protocollo TCP;
  • porta pubblica 1883;

0825.08_thumb_6E591391

Il broker è a tutti gli effetti pronto per essere compilato e distribuito sul Cloud. Per verificarne il funzionamento in locale, possiamo lanciarlo in esecuzione grazie all’emulatore di Windows Azure.

Pubblicazione su Azure

La pubblicazione su Azure è alquanto semplice grazie all’integrazione con Visual Studio (anche se potremmo eseguirla dal management portal online). Clicchiamo con il tasto destro sul progetto “AzureGnatMQ” (relativo al Cloud Service) e poi su “Publish”. Dobbiamo scegliere la sottoscrizione da utilizzare, il relativo cloud service in cui far eseguire il worker role, l’ambiente (produzione o staging) e la configurazione da utilizzare.

8640.09_thumb_0D9BBA65

La pubblicazione viene eseguita nel giro di qualche minuto e possiamo seguirne lo stato di avanzamento nella finestra “Windows Azure Activity Log”.

6406.10_thumb_21B4D6EE

Una volta terminata la pubblicazione, il broker MQTT sarà disponibile online ed accessibile all’indirizzo <name>.cloudapp.net oppure al VIP (Virtual IP Address) assegnato da Azure e reperibile nella dashboard del Cloud Service.

2308.11_thumb_6BCFE1D3

Advertisements

IoT@Work : evento “romano” dedicato all’Internet of Things !

3515.domusdotnet20262x60_thumb_130D09A3 1067.logotinyclrit_275x80_thumb_396EECEE

DomusDotNet, community romana orientata alle tecnologie Microsoft, e TinyCLR.it. community italiana dedicata al .Net Micro Framework e di cui faccio parte, hanno organizzato per Venerdì 6 Giugno 2014 a Roma (presso la sede Microsoft) un evento completamente gratuito e dedicato all’Internet of Things : IoT@Work !

Insieme ad altri due MVP su Windows Embedded, Mirco Vanini e Lorenzo Maiorfi, avrò l’onore di essere speaker, per la prima volta anche io nelle vesti di MVP, con una sessione dedicata al panorama dei principali protocolli per l’IoT ed M2M communication.

Dopo una mattinata dedicata allo studio dell’IoT ed alle tecnologie che lo caratterizzano, il pomeriggio vedrà protagonista un’interessantissima demo “corale” con tutti gli speaker con un approccio di realizzazione di un sistema di home ed industrial automation.

L’evento è assolutamente da non perdere !! Vi aspettiamo !!

M2Mqtt : release 3.3.0.0 per il client MQTT su piattaforma .Net

Lo sviluppo della libreria M2Mqtt continua …. ormai giunta alla versione 3.3.0.0 !

Questa volta le nuove funizionalità riguardano due richieste provenienti dalle persone che la stanno utilizzando.

In primo luogo, ho aggiunto più overload al metodo Connect(), poichè da quanto ho rimosso i parametri di default (per questioni di compatibilità con le versioni precedenti del .Net Framework) ho lasciato il costruttore più complesso che richiede tutti i parametri. Molte persone, non conoscendo bene il protocollo MQTT, si sono trovate in difficoltà nel decidere quali valori passare ai parametri meno noti (will message, clean session, …).

L’ulteriore nuova funzionalità riguarda l’evento di disconnessione del client dal broker MQTT che è stato richiesto sul sito ufficiale CodePlex. La classe MqttClient espone l’evento MqttMsgDisconnected che viene sollevato quando è rilevata una condizione di mancata connessione con il broker e tipicamente in due casi :

  • In caso di assenza di traffico dati, al messaggio di PINGREQ (relativo al keep alive) non si riceve la risposta PINGRESP dal broker;
  • La trasmissione o la ricezione dati verso/da il broker fallisce per un problema di connessione;

Anche questa volta la nuova versione è disponibile su CodePlex e su Nuget, oltre ad aver aggiornato il corrispondente componente M2Mqtt4CE per Windows Embedded Compact 2013 !

Breaking changes ….

Per quanto riguarda Nuget, gli assemblies M2Mqtt relativi al .Net Micro Framework 4.3 sono stati aggiornati all’ultima release QFE1; essi non funzionano con la versione RTM precedente, poichè gli assemblies del micro framework sono passati dalla versione 4.3.0.0 alla 4.3.1.0.

Raspberry Pi e Windows Azure Service Bus via AMQP con la libreria Qpid Proton C

Nel corso di questa tutorial vedremo in che modo sia possibile utilizzare la Raspberry Pi come client AMQP (Advanced Message Queuing Protocol) e collegarla al Windows Azure Service Bus che supporta la versione AMQP 1.0.

Ovviamente, la scelta della libreria client da utilizzare è quasi obbligata : Apache Qpid Proton. Tale libreria sviluppata in C fornisce comunque il bindings per altri linguaggi tra cui Java, Python e PHP ma nel corso dell’articolo utilizzeremo solo la versione nativa.

Generalmente, la Raspberry Pi viene utilizzata con la distribuzione Raspbian (basata su Debian) che è a tutti gli effetti una distribuzione Linux. Ciò vuol dire che possiamo installare la libreria Qpid Proton come faremo su un normale distribuzione Ubuntu su un PC oppure su una macchina virtuale ad esempio su Windows Azure.

Connessione alla Raspberry Pi

Tutte le operazioni che seguono possono essere effettuate accedendo direttamente alla Raspberry Pi attraverso un monitor, una tastiera ed un mouse collegati ad essa oppure in remoto attraverso l’utilizzo di SSH.

La seconda soluzione è sicuramente la più comoda, utilizzado un tool come Putty e specificando l’indirizzo IP della nostra board, la porta (tipicamente la 22) ed il tipo di connessione (SSH).

01

02

Installazione dei prerequisiti

Una volta effettuato l’accesso, in primo luogo bisogna installare dei componenti fondamentali tra cui GCC, CMAKE (sistema di build utilizzato da Qpid) e la libreria UUID per la generazione di identificativi univoci.

sudo apt-get install gcc cmake uuid-dev

Poichè Qpid utilizza SSL e il Service Bus necessita di questo prerequisito per la connessione, dobbiamo installare OpenSSL nel nostro sistema (che in realtà potrebbe essere già installato).

sudo apt-get install openssl

La presenza della libreria OpenSSL non include la presenza degli header file e delle librerie statiche necessarie per lo sviluppo. Bisogna quindi installare la libssl-dev.

sudo apt-get install libssl-dev

Non essendo interessato ad alcun binding con altri linguaggi, possiamo evitare di installare i package per Python, PHP e così via, passando direttamente al download della libreria dal sito ufficiale. Inoltre, non installiamo le dipendenze che riguardano la generazione automatica della documentazione.

Download e compilazione della Qpid Proton

Dal sito ufficiale possiamo ricavare uno dei mirror da cui scaricare la libreria nella sezione “Download” per poi scaricarla usando il tool WGET.

pi@raspberrypi ~ $ wget http://apache.fastbull.org/qpid/proton/0.6/qpid-proton-0.6.tar.gz
–2014-04-16 07:09:52–  http://apache.fastbull.org/qpid/proton/0.6/qpid-proton-0.6.tar.gz
Resolving apache.fastbull.org (apache.fastbull.org)… 194.116.84.14
Connecting to apache.fastbull.org (apache.fastbull.org)|194.116.84.14|:80… connected.
HTTP request sent, awaiting response… 200 OK
Length: 629147 (614K) [application/x-gzip]
Saving to: `qpid-proton-0.6.tar.gz’

100%[======================================>] 629,147     1.00M/s   in 0.6s

2014-04-16 07:09:53 (1.00 MB/s) – `qpid-proton-0.6.tar.gz’ saved [629147/629147]

Dopo il download. estraiamo il contenuto del file.

tar xvfz qpid-proton-0.6.tar.gz

Entriamo nella cartella appena create (qpid-proton-0.6) e creiamo una cartella “build” in cui faremo generare dal tool CMAKE il corrispondente Makefile per la compilazione della libreria.

mkdir build

cd build

cmake -DCMAKE_INSTALL_PREFIX=/usr ..

L’output del comando cmake dovrebbe essere il seguente.

pi@raspberrypi ~/qpid-proton-0.6/build $ cmake -DCMAKE_INSTALL_PREFIX=/usr ..
— The C compiler identification is GNU 4.6.3
— Check for working C compiler: /usr/bin/gcc
— Check for working C compiler: /usr/bin/gcc — works
— Detecting C compiler ABI info
— Detecting C compiler ABI info – done
— PN_VERSION: 0.6
— Found Java: /usr/bin/java
— Java version: 1.7.0.40. javac is at: /usr/bin/javac
— Locations of Bouncycastle 1.47 jars: BOUNCYCASTLE_BCPROV_JAR-NOTFOUND BOUNCYCASTLE_BCPKIX_JAR-NOTFOUND
— Won’t build proton-j-impl because one or more Bouncycastle jars were not found. PROTON_JAR_DEPEND_DIR was: /usr/share/java
— Found OpenSSL: /usr/lib/arm-linux-gnueabihf/libssl.so;/usr/lib/arm-linux-gnueabihf/libcrypto.so (found version “1.0.1e”)
— Looking for clock_gettime
— Looking for clock_gettime – not found.
— Looking for clock_gettime in rt
— Looking for clock_gettime in rt – found
— Looking for uuid_generate
— Looking for uuid_generate – not found.
— Looking for uuid_generate in uuid
— Looking for uuid_generate in uuid – found
— Looking for strerror_r
— Looking for strerror_r – found
— Looking for atoll
— Looking for atoll – found
— Could NOT find SWIG (missing:  SWIG_EXECUTABLE SWIG_DIR)
— Could NOT find Doxygen (missing:  DOXYGEN_EXECUTABLE)
— Looking for include file inttypes.h
— Looking for include file inttypes.h – found
— Can’t locate the valgrind command; no run-time error detection
— Cannot find rspec, skipping rspec tests
— Cannot find both Java and Maven: testing disabled for Proton-J and JNI Bindings
— Configuring done
— Generating done
— Build files have been written to: /home/pi/qpid-proton-0.6/build

Ci sono alcuni warning sull’impossibilità di trovare il runtime Java, Swig e Doxygen. Come già anticipato, non siamo interessato al binding con altri linguaggi ed alla generazione automatica della documentazione per cui possiamo non preoccuparci di tali warning.

L’ultimo step consiste nell’utilizzare il tool MAKE per elaborare il Makefile appena generato da cmake ed installare la libreria nel sistema.

sudo make install

Al termine della compilazione, la libreria è installata nel sistema in corrispondenza della cartella /usr (come specificato nel primo comando CMAKE eseguito) ed in particolare :

  • /usr/share/proton : contiene un esempio di utilizzo;

  • /usr/bin e /usr/lib : contengono i file relativi la libreria vera e propria;

  • /usr/include/proton : contiene gli header file necessari per lo sviluppo di un’applicazione;

Esempio di invio e ricezione su Service Bus

Per poter testare il corretto funzionamento della libreria utilizziamo i semplici esempi di send e receive distribuiti con la libreria stessa durante l’installazione.

cd /usr/share/proton/examples/messenger/

Anche in questo caso possiamo sfruttare il tool CMAKE per la generazione del Makefile necessario alla compilazione (da notare che è necessario l’esecuzione come Super User).

sudo mkdir build

cd build

sudo cmake ..

sudo make all

Al termine della compilazione avremo i due file eseguibili recv e send corrispondenti a due semplici applicativi che permettono di ricevere ed inviare messaggi ad una coda via AMQP.

Per fare questo, creiamo un nuovo namespace per il Service Bus sul portale di Microsoft Azure ed in corrispondenza di questo anche una queue. Nel mio caso, il namespace è qpidproton.servicebus.windows.net e la coda banalmente “myqueue”. Attraverso il portale dobbiamo ricavare due parametri fondamentali per la connessione che sono lo SharedSecretIssuer (tipicamente “owner”) e lo SharedSecretValue.

03

L’indirizzo per la connessione al Service Bus avrà la seguente struttura :

amqps://username:password@namespace.servicebus.windows.net/queue_name

Poichè il Service Bus usa le connessioni SSL, dobbiamo utilizzare AMQPS in luogo del semplice AMQP.

Per inviare un messaggio con testo “Hello” alla queue dobbiamo eseguire l’applicazione send nel modo seguente.

./send –a amqps://username:password@namespace.servicebus.windows.net/queue_name Hello

Per poter ricevere un messaggio dalla stessa queue possiamo utilizzare l’applicazione recv nel modo seguente.

./recv amqps://username:password@namespace.servicebus.windows.net/queue_name

Con un risultato di questo tipo.

Address: amqps://username:password@namespace.servicebus.windows.net/queue_name
Subject: (no subject)
Content: “Hello”

Microsoft Azure per l’Internet of Things

Immagine

Come ulteriore conferma che la Microsoft vuole entrare a far parte del business dell’Internet of Things, è stata rilasciata una “limited preview” di un nuovo prodotto su Azure : Microsoft Azure Intelligent System Service.

L’obiettivo primario è quello di fornire un’unica piattaforma in grado di acquisire dati generati da sistemi eterogenei (e quindi anche non Microsoft) per poterli elaborare ed analizzare in tempo reale con strumenti come HDInsight.

Le principali potenzialità saranno :

  • Connettività : possibilità di connettere un qualsiasi device indipendentemente dal sistema operativo onboard;
  • Configurazione : definizione di regole per automatizzare i processi sui device;
  • Amministrazione : possibilità di monitorare, configurare ed aggiornare i device sul campo;
  • Estendibilità : maggiore scalabilità ed efficienza grazie all’infrastruttura basata sul Cloud;

Al seguente link, è possibili richiedere la limited preview alla quale avranno accesso i potenziali utilizzatori a seguito di un questionario con cui valutare il progetto da realizzare.

Qpid Proton C su una macchina virtuale Ubuntu Server 12.04 in Windows Azure per l’utilizzo del Service Bus con AMQP : creazione, configurazione, compilazione ed uso

Uno dei protocolli maggiormente utilizzati nell’ambito del messaging che può trovare applicazione anche nell’Internet of Things è l’AMQP (Advanced Message Queuing Protocol), ormai già standard OASIS da alcuni anni e giunto alla versione 1.0.

Il servizio Service Bus offerto da Windows Azure supporta tale protocollo che, essendo standard, garantisce la comunicazione tra client sviluppati su piattaforme diverse. Nel caso di una piattaforma Microsoft non abbiamo alcun problema grazie al Windows Azure SDK (giunto alla versione 2.3) che astrae completamente il protocollo di comunicazione sottostante con il Service Bus (AMQP, SBMP, …) grazie al suo modello di programmazione.

Nel caso in cui ci troviamo a lavorare su un sistema non Microsoft, una delle migliori scelte è quella di adottare le librerie del progetto Apache Qpid ed in particolare la Qpid Proton. Tale libreria sviluppata in C fornisce comunque il bindings per altri linguaggi tra cui Java, Python e PHP.

Nel corso di questo tutorial, vedremo come sia possibile creare una macchina virtuale Ubuntu Server 12.04 su Windows Azure, installare ed utilizzare la libreria Qpid Proton per inviare e ricevere messaggi attraverso il Service Bus con il protocollo AMQP. Ovviamente, tale procedura può essere utilizzata anche nel caso di un qualsiasi sistema Ubuntu 12.04 (anche client e non server) non necessariamente su Windows Azure ma sul nostro PC in locale.

Creazione della macchina virtuale su Windows Azure

In primo luogo dobbiamo creare una macchina virtuale con il sistema operativo Ubuntu Server 12.04 LTS su Windows Azure. Per farlo, è necessario collegarsi al Management Portal e loggarsi con il proprio account. Una volta loggati, selezioniamo sulla sinistra “Virtual Machines” e cliccate su “Create a Virtual Machine”; utilizziamo l’opzione di “Quick create” impostando :

  • DNS Name : il nome DNS da assegnare alla macchina virtuale;
  • Image : l’immagine del sistema operativo da utilizzare che in questo caso è “Ubuntu Server 12.04 LTS”;
  • Size : la “dimensione” della macchina virtuale in base alle nostre necessità;
  • New password/Confirm : password e relativa conferma per l’utente creato di default che si chiama “azureuser”;
  • Region/Affinity Group : la regione (data center) in cui creare la nostra macchina virtuale;

Clicchiamo su “Create a virtual machine” per avviare la creazione della macchina virtuale.

01_create_vm

Al termine del processo di creazione che dura alcuni minuti avremo la conferma.

02_vm_created

Per poterci collegare alla macchina virtuale in remoto, è necessario conoscere l’endpoint per l’accesso via SSH che possiamo trovare cliccando sul nome della macchina virtuale appena creata (nel mio caso ppatiernoubuntu) e poi sul tab “Endpoints” (nel mio caso la porta è la 22).

03_SSH_endpoint

Scarichiamo un client Telnet come Putty per poterci collegare, inserendo l’host name e la porta corretta.

04_Putty

All’apertura della console digitiamo “azureuser” come nome utente e la corrispondente password che abbiamo scelto nella fase di creazione della macchina virtuale.

Installazione dei prerequisiti

Il file README distribuito con la libreria Qpid Proton descrive abbastanza nel dettaglio la procedura per l’installazione della libreria ma fa riferimento al tool YUM che su Ubuntu non abbiamo nativamente a disposizione; in luogo di esso usiamo APT. Inoltre, alcune libreria non hanno esattamente lo stesso nome come descritto nel file README.

In genere, la prima operazione che faccio su una macchina Ubuntu è quella di installare il package “build-essential” con tutti gli strumenti principali per la compilazione, eseguendo il comando :

sudo apt-get install build-essential

Il passo successivo è quello di installare le dipendenze principali tra cui GCC (che avremo già installato grazie al package “build-essential”), CMAKE (sistema di build utilizzato da Qpid) e la libreria UUID per la generazione di identificativi univoci (un pò come il nostro caro Guid).

sudo apt-get install gcc cmake uuid-dev

Poichè Qpid utilizza SSL e il Service Bus necessita di questo prerequisito per la connessione, dobbiamo installare OpenSSL nel nostro sistema (che in realtà potrebbe essere già installato).

sudo apt-get install openssl

La presenza della libreria OpenSSL non include la presenza degli header file e delle librerie statiche necessarie per lo sviluppo. Bisogna quindi installare la libssl-dev.

sudo apt-get install libssl-dev

Non essendo interessato ad alcun binding con altri linguaggi, possiamo evitare di installare i package per Python, PHP e così via, passando direttamente al download della libreria dal sito ufficiale. Inoltre, non installiamo le dipendenze che riguardano la generazione automatica della documentazione.

Download e compilazione della Qpid Proton

Dal sito ufficiale possiamo ricavare uno dei mirror da cui scaricare la libreria nella sezione “Download” per poi scaricarla usando il tool WGET.

azureuser@ppatiernoubuntu:~$ wget http://apache.fastbull.org/qpid/proton/0.6/qpid-proton-0.6.tar.gz
–2014-04-16 07:09:52– 
http://apache.fastbull.org/qpid/proton/0.6/qpid-proton-0.6.tar.gz
Resolving apache.fastbull.org (apache.fastbull.org)… 194.116.84.14
Connecting to apache.fastbull.org (apache.fastbull.org)|194.116.84.14|:80… connected.
HTTP request sent, awaiting response… 200 OK
Length: 629147 (614K) [application/x-gzip]
Saving to: `qpid-proton-0.6.tar.gz’

100%[======================================>] 629,147     1.00M/s   in 0.6s

2014-04-16 07:09:53 (1.00 MB/s) – `qpid-proton-0.6.tar.gz’ saved [629147/629147]

Dopo il download. estraiamo il contenuto del file.

tar xvfz qpid-proton-0.6.tar.gz

Entriamo nella cartella appena create (qpid-proton-0.6) e creiamo una cartella “build” in cui faremo generare dal tool CMAKE il corrispondente Makefile per la compilazione della libreria.

mkdir build

cd build

cmake -DCMAKE_INSTALL_PREFIX=/usr ..

L’output del comando cmake dovrebbe essere il seguente.

azureuser@ppatiernoubuntu:~/qpid-proton-0.6/build$ cmake -DCMAKE_INSTALL_PREFIX=/usr ..
— The C compiler identification is GNU
— Check for working C compiler: /usr/bin/gcc
— Check for working C compiler: /usr/bin/gcc — works
— Detecting C compiler ABI info
— Detecting C compiler ABI info – done
— PN_VERSION: 0.6
— Could NOT find Java (missing:  Java_JAVA_EXECUTABLE Java_JAR_EXECUTABLE Java_JAVAC_EXECUTABLE Java_JAVAH_EXECUTABLE Java_JAVADOC_EXECUTABLE)
— Found OpenSSL: /usr/lib/x86_64-linux-gnu/libssl.so;/usr/lib/x86_64-linux-gnu/libcrypto.so (found version “1..1”)
— Looking for clock_gettime
— Looking for clock_gettime – not found.
— Looking for clock_gettime in rt
— Looking for clock_gettime in rt – found
— Looking for uuid_generate
— Looking for uuid_generate – not found.
— Looking for uuid_generate in uuid
— Looking for uuid_generate in uuid – found
— Looking for strerror_r
— Looking for strerror_r – found
— Looking for atoll
— Looking for atoll – found
— Could NOT find SWIG (missing:  SWIG_EXECUTABLE SWIG_DIR)
— Could NOT find Doxygen (missing:  DOXYGEN_EXECUTABLE)
— Looking for include files INTTYPES_AVAILABLE
— Looking for include files INTTYPES_AVAILABLE – found
— Can’t locate the valgrind command; no run-time error detection
— Cannot find ruby, skipping ruby tests
— Cannot find both Java and Maven: testing disabled for Proton-J and JNI Bindings
— Configuring done
— Generating done
— Build files have been written to: /home/azureuser/qpid-proton-0.6/build

Ci sono alcuni warning sull’impossibilità di trovare il runtime Java, Swig e Doxygen. Come già anticipato, non siamo interessato al binding con altri linguaggi ed alla generazione automatica della documentazione per cui possiamo non preoccuparci di tali warning.

L’ultimo step consiste nell’utilizzare il tool MAKE per elaborare il Makefile appena generato da cmake ed installare la libreria nel sistema.

sudo make install

Al termine della compilazione, la libreria è installata nel sistema in corrispondenza della cartella /usr (come specificato nel primo comando CMAKE eseguito) ed in particolare :

  • /usr/share/proton : contiene un esempio di utilizzo;
  • /usr/bin e /usr/lib : contengono i file relativi la libreria vera e propria;
  • /usr/include/proton : contiene gli header file necessari per lo sviluppo di un’applicazione;

Esempio di invio e ricezione su Service Bus

Per poter testare il corretto funzionamento della libreria utilizziamo i semplici esempi di send e receive distribuiti con la libreria stessa durante l’installazione.

cd /usr/share/proton/examples/messenger/

Anche in questo caso possiamo sfruttare il tool CMAKE per la generazione del Makefile necessario alla compilazione (da notare che è necessario l’esecuzione come Super User).

sudo mkdir build

cd build

sudo cmake ..

sudo make all

Al termine della compilazione avremo i due file eseguibili recv e send corrispondenti a due semplici applicativi che permettono di ricevere ed inviare messaggi ad una coda via AMQP.

Per fare questo, creiamo un nuovo namespace per il Service Bus sul portale di Microsoft Azure ed in corrispondenza di questo anche una queue. Nel mio caso, il namespace è qpidproton.servicebus.windows.net e la coda banalmente “myqueue”. Attraverso il portale dobbiamo ricavare due parametri fondamentali per la connessione che sono lo SharedSecretIssuer (tipicamente “owner”) e lo SharedSecretValue.

05_sb_access

L’indirizzo per la connessione al Service Bus avrà la seguente struttura :

amqps://username:password@namespace.servicebus.windows.net/queue_name

Poichè il Service Bus usa le connessioni SSL, dobbiamo utilizzare AMQPS in luogo del semplice AMQP.

Per inviare un messaggio con testo “Hello” alla queue dobbiamo eseguire l’applicazione send nel modo seguente.

./send –a amqps://username:password@namespace.servicebus.windows.net/queue_name Hello

Per poter ricevere un messaggio dalla stessa queue possiamo utilizzare l’applicazione recv nel modo seguente.

./recv amqps://username:password@namespace.servicebus.windows.net/queue_name

Con un risultato di questo tipo.

Address: amqps://username:password@namespace.servicebus.windows.net/queue_name
Subject: (no subject)
Content: “Hello”

GnatMQ : un broker MQTT per il .Net Framework

Cattura

Con una settimana di ritardo rispetto l’uscita prevista, ho finalmente rilasciato in versione Beta un broker MQTT completamente sviluppato in C# e che può essere eseguito con il .Net Framework ed il .Net Compact Framework 3.9 (su sistemi con Windows Embedded Compact 2013) … il suo nome è GnatMQ !

Al suo interno pulsa il cuore della libreria M2Mqtt con la quale condivide il “core” del protocollo MQTT, per quanto riguarda la parte di connessione al client e la gestione dei messaggi.

Ovviamente, è completamente open source e disponibile su CodePlex ma è attualmente in versione Beta (aspetto numerose segnalazioni da parte vostra !).

Come riportato nella pagina di documentazione supporta le seguenti funzionalità :

  • Tutti i livelli di QoS del protocollo MQTT;
  • Flag Clean Session alla connessione di un client;
  • Flag di Retained Message;
  • Will Message con relativo QoS e topic;
  • Autorizzazione con username e password;
  • Sottoscrizione ai topic con wildcards;
  • Publish e subscribe mediante una “inflight queue”;

Tra le funzionalità non ancora supportate abbiamo :

  • Configurazione del broker da un file di configurazione;
  • Sicurezza basata su SSL/TLS;
  • Configurazione bridge (broker to broker);
  • Salvataggio permanente (es. database) delle sessioni, retained message e will message;

Il mio obiettivo è di supportare lo sviluppo di questo broker così come per la libreria M2Mqtt nella speranza che possa essere utilizzato e migliorato grazie alle vostre segnalazioni !

Per poterne seguire l’evoluzione è possibile utilizzare anche la relativa pagina Facebook ed account Twitter.