Orion PUB/SUB Protokoll

Question

Welches Protokoll wird in Orion PUB/SUB verwendet?

NATS zum Beispiel nutzt so etwas wie diese: http://nats.io/documentation/internals/nats-protocol/

Wie dieser Mechanismus Arbeit in Orion auf der Protokollebene?

Ich denke, einige der folgenden Mechanismen verwendet werden: https://github.com/slact/nchan#subscriber-endpoint, um die Nachricht an den Abonnenten über HTTP-Verbindung, die offen gehalten wird. Welcher genau?

BR,

Drasko

Answer 1

Orion NGSI API ist REST Basis in HTTP als Applikationsprotokoll (die Sequenz ist in TCP/IP als Transport/Netzwerk-Protokoll-basiert). Orion kann auch im HTTPS-Modus arbeiten, unter Verwendung der -httpsCLI parameter (wie lange siwth -cert und -key).

In der Vergangenheit unterstützten wir NGSI-API basierend auf CoAP (die in Folge in UDP basiert). Dieser Code wird jedoch nicht mehr beibehalten (obwohl er immer noch verfügbar ist here).

Schließlich entwickeln wir einen Websocket-Transport für NGSIv2 (die neue Version der NGSI-API, in der wir gerade arbeiten), aber es ist noch in einem sehr frühen und experimentellen Status.

Answer 2

@fgalan,

genau zu sein NGSI PUB/SUB über HTTP-Protokoll spezifiziert, was ungewöhnlich und wahrscheinlich nicht effizient ist.

Um der Lage sein, die Nachricht zurück zu HTTP-Teilnehmer von der Server-Seite zu schieben, müssen Sie einige Tricks verwenden:

• Lange Polling
• Interval-Polling
• Eventsource
• HTTP multipart/mixed
• HTTP segmentierte Übertragungs

Diese verhindern das Schließen der HTTP-Verbindung, so dass der Server die Daten an den Abonnenten senden kann, sobald sie angekommen sind (beachten Sie, dass dies nicht das erneute Öffnen der HTTP-Verbindung für jeden PUB/SUB verhindert, den Sie von der Clientseite durchführen möchten auch resorce-konsumierend). Sie können mehr darüber hier lesen: http://mrjoes.github.io/2013/06/21/python-realtime.html

Das ist genau das, was ich Frage - welche dieser Methoden verwenden Sie in Orion, und können Sie mich bitte auf den Code verweisen.

Wegen dieser Probleme mit HTTP ist es wirklich ungewöhnlich, HTTP für PUB/SUB zu verwenden. Es gibt keine erfolgreiche Lösung, die es tut (nach meinem Wissen), und alle anderen verwenden ein anderes spezifisches Protokoll für RT Messaging - RabbitMQ (AQMP), Redis, NATS, Kafka, MQTT - Sie benötigen ein Protokoll, das für PUB/SUB geeignet ist wenn Sie wollen, dass es effizient ist.

Apropos - haben Sie jemals Ihre PUB/SUB-Warteschlange mit anderen Lösungen verglichen? Ich würde Orion sehr gerne in einer dieser Analysen sehen: http://bravenewgeek.com/dissecting-message-queues/, Seite an Seite mit der Schlachtfeld-erprobten SW für diesen Zweck. Ich würde gerne die Latenzen und den Durchsatz sehen ...

Ich kann sehen, warum WS benötigt werden, aber ich sehe nicht, wie Sie sie mit NGSI-Spezifikation ausrichten werden - Ihre Spezifikation erfordert heute PUB/SUB über HTTP (über REST-Aufruf). Werden Sie die Spezifikation ändern?

Mit freundlichen Grüßen,

Drasko

Answer 3

Nun, Orion HTTP-Benachrichtigungen wurden ursprünglich entwickelt für Server-zu-Server-Kommunikation. Tatsächlich erlauben sie Orion, andere Komponenten in der "Datenkette" von FIWARE mit Cygnus oder anderen Mechanismen zu verbinden.

Für Server-zu-Client-Benachrichtigungen besteht eine Alternative darin, ein Websocket-Gateway zwischen Orion und einem Webclient zu verwenden. Das wurde schon oft umgesetzt.

Was wir jetzt tun, ist das Hinzufügen "nativer" Websocket-Kanäle, abgesehen von HTTP, für Orion-Benachrichtigungen. Diese Websocket-Kanäle können in der Server-zu-Server-Kommunikation oder in der Server-Browser-Kommunikation verwendet werden. Das bedeutet nicht, dass wir NGSI ändern werden. Das bedeutet, dass wir einen weiteren Benachrichtigungskanal hinzufügen und die API so ändern, dass Entwickler einen Web-Socket-Kanal verwenden können.