...
Het bedrijf Regterschot Racing wil een website applicatie hebben, waarop de data van de sensoren in de auto, te zien is. Regterschot Racing verwacht in ieder geval van één sensor, de GPS, twintig keer per seconde data te krijgen. Het is voor Regterschot Racing belangrijk dat deze data goed overkomt vanaf de auto naar de website applicatie en dat dit zo snel mogelijk, het liefst in real-time, overkomt. Het is voor ons van belang om dit onderzoek uit te voeren, om zo te weten te komen welke techniek het beste aansluit bij de wensen van Regterschot Racing. Iets waar we ook rekening mee moeten houden is dat de Raspberry Pi de data in ieder geval op slaat in een MySQL database. Dit proces loopt via een message broker. Een message broker is een soort van tussenpersoon bij twee of meer applicaties. Het is mogelijk of van applicatie A een bericht te sturen naar applicatie B. Ook kunnen applicatie A en C berichten sturen naar alleen applicatie B, of juist alleen applicatie A naar B en D. Eén van de voordelen die een message broker heeft is dat berichten altijd aankomen. Een bericht wordt verstuurd en pas als er een response komt wordt het bericht uit de queue (wachtrij) van de broker verwijderd. Als de broker geen response krijgt wordt het bericht nogmaals verstuurd totdat dit succesvol is. Het hebben van een queue is handig voor het hebben van een first in first out ordering, maar ook het bewaren van berichten voor als een server niet bereikbaar is.
Hoofd- en deelvragen
Onze hoofdvraag is: 'Welke techniek kunnen wij gebruiken om real-time data weer te geven op een website?' Om deze vraag te kunnen beantwoorden, hebben we ook een aantal deelvragen opgezet. Onze eerste twee deelvragen gaan over de technieken die bekend zijn, of veel gebruikt worden, voor het weergeven van data in real-time op een website. Deze deelvraag is opgesplitst in welke technieken er zijn die gebruik maken van een MySQL database en technieken die geen gebruik maken van deze database. Bij de tweede deelvraag zal er gekeken worden naar technieken die geen gebruik maken van een database. Bij deelvraag 3 zal er gekeken worden naar welke technieken voor het streamen van data naar de pit er in autoraces worden toegepast. Een voorbeeld hiervan kan zijn: 'Welke techniek wordt er gebruikt bij F1 races om de data van de baan naar de pit te sturen?' In de vierde deelvraag zullen we ingaan op de voor- en nadelen van de bovengenoemde technieken. In het kort hebben we de volgende deelvragen:
...
Herrera kiest hier voor de derde optie, omdat hij vindt dat deze het meest robuust is. Ook benoemd hij dat deze techniek geen middelen verspilt door bijvoorbeeld polling of het proces vertraagd door het gebruik van triggers. Een trigger is een stuk code dat in de database luistert naar een insert, update of delete. Vaak wordt dit gebruikt om in de database een aanpassing te doen of om een stukje van de code te valideren. Een trigger kan echter ook gebruikt worden om een stukje code uit te voeren, al is dit zoals Herrera zegt proccess vertragend.
Herrera geeft de volgende afbeelding met hoe het systeem uiteindelijk zal werken.
Figuur 1 (Herrera, 2018)
Als er een insert, update of delete op de MySQL database wordt uitgevoerd, wordt dit in een binary log gezet. De Java applicatie luistert naar deze binary log met gebruik van de mysql-binlog-connector-java. Nadat de Java applicatie deze data heeft ontvangen, wordt deze omgezet zodat alleen de relevante data door wordt gestuurd naar de "Pusher Channel". Vervolgens gebruikt Herrera een React app die verbonden is aan de pusher. De pusher zit als een soort API tussen de React app en de Java backend.
...
Regterschot Racing gebruikt een API om de data van de Raspberry Pi in de database te zetten. De client, in dit geval onze Java web applicatie, kan een request sturen naar deze API. Als de API nieuwe data heeft, dan zal hij deze teruggeven aan de applicatie. Als deze geen nieuwe data heeft, dan krijgt de applicatie een bericht terug dat er geen nieuwe data is. Het is vergelijkbaar met het verversen van je email om te kijken of er nieuwe email is.
Figuur 2 (Veen, 2012)
Long polling
Long polling lijkt op polling, al is er 1 verschil. De client stuurt ook in dit geval een request naar de server, in dit geval de API van Regterschot Racing. De server krijgt deze request binnen maar stuurt niet gelijk een response terug. De server wacht echter tot hij nieuwe info heeft. Op het moment dat dat zo is stuurt hij deze info terug aan de client. De client stuurt op dat moment gelijk weer een nieuwe request.
Figuur 3 (Veen, 2012)
Server-sent events (SSE)
Bij SSE stuurt de client een request naar een server. De server opent dan een connectie tussen de twee. De server stuurt niks terug tot het moment dat deze nieuwe data krijgt. Op het moment dat deze nieuwe data krijgt stuurt hij deze naar de client. De connectie wordt echter niet gesloten en blijft dus bestaan. Dit zorgt ervoor dat de client niet opnieuw een request hoeft te sturen, maar gewoon kan wachten op de nieuwe data van de server.
Figuur 4 (Veen, 2012)
Websocket
Een websocket lijkt veel op SSE. Een websocket is te vergelijken met bijvoorbeeld WhatsApp. Bij SSE wordt er een connectie geopend en kan de server ten alle tijde data sturen naar de client. Bij een websocket kan dit ook, echter kan ook de client nieuwe data sturen naar de server, wat niet mogelijk is bij SSE.
...
Figuur 5 (Veen, 2012)
Welke techniek wordt er bij autoraces gebruikt om de data van de auto naar een pit te krijgen?
Data via radiosignalen
De sensoren die in een F1 raceauto zitten zijn veelal met elkaar verbonden. Elke auto heeft zijn eigen netwerk en de data wordt van punt één naar punt twéé verzonden. Uiteindelijk komt alle data binnen op een server die nog in de auto zelf zit. De data wordt op dat moment geëncrypt en verzonden naar de pit met gebruik van radio signalen. Op een race circuit staan meerdere palen die de radiosignalen op kunnen pikken en weer kunnen versturen. De palen staan op zo'n manier ingedeeld dat als een coureur niet meer in het bereik is van paal A, hij wel in het bereik is van paal B.
...
Long polling is een soort van opvolger en in dit geval een betere opvolger van polling. Long polling begint op dezelfde manier. Er wordt een request gestuurd naar de server vanaf de client. Hier is ook gelijk al te zien wat er beter is aan long polling ten opzichte van 'gewoon' polling. Bij polling wordt er een response gestuurd. Deze response is zo snel mogelijk, dus of met data, of er is geen nieuwe data. Long polling wacht tot er nieuwe data is. Is er nog geen data, dan ook geen response. Is er wel nieuwe data, dan krijg je ook de response. Zo snel als de response binnenkomt wordt er ook weer een nieuwe request gestuurd ,zodat de mogelijk nieuwe data weer zo snel mogelijk binnenkomt. Bij long polling is het echter wel zo dat een server of client soms denkt dat de connection te lang open heeft gestaan en dat deze connection na een tijd gesloten wordt. Het gebruikt meer middelen resources dan een websocket. Ook kan het zijn dat er meerdere poll requests open staan naar een server en de volgorde van de berichten niet klopt.
...
Server-sent events en websockets lijken veel op elkaar, ook is er in dit geval één kopje voor de twee samen. Een aantal verschillen tussen de twee, is dat SSE over HTTP gebruikt kan worden, terwijl websockets hun eigen protocol hebben. Een groot verschil tussen deze data transfer technieken, is wie requests en responses kan sturen. Bij SSE wordt er één keer een request gestuurd naar de server. Deze request is een aanvraag om te verbinden. Daarna kan alleen de server berichten terug sturen. De client kan geen berichten naar de server sturen. Dit is ook waar SSE voor gemaakt is. Websockets die wel berichten kunnen sturen naar de server als er eenmaal een connectie is geopend zijn overbodig. Daarnaast zijn er andere voor- en nadelen te benoemen, zoals dat SSE maar een maximum aantal van open connecties mag hebben Voor dit probleem zijn er oplossingen te bedenken. Een makkelijke oplossing voor dit probleem is het gebruik van meerdere host names. In plaats van www.example.com kan je ook www1.example.com en www2.example.com gebruiken.
Conclusie
Als we los kijken naar alle systemen, dan zijn er twee die uitspringen. Dit zijn de server-side events en websockets. Deze twee bijna identieke technieken zijn de technieken die ons het beste lijken. Een websocket en een server-side event service zijn de twee keuzes die het meest real time data weergeven, zonder dat deze technieken extra middelen gebruiken
...