Bachelor Informatica

Erlang voor publish subscribesystemen in heterogene sen-sor netwerken

Merwin van Dijk

30 augustus 2016

Supervisor(s): Taco Walstra

Signed:

Informatica—

Universiteit

vanAmst

erdam

Samenvatting

In een heterogeen sensor netwerk worden verschillende soorten sensor apparaten gebruiktdie onderling met elkaar communiceren. Vanwege de beperkte capaciteit van sommige vandeze sensor apparaten kan er voor gekozen worden om gebruik te maken van een gecentra-liseerd publish subscribe systeem. Een belangrijk voordeel van het publish subscribe modelis dat berichten niet naar specifieke ontvangers verstuurd hoeven worden. In deze scriptiewordt een implementatie van de publish subscriber broker in Erlang vergeleken met een im-plementatie in Java. Onder andere is onderzocht wat de gevolgen zijn van het actor modelen het gebruik van lichtgewicht processen voor de Erlang implementatie ten opzichte van eenimplementatie in een imperatieve taal (Java). Voor beide implementaties zijn twee verschil-lende tests gedaan met een groot aantal clienten (tot ca. 10000) en is hierbij de tijdsduurgemeten. Hieruit bleek de performance van de Erlang implementatie beter bij het versturenvan een enkel bericht per client en de performance van de Java implementatie beter bij hetversturen van een groter aantal berichten per client.

Inhoudsopgave

1 Inleiding 51.1 Publish subscribe model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.2 Erlang . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.3 Vraagstelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2 Erlang 82.1 Processen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2 Asynchroon berichten versturen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3 Publish – subscribe protocollen 103.1 Protocol stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.2 Functionaliteit MQTT/MQTT-SN . . . . . . . . . . . . . . . . . . . . . . . . . . 11

4 Publish – subscribe broker 134.1 Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134.2 Uitvoering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

5 Implementatie 155.1 Erlang . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155.2 Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

6 Testopstelling 186.1 Gebruikte systemen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186.2 Test configuratie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

7 Resultaten 207.1 Test 1: 1 publisher 1 subscriber per topic . . . . . . . . . . . . . . . . . . . . . . 207.2 Test 2: 1 publisher 20 subscribers per topic . . . . . . . . . . . . . . . . . . . . . 22

8 Conclusie en vervolgonderzoek 24

A Toelichting op het gebruik Erlang 26A.1 Pattern Matching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

A.1.1 Selective Receive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26A.1.2 Bit Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

A.2 OTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

B Client implementatie 28

4

HOOFDSTUK 1

Inleiding

In dit document wordt de geschiktheid van Erlang voor publish subscribe systemen in hetero-gene sensor netwerken onderzocht. Een heterogeen sensor netwerk is een netwerk van verschil-lende apparaten uitgerust met sensoren. Deze apparaten kunnen verschillen in energie-capaciteit,verwerkings-capaciteit, mobiliteit en kunnen een vaste of draadloze verbinding hebben met hetnetwerk. Zo kan in een heterogeen sensor netwerk informatie verzameld door sensoren doorge-stuurd worden naar apparaten die deze informatie kunnen verwerken.

Het netwerk waar binnen de apparaten gebruikt wordt zal in veel gevallen dynamisch zijn. Ditis onder andere het geval omdat nieuwe apparaten kunnen worden toegevoegd en bestaande ap-paraten stuk kunnen gaan. Ook kan de beweegbaarheid van apparaten er voor zorgen dat dezesoms wel en soms niet onderdeel zijn van het netwerk. Het zou hierbij bijvoorbeeld kunnen gaanom drones die binnen een bepaald gebied rondvliegen en via een draadloze verbinding onderdeelvan een netwerk kunnen worden.

Binnen het heterogene sensor netwerk zal een protocol gebruikt moeten worden voor het ver-sturen en ontvangen van berichten of data tussen de apparaten. In dit protocol kan vastgelegdworden hoe een bericht er uit moet komen te zien en hoe er op een bericht gereageerd moetworden (e.g. ontvangstbevestiging van een ontvangen bericht). Door gebruik van het protocolzal er extra data binnen het heterogene sensor netwerk verstuurd moeten worden. Het is belang-rijk dat de extra data die verstuurd moet worden zo klein mogelijk blijft vanwege de beperkteenergie-capaciteit van sommige apparaten in het netwerk. Om deze reden moet er gebruik ge-maakt worden van een lichtgewicht protocol.

1.1 Publish subscribe model

Voor een heterogeen sensor netwerk is een protocol dat gebaseerd is op het publish - subscribemodel een interessante optie. Bij het publish - subscribe model worden berichten niet naar spe-cifieke ontvangers verstuurd, maar gepubliceerd bij een bepaald topic. Berichten kunnen dangelezen worden door subscribers die aangeven geınteresseerd te zijn in een bepaald topic. Dereden dat een protocol gebaseerd op dit model interessant is voor een heterogeen sensor netwerkis dat apparaten niet hoeven te weten naar welke ontvangers verzamelde data verstuurd moetworden. Als er bijvoorbeeld nieuwe apparaten aan het netwerk toegevoegd moeten worden is diteen voordeel. Bestaande protocols die gebaseerd zijn op het publish subscribe model zijn onderandere AMQP, MQTT, MQTT-SN en CoAP, hier wordt verder op in gegaan in hoofdstuk 3.

5

Het publish subscribe model zorgt er voor dat het nodig is om berichten centraal te verwerken.Het systeem dat gebruikt wordt voor het verwerken van de berichten wordt aangeduid als debroker of meer specifiek de publish subscribe broker. In het figuur hieronder is schematischweergegeven hoe een publisher naar meerdere subscribers een bericht kan sturen via de broker.

Figuur 1.1: De publish subscribe broker stuurt een publish bericht door naar meerdere subscri-bers.

1.2 Erlang

Voor het maken van een publish subscribe broker in een heterogeen sensor netwerk is Erlang eengeschikte taal. Erlang is ontworpen voor het maken van concurrente en fout-tolerante systemendie een hoge up-time vereisen [4]. Voorbeelden van dit soort systemen zijn telefooncentrales,geldautomaten en IM-services (whats-app). De belangrijkste overeenkomst hierbij is dat eengroot aantal clienten gelijktijdig gebruik moet kunnen maken van het systeem. Bij een publishsubscribe broker in een heterogeen sensor netwerk zal dit ook het geval zijn.

In Erlang wordt er gebruik gemaakt van lichtgewicht processen en is het mogelijk om grote aan-tallen processen te gebruiken. Dit maakt dat bij de publish subscribe broker bij een relatief grootaantal clienten nog steeds een proces per client gebruikt kan worden. Daarnaast kunnen pro-cessen geen geheugen delen waardoor de processen geısoleerd van elkaar draaien. Communicatietussen processen is mogelijk door het versturen en ontvangen van berichten waardoor er sprakeis van actor-based concurrency in Erlang.

Een bekend voorbeeld van een publish subscribe broker gemaakt in Erlang is rabbitMQ. Een be-langrijk kenmerk van RabbitMQ is de betrouwbaarheid waarmee berichten verstuurd en verwerktkunnen worden. Zo kan het versturen van een bericht tussen client en server als een transactieworden uitgevoerd en is er ondersteuning voor node failures bij clustering [11]. RabbitMQ isgebasseerd op het AMQP protocol wat een relatief zwaar protocol is vergeleken met het MQTTprotocol [1].

1.3 Vraagstelling

In dit verslag zal een publish subscribe broker gemaakt in Erlang vergeleken worden met eenpublish subscribe broker gemaakt in Java. Hierbij wordt voor de implementatie van de publishsubscribe broker in Java gebruik gemaakt van een threadpool voor de verschillende clienten. Deperformance van de publish subscribe broker gemaakt in Erlang zal vergeleken worden met diein Java voor verschillende vaste groottes van de threadpool. Doordat beide talen verschillendemanieren hebben om met concurrency om te gaan kunnen ook deze met elkaar vergeleken worden.

Voor het onderzoek leidt dit tot de volgende vragen:

• Heeft een publish subscribe broker gemaakt in Erlang een betere performance dan eenpublish subscribe broker gemaakt in Java bij een groot aantal clienten?

• Wat zijn de gevolgen van het actor-model in Erlang versus het shared memory model inJava voor het maken van een publish subscribe broker?

Om deze vragen te beantwoorden zal er in hoofdstuk 2 verder in gegaan worden op de lichtge-wicht processen van Erlang en de mogelijkheid tot asynchroon message passing. In hoofdstuk3 zullen bestaande publish subscribe protocollen besproken worden en wordt beargumenteerdwaarom het MQTT/MQTT-SN protocol het meest geschikt is voor gebruik in een heterogeensensor netwerk. In dit hoofdstuk zal ook de belangrijkste functionaliteit van deze protocollenbesproken worden.

Voor het ondezoek wordt een versimpelde versie van het MQTT/MQTT-SN protocol gebruiktdat besproken zal worden in hoofdstuk 4. In dit hoofdstuk zal ook de uitvoering van de publishsubscribe broker besproken worden. De implementaties van de publish subscribe broker in Erlangen in Java worden besproken in hoofdstuk 5. Daarna volgen de resultaten van de twee publishsubscribe brokers voor twee verschillende tests in hoofdstuk 7. Het artikel eindigt met eenhoofdstuk 8 waarin deze resultaten besproken worden en gekeken wordt naar mogelijk vervolgonderzoek.

HOOFDSTUK 2

Erlang

Erlang is een functionele programmeertaal gericht op het maken van fout-tolerante en concurrentesystemen. Voor de publish subscribe broker zal met name de mogelijkheid tot het aanmakenlichtgewicht processen en het asynchroon versturen van berichten van belang zijn.

2.1 Processen

In Erlang worden lichtgewicht processen aangemaakt binnen een virtuele machine. Het gaathierbij dus om processen binnen de virtuele machine en niet om threads zoals in veel anderetalen (bijvoorbeeld Java, C, C++, ..). De processen die worden aangemaakt door Erlang blijvenwel onderdeel van de Erlang VM en zijn niet waarneembaar als processen binnen het besturings-systeem. De Erlang VM zorgt er voor dat het gaat om lichtgewicht processen die geısoleerd vanelkaar draaien. Zo kunnen processen geen geheugen delen en is het niet mogelijk voor een procesom een ander proces te laten crashen.

Er wordt gesproken over lichtgewicht processen vanwege de korte aanmaaktijd van een proces ende mogelijkheid om grote aantallen processen aan te maken. In [3] worden Erlang processen metthreads in C# of Java vergeleken. De aanmaaktijd blijkt voor Erlang processen op ongeveer 1µsper proces te liggen tot ca. 2500 processen en stijgt naar ca. 3µs per proces bij grotere aantallenprocessen. Voor threads in C# of Java ligt de aanmaaktijd rond de 300µs per thread en blijkthet aanmaken van meer dan 2000 threads niet mogelijk.

2.2 Asynchroon berichten versturen

Het versturen van berichten tussen processen is ingebouwd als onderdeel van de taal in Erlang.Processen hoeven alleen een proces identifier (PID) van het ontvangende proces te hebben omeen bericht te kunnen versturen. Doordat het versturen van berichten tussen processen asyn-chroon gebeurt kan een proces na het verzenden van een bericht direct verder gaan met hetevalueren van de functie. Een verstuurd bericht komt in de mailbox van het ontvangende procesterecht. Elk proces heeft zijn eigen mailbox en kan met behulp van selective receive’s bepalenwelke berichten het wil ontvangen.

Er is geen zekerheid dat een verzonden bericht ook daadwerkelijk bezorgd wordt bij het ontvan-gende proces. Bij het versturen van een bericht wordt ook niet gecontroleerd of het ontvangendeproces daadwerkelijk bestaat. De reden hiervoor is dat het ontvangende proces kan crashen vlaknadat deze controle heeft plaats gevonden. Een controle of een bericht ontvangen is kan daardooralleen door het sturen van een ontvangstbevestiging door het ontvangende proces. Verder kunnenberichten alleen constanten en PID’s bevatten en geen verwijzingen naar data in een proces (ditzou er voor zorgen dat processen niet langer geısoleerd zijn).

8

Het versturen van berichten tussen processen gaat erg snel in Erlang. In [3] wordt de tijd voorhet versturen van een bericht uitgezet tegen het aantal processen/threads in Java en Erlang.Hierbij blijkt het versturen van een bericht in Erlang tot 30000 processen op ongeveer 0, 8µs teliggen. Voor C# is dit zo’n 50µs en bij Java is dit voor 100 threads ook ongeveer 50µs en loopt deverzendtijd op tot zo’n 10ms bij 1000 threads. In [6] worden de resultaten van drie verschillendescenario’s bij een ringbuffer besproken voor Erlang, Scala en Jason. Uit deze resultaten blijktdat Erlang in alle drie de scenario’s een betere performance geeft voor tijd en geheugen.

HOOFDSTUK 3

Publish – subscribe protocollen

Voor het onderzoek zal een protocol gebaseerd op het publish subscribe model gekozen moetenworden. Bij het kiezen van dit protocol moet er rekening mee gehouden moeten worden dat hetprotocol binnen een heterogeen sensor gebruikt zal worden. Het protocol moet onder andererekening houden met de beperkte energie-capaciteit van de sensor apparaten en ook is de ge-bruikte transportlaag van belang. Niet alle apparaten hebben namelijk de mogelijkheid om TCPals transportlaag te gebruiken.

Bekende voorbeelden van protocollen gebaseerd op het publish subscribe model zijn AMQP,CoAP, en MQTT/MQTT-SN. Het AMQP protocol maakt gebruik van TCP als transportlaagen is om die reden niet geschikt voor gebruik in een heterogeen sensor netwerk. Het CoAPprotocol maakt gebruik van UDP als transportlaag en ondersteunt meerdere communicatie mo-dellen waaronder het publish subscribe model [9]. Voor MQTT geldt dat het een OASIS openstandaard is [5].

De MQTT/MQTT-SN protocollen zijn gebaseerd op respectievelijke TCP en UDP als trans-portlaag waarbij MQTT-SN specifiek bedoeld is voor draaloze sensor netwerken. Het MQTT-SNprotocol is ontworpen om zoveel mogelijk te lijken op het MQTT protocol [10]. Dit maakt dathet mogelijk is om apparaten met het MQTT-SN protocol aan te sluiten op een MQTT brokermet behulp van een gateway [7]. De gateway maakt dan een vetaling van MQTT-SN berichtennaar MQTT berichten en omgekeerd.

Het MQTT-SN protocol is aangepast voor draadloze netwerken waar de energie-capaciteit vande apparaten beperkt is. Het MQTT-SN protocol houdt er rekening mee dat apparaten kapotkunnen gaan of weg kunnen vallen. Er is extra functionaliteit ingebouwd om op energie zuinigewijze te controleren of een apparaat nog onderdeel is van het netwerk. Ook kan een sensor appa-raat aangeven wat er moet gebeuren als de verbinding met het netwerk wegvalt. Dit gaat doorhet geven van een last will and testament bericht aan de MQTT broker.

Door de specicieke ondersteuning voor draadloze sensor netwerken bij het MQTT-SN protocol iser voor gekozen het MQTT/MQTT-SN protocol te gebruiken voor dit onderzoek. In combinatiemet een gateway kunnen beide protocols gebruikt worden waardoor clienten een verbindingkunnen leggen met de MQTT broker.

10

3.1 Protocol stack

Het gebruik van MQTT/MQTT-SN leidt tot de volgende protocol stack:

Voor zowel de sensor apparaten als de MQTT-broker / gateway zal bovenstaande protocol stackgebruikt moeten worden. Hierbij maakt de gateway mogelijk dat er twee verschillende trans-portlagen en protocols gebruikt worden.

3.2 Functionaliteit MQTT/MQTT-SN

Veel van de functionaliteit van het MQTT protocol is gebaseerd op de onbetrouwbaarheid bijhet versturen van berichten. Er is geen zekerheid dat een verstuurd bericht ook daadwerkelijk bijde ontvanger zal aankomen. Door het versturen van een ontvangstbevestiging bij het ontvangenvan een bericht kan deze zekerheid wel gegeven worden.

De belangrijkste functionaliteit van het MQTT protocol bestaat uit het publiceren en inschrijvenvoor topics. Voor een client die een publish of subscribe bericht naar de broker verstuurt kanhet van belang zijn om te weten of dit bericht goed is aangekomen. Voor zowel een publish alseen subscribe bericht is het daarom mogelijk een ontvangbevestiging te krijgen. Bij het MQTTprotocol zijn dit berichten van type PUBACK of SUBACK.

Figuur 3.1: Het versturen van publish en subscribe berichten naar de broker met bijbehorendeontvangstberichten.

Bovenstaande methode geeft een client de garantie dat een publish of subscribe bericht goed isaangekomen als er een ontvangstbevestiging is aangekomen. Als de klant geen ontvangstbeves-tiging krijgt kan deze het bericht herhaaldelijk versturen totdat er wel een ontvangstbevestigingkomt of uiteindelijk opgeven.

Door het herhaaldelijk versturen van dezelfde publish berichten kan het zijn dat de broker dezeook meerdere malen ontvangt. Dit gebeurt wanneer er iets mis gaat bij het versturen van deontvangstbevestiging (zowel het originele bericht als de ontvangstbevestiging worden over eenonbetrouwbare verbinding verstuurd). Voor de broker is het echter niet mogelijk om onderscheidte maken tussen de ontvangen publish berichten. Een zelfde publish bericht wat meerdere malenontvangen wordt zal daarom ook meerdere malen doorgestuurd worden naar subscribers van hettopic. Om dit te voorkomen heeft het MQTT protocol een service met gegarandeerde bezorgingzonder duplicaten (zie figuur 3.2).

Figuur 3.2: Het versturen van een publish bericht met gegarandeerde eenmalige bezorging.

Voor dat een client berichten kan versturen moet er eerst een verbinding met de publish sub-scribe broker gelegd worden door middel van een CONNECT bericht. De publish subscribebroker beantwoordt dit bericht met een CONNACK bericht om aan te geven dat de verbindinggeaccepteerd is (een verbinding met een client kan ook geweigerd worden als er teveel clientenzijn). In het connect bericht zijn verschillende flags die gebruikt kunnen worden om aan te gevenom wat voor type verbinding het gaat en van welke service gebruik wordt gemaakt.

HOOFDSTUK 4

Publish – subscribe broker

In deze sectie wordt de publish subscribe broker besproken die voor dit onderzoek zowel in Erlangals in Java geımplementeerd is. Beide implementaties maken gebruik van een versimpelde versievan het MQTT protocol wat hieronder is vastgelegd. In deze sectie wordt ook besproken hoe depublish subscribe broker berichten moet verwerken. Het gaat hierbij om het soort gedrag dateen client mag verwachten na het versturen van subscribe/publish bericht of het krijgen van eenontvangstbevestiging.

4.1 Protocol

Het protocol dat de publish subscribe broker gebruikt biedt de volgende functionaliteit:

• Clienten kunnen een verbinding maken met de publish subscribe broker door het versturenvan een connect bericht en te wachten op een connack bericht.

• Clienten kunnen een subscribe/unsubscribe bericht versturen voor een topic met een be-paald topic id en ontvangen een suback/unsuback als deze is verwerkt.

• Clienten kunnen een publish bericht versturen voor een topic met een bepaald topic id enontvangen een puback als deze is verwerkt.

De versimpelde versie van het MQTT protocol heeft dus een service level voor het versturenvan berichten; versturen van een publish bericht met gegarandeerde eenmalige bezorging is nietmogelijk.

Hieronder is het formaat weergegeven waarmee de berichten verstuurd moet worden waarbijeen vaste header van 8 bytes wordt gebruikt. Alleen een publish bericht kan data meezendenwaardoor alle andere berichten een grootte van 8 bytes hebben.

Figuur 4.1: Het bericht formaat met het aantal bits aangegeven per veld (totaal 64 bits/8 bytes).

13

4.2 Uitvoering

De publish subscribe broker verwerkt de ontvangen berichten als volgt:

• Een connect bericht wordt altijd met een connack bericht beantwoord (er is geen maximumaantal clienten).

• Een subscribe bericht wordt beantwoordt met een suback bericht als het subscribe berichtintern verwerkt is. Dit houdt in dat een suback bericht pas verstuurd kan worden als desubscriber is toegevoegd aan de lijst van subscribers bij een bepaald topic.

• Een publish bericht wordt direct beantwoordt met een puback bericht. De publish subscribebroker heeft na het onvangen van een publish bericht de verantwoordelijkheid voor eencorrecte afhandeling en onderneemt de volgende acties:

– Het publish bericht wordt doorgestuurd naar alle subscribers van het topic.

– De publish subscribe broker wacht voor elke subscriber op een puback bericht. Rea-geert een subscriber niet tijdig met een puback bericht dan wordt het publish berichtopnieuw verzonden.

– Als een topic geen subscribers heeft wordt het gepubliceerde bericht bewaard en door-gestuurd naar de eerstvolgende subscriber van dit topic.

Voor zowel de Erlang als de Java implementatie van de publish subscribe broker geldt dat be-richten op bovenstaande wijze verwerkt worden.

HOOFDSTUK 5

Implementatie

In deze sectie worden de implementaties van de publish subscribe broker in Erlang en Java be-sproken. Het belangrijkste verschil tussen de twee implementaties is het aantal processen/threadsdat gebruikt wordt. Voor het verwerken van inkomende berichten van de clienten wordt bij deErlang implementatie een proces per client gebruikt en bij de Java implementatie een threadpoolvan vaste grootte. Ook het aantal threads/processen dat gebruikt wordt voor het beheer vantopics en subscribers verschilt. Bij de Erlang implementatie wordt voor elk topic en elke subscri-ber een appart proces aangemaakt terwijl er bij de Java implementatie gebruikt wordt gemaaktvan een vast aantal threads.

5.1 Erlang

Voor het maken van de publish subscribe broker in Erlang is gebruik gemaakt van het beschrevenontwerp van de MQTT broker bij [2] slides 54/55. Het uiteindelijke ontwerp is schematischweergegeven in figuur 5.1 en heeft de volgende eigenschappen:

• Er wordt per TCP verbinding een proces aangemaakt.

• Er wordt per topic een proces aangemaakt.

• Er wordt bij alle topics een proces per ingeschreven client aangemaakt.

• Er is een proces voor het beheer van alle inschrijvingen.

• Er is een proces voor het beheer van alle topics.

Bij dit ontwerp is de topic manager verantwoordelijk voor het beheer van de topic processen dieelk een lijst van subscribers bijhouden. Een binnenkomend publish bericht wordt doorgestuurdnaar een topic proces dat het publish bericht doorstuurt naar een of meerdere subscriber proces-sen of wacht totdat er een subscriber voor dit topic is.

De subscriber manager is verantwoordelijk voor het beheer van alle subscriber processen. Desubscriber manager zorgt voor het toevoegen van subscribers aan topics en maakt het mogelijkom een subscriber proces op te zoeken. De subscriber processen zorgen voor het doorsturen vaneen publish bericht naar de client en wachten op een ontvangstbevestiging (puback bericht). Hetsubscriber proces start ook een timer na het versturen van een publish bericht en verzend hetpublish bericht opnieuw als de ontvangstbevestiging van het publish bericht niet tijdig komt.

Bij het maken van een verbinding met de broker wordt door de connection listener een procesaangemaakt voor de client dat verantwoordelijk is voor alle binnenkomende berichten van declient. Inkomende berichten worden direct beantwoord of doorgestuurd naar de topic managerof subscriber manager.

15

Figuur 5.1: Het ontwerp van de publish subscribe broker met een proces per verbinding, topicen inschrijving van een topic. De rode pijlen geven de flow van een publish bericht aan.

5.2 Java

Bij de Java implementatie is het niet mogelijk om een thread per TCP verbinding te gebruikenals het aantal clienten groot is. Het is daarom nodig om gebruik te maken van een threadpoolmet een vast aantal threads. Het gebruik van de threadpool mag er niet toe te leiden dat hetaantal verbindingen dat gelijktijdig gebruikt kan worden ook vast komt te liggen. Door gebruikte maken van Java NIO (Non-blocking Input Output) is het mogelijk om met een vast aantalthreads een relatief groot aantal verbindingen te hebben (gelijk aan het aantal mogelijke TCPverbindingen).

In Java kunnen objecten tussen threads gedeeld worden waardoor er geheugen tussen de threadsgedeeld wordt. Het delen van geheugen tussen threads kan leiden tot race conditions als meer-dere threads bij hetzelfde geheugen willen lezen of schrijven. Er wordt daarom gebruik gemaaktvan de concurrente data-structuren uit de java.util.concurrent library. Deze library maakt hetmogelijk om data-structuren tussen threads te delen op een manier die thread-safe is.

Voor de Java implementatie is het nodig dat er threads berichten naar elkaar kunnen versturen.Er is in Java geen ingebouwde mogelijkheid voor het versturen van berichten tussen threads.Een thread moet daarom gebruik maken van een FIFO queue die het met andere threads deelt.Threads die een bericht willen versturen kunnen een bericht toevoegen aan deze queue. De ont-vangende thread heeft de mogelijkheid te controleren of er berichten zijn en het eerste ontvangenbericht binnen te halen.

Voor het beheer van alle queue’s die als mailbox dienen wordt de queue manager gebruikt. Dequeue manager beheert de queue’s door het bijhouden van een map met als sleutel een client iden een referentie naar de queue als waarde. Andere threads zoals de topic manager kunnengebruik maken van deze (concurrente) map bij het doorsturen van berichten.

Voor het bijhouden van timeouts na het versturen van een publish bericht wordt de timeoutmanager gebruikt. Het uiteindelijk ontwerp van de Java implementatie ziet er als volgt uit:

• Er is een threadpool voor het verwerken van de binnenkomende berichten van clienten.

• Er wordt gebruik gemaakt van een queue manager voor het beheer van queue’s die gebruiktworden als mailbox voor een thread.

• Er wordt gebruik gemaakt een topic manager voor het beheer van alle topics

• Er wordt gebruik gemaakt van een timeout manager voor alle threads die wachten op eenontvangstbevestiging van een client.

Figuur 5.2: Het ontwerp van de publish subscribe broker in Java: de rode pijlen geven de flowvan een publish bericht aan.

HOOFDSTUK 6

Testopstelling

Voor het testen van de publish subscribe broker zijn er clienten nodig die de publish subscribebroker belasten. Voor dit onderzoek is daarom een client applicatie voor de publish subscribebroker geımplementeerd (zie appendix B). Voor de test krijgen clienten de opdracht om eenverbinding te maken met de publish subscribe broker, een inschrijving te doen voor een topicof berichten bij een topic te publiceren. Het aanmaken van de clienten en het geven van deopdrachten gebeurt door middel van een script (Erlang escript).

Het is mogelijk om bij een client in te stellen hoeveel berichten er per topic verstuurd en ont-vangen moet worden. De client geeft dan een finish signaal af op het moment dat het gewensteaantal berichten per topic is ontvangen en er voor alle verzonden berichten ontvangstbevestigin-gen zijn gekregen. Het script kan zo bijhouden welke clienten klaar zijn met de test en bepalenwanneer de test is afgelopen.

De clienten beginnen in de tests met het versturen van een connect bericht naar de publishsubscribe broker en wachten daarna op een connack bericht. Hierna versturen de clienten eensubscribe bericht voor een topic (dit topic is van te voren bepaald) en wachten de clienten opeen suback bericht. De test start na het versturen van de subscribe berichten een synchronisatiefase waarbij gewacht wordt totdat alle clienten ingeschreven zijn. Als alle clienten ingeschrevenzijn wordt een timer gestart en beginnen de clienten met het publiceren en ontvangen van deberichten. Als alle clienten een finish signaal hebben afgegeven wordt de timer gestopt en wordtde test beeindigd.

6.1 Gebruikte systemen

Voor de test is gebruikt gemaakt van een laptop en een desktop systeem:

ASUS R510C LaptopOS: Linux Mint 17.3Hardware: Intel Core i7-3557U ∼2.0 Ghz Dual-Core 4 MB Cache, 4 GB werkgeheugenSoftware: Erlang/OTP 18, Java Oracle 1.8.0 91

Desktop systeemOS: Linux Mint 17.3Hardware: Intel Core i5-2400 ∼3.1 Ghz Quad-Core 6 MB Cache, 4 GB werkgeheugenSoftware: Erlang/OTP 18

Hierbij is de laptop voor de publish subscribe broker gebruikt (Java en Erlang) en is het desktopsysteem gebruikt voor de client applicatie in combinatie met Erlang escript.

18

6.2 Test configuratie

De volgende keuzes zijn gemaakt voor het doen van de tests:

Publish berichten van 1 KBEr is gekozen voor vaste grootte voor de publish berichten van 1024 bytes. Voor dezegrootte is gekozen omdat er relatief veel kleine berichten binnen een heterogeen sensornetwerk verstuurd zullen worden. Daarnaast zal bij deze grootte het versturen van dataniet snel de bottleneck zijn binnen de testopstelling.

Asynschroon verzenden van publish berichtenBij de tests verzenden de clienten asynchroon publish berichten naar de broker. Dit houdtin dat de clienten niet wachten op een puback bericht, maar direct verder gaan met hetverzenden van het volgende publish bericht.

Nagle’s algoritme wordt niet gebruiktDoordat de clienten veel kleine berichten verzenden en ontvangen is er voor gekozen om bijzowel de clienten als de broker Nagle’s algoritme [8] niet te gebruiken. Bij Nagle’s algoritmewordt gewacht met het versturen van een pakket over het netwerk totdat meerdere kleineberichten een pakket gevuld hebben. De standaard configuratie bij een TCP verbinding isom Nagle’s algoritme wel te gebruiken

Het asynchroon versturen van berichten leidt er toe dat er geen vaste tijd gekozen kan wordenvoor het doen van de test. Doordat een client niet wacht na het versturen van een publishbericht zijn er tijdens de test meerdere publish berichten onderweg; voor deze publish berichtenmoet dan nog een puback bericht ontvangen worden. Dit maakt dat het niet mogelijk is om detest te laten draaien voor een vooraf gegeven tijdsduur. Wel is het mogelijk om aan te gevenhoeveel berichten er verzonden moet worden. Door deze manier van testen wordt de tijdsduureen functie van het aantal publish berichten (of het aantal clienten/topics dat bepaald hoeveelpublish berichten er verstuurd moeten worden).

HOOFDSTUK 7

Resultaten

De performance van de Erlang en Java implementaties worden hieronder bij twee verschillendetests met elkaar vergeleken.

7.1 Test 1: 1 publisher 1 subscriber per topic

Bij deze test schrijft elke client zich in voor een topic en publiceert het bij een topic berichten.De test wordt zo ingesteld dat elk topic een subscriber en een publisher heeft en dat de subscri-ber en publisher bij een topic twee verschillende clienten zijn. Bij de test wordt de tijd gemetendie nodig is voor het verzenden en ontvangen van de berichten voor verschillende aantallen topics.

De test hieronder is uitgevoerd met een gepubliceerd bericht per topic voor zowel de Erlang alsde Java implementatie met verschillende aantallen threads.

0.2 0.4 0.6 0.8 1

·104

0

0.2

0.4

0.6

Aantal topics

Tij

dsd

uu

r(s

)

ErlangJava 1Java 5

Java 20

Figuur 7.1: Tijdsduur voor het verzenden en ontvangen van een publish bericht per topic voorErlang en Java implementatie met verschillende aantal threads.

De resultaten van de Erlang implementatie zijn bij deze test beter dan de resultaten van de Javaimplementatie met verschillend aantal threads. De resultaten van de Java implementatie zijnvoor 5 en 20 threads redelijk vergelijkbaar en wat trager bij 1 thread.

20

De test kan ook worden uitgevoerd met een groter aantal gepubliceerde berichten per topic. Infiguur 7.2 is de test uitgevoerd met 2, 5, 10 en 20 gepubliceerde berichten per topic. Bij dezetest is bij de Java implementatie twintig threads gebruikt.

0.2 0.4 0.6 0.8 1

·104

0

0.2

0.4

0.6

0.8

Aantal topics

Tij

dsd

uu

r(s

)

2 berichten

ErlangJava

0.2 0.4 0.6 0.8 1

·104

0

0.5

1

1.5

2

Aantal topics

Tij

dsd

uu

r(s

)

5 berichten

ErlangJava

0.2 0.4 0.6 0.8 1

·104

0

1

2

3

4

Aantal topics

Tij

dsd

uu

r(s

)

10 berichten

ErlangJava

0.2 0.4 0.6 0.8 1

·104

0

2

4

6

8

Aantal topics

Tij

dsd

uu

r(s

)

20 berichten

ErlangJava

Figuur 7.2: Tijdsduur voor het verzenden en ontvangen van verschillende aantallen publishberichten per topic voor Erlang en Java (20 threads) implementatie.

Uit bovenstaande grafieken blijkt dat bij het verhogen van het aantal berichten per topic deJava implementatie geleidelijk aan betere resultaten heeft dan de Erlang implementatie. Bij hetversturen van twintig berichten per topic heeft de Java implementatie zo’n 10% a 20% minder tijdnodig. Een mogelijke verklaring hiervoor is dat bij de Java implementatie een thread meerdereberichten in een keer kan verwerken. De tijd die nodig is voor het uitvoeren van een contextswitch wordt hierdoor relatief klein.

7.2 Test 2: 1 publisher 20 subscribers per topic

Bij deze test schrijven twintig clienten zich in voor een topic en publiceert een client berichtenbij dit topic. De test wordt zo ingesteld dat een client zich inschrijft bij een topic of publiceertbij een topic. Voor elk topic zijn er daarom twintig unieke subscribers en een unieke publisher.Bij de test wordt de tijd gemeten die nodig is voor het versturen en ontvangen van de berichtenvoor verschillende aantallen topics.

Opnieuw is de test uitgevoerd met een gepubliceerd bericht per topic voor zowel de Erlang alsde Java implementaties. Het aantal topics dat gebruikt is bij deze test is verlaagd met een factortwintig zodat het totaal aantal subscribers gelijk is gebleven.

100 200 300 400 5000

0.1

0.2

0.3

0.4

Aantal topics

Tij

dsd

uu

r(s

)

ErlangJava 1Java 5

Java 20

Figuur 7.3: Tijdsduur voor het verzenden en ontvangen van een publish bericht naar een topicmet 20 subscribers voor Erlang en Java implementatie met verschillend aantal threads.

De resultaten van de Erlang implementatie zijn bij deze test opnieuw beter dan de resultatenvan de Java implementatie met verschillend aantal threads. De tijdsduur van de Erlang imple-mentatie lijkt ongeveer lineair met het aantal topics, bij de Java implementatie met verschillendaantal threads is dit wisselvalliger.

Ook test 2 wordt uitgevoerd met een groter aantal gepubliceerde berichten per topic. In figuur7.4 is de test uitgevoerd met 2, 5, 10 en 20 gepubliceerde berichten per topic. Bij deze test is bijde Java implementatie twintig threads gebruikt.

100 200 300 400 500

0.1

0.2

0.3

0.4

0.5

Aantal topics

Tij

dsd

uu

r(s

)

2 berichten

ErlangJava

100 200 300 400 5000

0.2

0.4

0.6

0.8

1

1.2

Aantal topics

Tij

dsd

uu

r(s

)

5 berichten

ErlangJava

100 200 300 400 5000

0.5

1

1.5

2

2.5

Aantal topics

Tij

dsd

uu

r(s

)

10 berichten

ErlangJava

100 200 300 400 5000

1

2

3

4

5

Aantal topics

Tij

dsd

uu

r(s

)

20 berichten

ErlangJava

Figuur 7.4: Tijdsduur voor het verzenden en ontvangen van verschillende aantallen publishberichten naar een topic met 20 subscribers voor Erlang en Java (20 threads) implementatie.

Uit bovenstaande grafieken blijkt opnieuw dat bij het verhogen van het aantal berichten per topicde Java implementatie geleidelijk aan betere resultaten heeft dan de Erlang implementatie. Bijhet versturen van 20 berichten per topic heeft de Java implementatie bij grotere aantallen topicstot ∼ 40% minder tijd nodig (bij test 1 was dit 10% a 20%).

Het relatieve verschil tussen de Java en de Erlang implementatie blijkt bij test 2 dus groter danbij test 1. Een factor die bij test 2 belangrijker is dan bij test 1 is de tijd die nodig is voorserialisatie van de berichten die verzonden moeten worden. Een mogelijke verklaring zou daaromkunnen zijn dat de Java implementatie minder tijd nodig heeft voor serialisatie van de berichtendie verstuurd moeten worden.

HOOFDSTUK 8

Conclusie en vervolgonderzoek

In deze scriptie is onderzocht hoe Java en Erlang gebruikt kunnen worden voor het maken vaneen publish subscribe broker in een heterogeen sensor netwerk. Beide talen zijn gebruikt voorhet maken van een publish subscribe broker die gebruik maakt van een aangepast versie van hetMQTT protocol. Hierbij zijn voor de Java en Erlang implementatie twee verschillende ontwer-pen gebruikt. De belangrijkste reden hiervoor is dat het in Erlang mogelijk is een groot aantalprocessen te gebruiken.

Het ontwerp van de Erlang implementatie maakt voor elk topic en elke subscriber een apartproces aan. Doordat processen geısoleerd van elkaar draaien in Erlang heeft een fout in een sub-scriber of topic proces geen invloed op andere processen. Dit maakt dat het in Erlang mogelijkis om berichten van clienten te verwerken op een manier die fout-tolerant is.

Bij de Java implementatie wordt er gebruik gemaakt van een threadpool voor de clienten en ma-ken threads gebruik van concurrent datastructuren. Er is naar gestreefd zo min mogelijk gedeeldgeheugen te hebben tussen threads en er is daarom gekozen voor een ontwerp waarbij berichtenverzonden worden tussen de threads (gebruikmakend van concurrent queue’s). Bij dit ontwerpwordt er gebruik gemaakt van een thread die verantwoordelijk is voor het beheer van alle topicsen subscribers zodat het niet nodig is om een gedeelde datastructuur voor topics en subscriberste gebruiken.

Voor het onderzoek zijn twee verschillende tests gedaan voor beide implementaties van de publishsubscribe broker. Bij de eerste test was er voor elk topic een publisher en een subscriber. Bijde tweede test was er bij elk topic een publisher en twintig subscribers. Bij beide testen bleekde Erlang implementatie het snelst als er 1 bericht per topic verstuurd werd, maar trager alser meerdere berichten per topic verstuurd werden. Een mogelijk verklaring hiervoor kan zijndat een thread bij de java implementatie meerdere berichten van/naar een client kan verwerken.Hierdoor kost het switchen tussen threads relatief minder tijd en daalt de gemiddelde tijd voorhet versturen van een bericht.

Bij dit onderzoek is Erlang gebruikt voor het maken van de publish subscribe broker, het makenvan een client implementatie en voor het doen van de tests. Erlang is hierbij een geschikte taalgebleken voor het maken van de client applicatie (zie appendix B) en het doen van de tests. Zois het bij de tests mogelijk om voor grote aantallen clienten een proces per client te gebruiken enkunnen processen worden aangemaakt die als taak hebben de client aan te sturen. Dit zorgt ervoor dat clienten parallel kunnen worden aangestuurd en daardoor gelijktijdig berichten kunnenversturen.

24

Beide tests zijn gedaan nadat clienten een verbinding hebben gemaakt met de publish subscribebroker en inschrijvingen voor topics zijn verwerkt. Een realistischer test zou kunnen zijn dat depublish subscribe broker gelijktijdig connect, subscribe/unsubscribe en publish berichten moetverwerken. Bij de Java implementatie zou dit er voor zorgen dat er schrijf operaties plaats vin-den bij gedeelde datastructuren. Door het gebruik van concurrent datastructuren bij de Javaimplementatie kan dit niet tot race conditions leiden. Wel zouden de extra schrijf operatiesbij concurrent datastructuren er voor kunnen zorgen dat er meer tijd nodig is om de opera-ties op deze datastructuren uit te voeren. Voor de Erlang implementatie is er geen reden omaan te nemen dat dit tot vertraging zal leiden omdat er geen gedeeld geheugen bij de processen is.

Voor het doen van vervolgonderzoek zouden testen ontwikkeld kunnen worden waarbij clientengelijktijdig connect, subscribe/unsubscribe en publish berichten versturen naar de publish sub-scribe broker. Het uitvoeren van deze tests leidt wel tot extra complicaties ten opzichte van detests die uitgevoerd zijn bij dit onderzoek. Voor een client is het namelijk nodig om te controlerenof het vooraf ingestelde aantal verzonden en ontvangen berichten is bereikt zodat bepaald kanworden wanneer de test is afgelopen. Wanneer connect, subscribe en publish berichten echtergelijktijdig verstuurd worden is het niet mogelijk om te bepalen in welke volgorde de publishsubscribe broker de berichten zal verwerken. Hierdoor is het niet mogelijk om te bepalen hoeveelberichten een client moet ontvangen.

Er zou ook gekeken kunnen worden naar tests waarbij het totaal aantal verzonden en ontvangenberichten over een bepaalde tijdsduur gemeten wordt (en deze van te voren dus niet vastliggen).Hierbij is het de vraag of bij deze tests het asynchroon versturen van berichten door clientenrepresentatieve resultaten geeft (er kunnen berichten verwerkt zijn door de publish subscribebroker maar niet ontvangen zijn bij de client). Het doen van tests waarbij synchroon berichtenverstuurd worden zou om die reden ook interessant kunnen zijn.

BIJLAGE A

Toelichting op het gebruik Erlang

Deze sectie bevat een toelichting op het programmeren in Erlang. In het eerste deel wordteen deel van de ingebouwde functionaliteit van Erlang besproken die gebasseerd is op patternmatching. Het tweede deel gaat over het gebruik van de standaard bibliotheek OTP.

A.1 Pattern Matching

In Erlang kan een waarde worden toegekend aan een variabele met behulp van pattern matching.Dit houdt in dat variabelen een waarde krijgen die wordt afgeleid uit een gegeven expressie. Opdeze manier kunnen tuples en lijsten ontleed worden in een regel. Een voorbeeld:

[{A, B}, {C, D, E}] = X

Als X nu bijvoorbeeld [{1, 2}, {7, 8, 9}] dan geldt A = 1, B = 2, C = 7, D = 8, E = 9. Patternmatching kan gebruikt worden voor het definieren van functie clausules. Zo kan bijvoorbeeld defunctie length voor het bepalen van de lengte van een lijst als volgt gedefinieerd worden:

length([H|Tail]) = 1 + length(Tail);

length([]) = 0.

Hierbij wordt pattern matching gebruikt om te bepalen welke functie clausule moet worden aan-geroepen.

Er zijn meer manieren waarop pattern matching gebruikt wordt in Erlang waaronder selectivereceive en bij gebruik van bit syntax.

A.1.1 Selective Receive

Een belangrijke functionaliteit van Erlang is het versturen van berichten tussen processen. Dezeberichten kunnen met de syntax Pid ! Variable verstuurd worden. Het ontvangen van een berichtgebeurt met het receive keyword gevolgd door een of meerdere expressie(s):

receive

{subscribe, Msg_Id, Topic_Id} ->

subscribe(Msg_Id, Topic_Id, );

{publish, Msg_Id, Topic_Id, Data} ->

topic_manager:publish(Msg_Id, Topic_Id, Data);

end

Met het gebruik van het receive keyword kan bepaald worden welke berichten uit de mailboxgehaald moeten worden. Ook kan bepaald worden in welke volgorde de berichten uit de mailboxgehaald moeten worden waardoor deze niet langer het gedrag heeft van een FIFO queue.

26

A.1.2 Bit Syntax

In Erlang is er ingebouwde ondersteuning voor het ontleden van binary variabelen. Onderstaandevoorbeeld laat zien hoe een header van 48 bits (6 bytes) ontleed kan worden:

<< Length:8, Type:4, Client_Id:14, Topic_Id:6, Msg_Id:16 >> = Header

De << en >> geven hierbij het begin en eind van de binary aan. Het getal achter de : het aantalbits wat een variabele gebruikt. Met behulp van pattern matching kan zo in een regel een binaryvariable ontleed worden.

A.2 OTP

Concurrente programma’s maken vaak gebruik van vaste patronen voor het aanmaken van pro-cessen of het verzenden en ontvangen van berichten. Zo wordt er bij het aanmaken van eenproces vaak eerst een initialisatie functie aangeroepen waarna er een loop functie volgt. Doordeze vaste partronen is er een gemeenschappelijk deel aan code wat door veel concurrente pro-gramma’s wordt gebruikt. Het OTP framework heeft als doel het gemeenschappelijke deel vandeze concurrente programma’s weg te abstraheren.

Met behulp van behaviours kan aangegeven worden van welk gemeenschappelijk deel gebruiktwordt gemaakt. De volgende behaviours zijn onderdeel van het OTP framework:

gen serverAbstractie voor processen die als server gebruikt worden binnen het programma. Hierbijis een server een proces dat een bepaalde functionaliteit levert aan andere processen.

gen fsmAbstractie voor processen die zich in een eindig aantal staten kunnen begeven (finite statemachine).

gen eventAbstractie voor processen die events moeten verwerken.

supervisorAbstractie voor processen die supervisie hebben over andere processen.

Bij het gebruik van een behaviour staat van te voren vast welke functies geımplementeerd moetenworden (zogenaamde callback functies). De progammeur hoeft zelf geen algemene code meer teschrijven en kan zich richten op de specifieke code van de implementatie. Het gebruik van hetOTP framework zorgt voor een aantal voordelen, waaronder debug informatie die automatischwordt toegevoegd en de manier waarop er een proces omgaat met ontvangen berichten die nietverwerkt kunnen worden.

BIJLAGE B

Client implementatie

Het client programma dat gebruikt wordt voor het testen van de publish subscribe broker isgebaseerd op de gen fsm behaviour (zie A.2). Het programma kan zich in de volgende statenbevinden:

connectingHet programma is bezig met het versturen van een connect bericht. Is het hiermee klaardan verandert de staat naar waiting for connack.

waiting for connackHet programma wacht op een connack bericht van de publish subscribe broker.

connectedHet programma heeft een verbinding met de publish subscribe broker en kan subscribe/publishberichten versturen.

Afhankelijk van de staat van het client-programma wordt bepaald hoe er met inkomende berich-ten of events moet worden omgegaan. Bijvoorbeeld bij het versturen van een publish bericht zalin de ‘verbonden’-staat het bericht voorzien worden van een bericht id en doorgestuurd wordennaar de publish subscribe broker. In een ‘niet verbonden’-staat zal het bericht worden toege-voegd aan lijst van wachtende berichten.

Net als bij de publish subscribe broker wordt voor verstuurde berichten bijgehouden of er eenbijbehorende ontvangstbevestiging ontvangen is. Als dit niet binnen een bepaalde tijd gebeurtwordt het bericht opnieuw verzonden. Dit betekent dat er een administratie bijgehouden moetworden van verstuurde berichten en gecontroleerd moet worden of de maximale tijd voor hetkrijgen van een ontvangstbevestiging bereikt is.

Voor het doen van de testen is het nodig dat de client een specifiek aantal berichten kan verzendenen ontvangen (hierbij moet een ontvangstbevestiging gekregen zijn van de verzonden berichten).Het is daarom mogelijk om bij het aanmaken van een client een PID (process identifier) mee tegeven. Dit process ontvangt een bericht van de client als voor alle topics het gewenste aantallenberichten verstuurd en ontvangen is.

28

Bibliografie

[1] A Comparison of AMQP and MQTT, White Paper. https://lists.oasis-open.org/

archives/amqp/201202/msg00086/StormMQ_WhitePaper_-_A_Comparison_of_AMQP_

and_MQTT.pdf.

[2] Building Wireless Sensor Networks with MQTT-SN, RaspberryPi and Erlang. http://www.slideshare.net/nivertech/zvi-mqtts-foreuc2013. Accessed: 2016-07-16.

[3] Joe Armstrong. Concurrency oriented programming in erlang. Invited talk, FFG, 2003.

[4] Joe Armstrong, Robert Virding, Claes Wikstrom, and Mike Williams. Concurrent program-ming in erlang. 1993.

[5] Andrew Banks and Rahul Gupta. Mqtt version 3.1. 1. OASIS standard, 2014.

[6] Rafael C Cardoso, Jomi F Hubner, and Rafael H Bordini. Benchmarking communication inactor-and agent-based languages. In Engineering multi-agent systems, pages 58–77. Springer,2013.

[7] Urs Hunkeler, Hong Linh Truong, and Andy Stanford-Clark. Mqtt-s—a publish/subscribeprotocol for wireless sensor networks. In Communication systems software and middlewareand workshops, 2008. comsware 2008. 3rd international conference on, pages 791–798. IEEE,2008.

[8] John Nagle. Congestion control in ip/tcp internetworks. 1984.

[9] Zach Shelby, Klaus Hartke, and Carsten Bormann. The constrained application protocol(coap). 2014.

[10] Andy Stanford-Clark and Hong Linh Truong. Mqtt for sensor networks (mqtt-s) protocolspecification. International Business Machines Corporation version, 1, 2008.

[11] Alvaro Videla and Jason JW Williams. RabbitMQ in action. Manning, 2012.

29