Erstellen zuverlässiger WebSocket-Clients mit Unterprotokoll

Artikel
10/26/2023

Wenn Websocket-Clientverbindungen aufgrund von zeitweiligen Netzwerkproblemen unterbrochen werden, können Nachrichten verloren gehen. In einem Pub/Sub-System werden Herausgeber von Abonnenten entkoppelt, sodass Herausgeber möglicherweise nicht die verworfene Verbindung oder den Verlust von Nachrichten erkennen. Es ist wichtig, dass Kunden zeitweilige Netzwerkprobleme überwinden und zuverlässige Nachrichtenübermittlungen Standard beibehalten. Um dies zu erreichen, können Sie einen zuverlässigen Websocket-Client mit Hilfe von zuverlässigen Azure Web PubSub-Unterprotocols erstellen.

Zuverlässiges Protokoll

Der Web PubSub-Dienst unterstützt zwei zuverlässige Unterprotocols json.reliable.webpubsub.azure.v1 und protobuf.reliable.webpubsub.azure.v1. Clients müssen den Herausgeber-, Abonnenten- und Wiederherstellungsteilen des Unterprotocols folgen, um Zuverlässigkeit zu erzielen. Wenn Sie das Unterprotocol nicht ordnungsgemäß implementieren, funktioniert die Nachrichtenübermittlung möglicherweise nicht wie erwartet oder der Dienst, der den Client aufgrund von Protokollverletzungen beendet.

Die einfache Methode – Verwenden des Client-SDK

Die einfachste Möglichkeit zum Erstellen eines zuverlässigen Clients ist die Verwendung des Client-SDK. Client SDK implementiert web PubSub-Clientspezifikation und verwendet json.reliable.webpubsub.azure.v1 standardmäßig. Informationen zum Schnellstart finden Sie unter " Veröffentlichen/Abonnieren von Clients ".

Der harte Weg - Hand implementieren

Das folgende Lernprogramm führt Sie durch den wichtigen Teil der Implementierung der Web PubSub-Clientspezifikation. Dieser Leitfaden richtet sich nicht an Personen, die nach einem Schnellstart suchen, sondern das Prinzip der Zuverlässigkeit erreichen möchten. Für den Schnellstart verwenden Sie bitte das Client-SDK.

Initialisierung

Um zuverlässige Unterprotocols zu verwenden, müssen Sie beim Erstellen von Websocket-Verbindungen das Unterprotocol festlegen. In JavaScript können Sie den folgenden Code verwenden:

Verwenden Sie json-zuverlässiges Unterprotocol:

var pubsub = new WebSocket(
  "wss://test.webpubsub.azure.com/client/hubs/hub1",
  "json.reliable.webpubsub.azure.v1"
);

Verwenden Sie Protobuf zuverlässige Unterprotocol:

var pubsub = new WebSocket(
  "wss://test.webpubsub.azure.com/client/hubs/hub1",
  "protobuf.reliable.webpubsub.azure.v1"
);

Wiederherstellen einer Verbindung

Verbinden ion Recovery ist die Grundlage für die Zuverlässigkeit und muss bei Verwendung der json.reliable.webpubsub.azure.v1 Protokolle protobuf.reliable.webpubsub.azure.v1 implementiert werden.

Websocket-Verbindungen basieren auf TCP. Wenn die Verbindung nicht abzulegen ist, sind Nachrichten verlustlos und werden in der Reihenfolge übermittelt. Um den Verlust von Nachrichten über verworfene Verbindungen zu verhindern, speichert der Web PubSub-Dienst die Verbindungsstatusinformationen, einschließlich Gruppen- und Nachrichteninformationen. Diese Informationen werden verwendet, um den Client bei der Verbindungswiederherstellung wiederherzustellen.

Wenn der Client mithilfe zuverlässiger Unterprotocols erneut eine Verbindung mit dem Dienst herstellen kann, erhält der Client eine Connected Nachricht mit den connectionId und reconnectionToken. Dies connectionId identifiziert die Sitzung der Verbindung im Dienst.

{
  "type": "system",
  "event": "connected",
  "connectionId": "<connection_id>",
  "reconnectionToken": "<reconnection_token>"
}

Sobald die WebSocket-Verbindung abgebrochen wurde, sollte der Client versuchen, die Verbindung mit demselben connectionId wiederherzustellen, um dieselbe Sitzung wiederherzustellen. Clients müssen nicht mit dem Server verhandeln und die .access_token Um die Verbindung wiederherzustellen, sollte der Client eine WebSocket-Verbindungsanforderung direkt mit dem Diensthostnamen, connection_idund reconnection_token:

wss://<service-endpoint>/client/hubs/<hub>?awps_connection_id=<connection_id>&awps_reconnection_token=<reconnection_token>

Verbinden Ionwiederherstellung kann fehlschlagen, wenn das Netzwerkproblem noch nicht wiederhergestellt wurde. Der Client sollte versuchen, die Verbindung erneut herzustellen, bis:

Die Websocket-Verbindung wird mit dem Statuscode 1008 geschlossen. Der Statuscode bedeutet, dass die Verbindungs-ID aus dem Dienst entfernt wurde.
Ein Wiederherstellungsfehler tritt weiterhin für mehr als 1 Minute auf.

Herausgeber

Clients, die Ereignisse an Ereignishandler senden oder Nachrichten an andere Clients veröffentlichen, werden als Herausgeber bezeichnet. Herausgeber sollten in der Nachricht festgelegt werden ackId , um eine Bestätigung vom Web PubSub-Dienst zu erhalten, dass die Veröffentlichung der Nachricht erfolgreich war oder nicht.

Dies ackId ist der Bezeichner der Nachricht, jede neue Nachricht sollte eine eindeutige ID verwenden. Das Original ackId sollte beim erneuten Senden einer Nachricht verwendet werden.

Beispiel für eine Nachricht, die an eine Gruppe gesendet wird:

{
  "type": "sendToGroup",
  "group": "group1",
  "dataType": "text",
  "data": "text data",
  "ackId": 1
}

Beispielantwort:

{
  "type": "ack",
  "ackId": 1,
  "success": true
}

Wenn der Web PubSub-Dienst eine Ack-Antwort zurückgibt success: true, wurde die Nachricht vom Dienst verarbeitet, und der Client kann erwarten, dass die Nachricht an alle Abonnenten übermittelt wird.

Wenn der Dienst einen vorübergehenden internen Fehler aufweist und die Nachricht nicht an Abonnenten gesendet werden kann, erhält der Herausgeber eine Leiste mit success: false. Der Herausgeber sollte den Fehler lesen, um festzustellen, ob die Nachricht erneut zurückgegeben werden soll. Wenn die Nachricht erneut angezeigt wird, sollte dasselbe ackId verwendet werden.

{
  "type": "ack",
  "ackId": 1,
  "success": false,
  "error": {
    "name": "InternalServerError",
    "message": "Internal server error"
  }
}

Message Failure

Wenn die Antwort des Diensts verloren geht, da die WebSocket-Verbindung gelöscht wurde, sollte der Herausgeber die Nachricht nach der ackId Wiederherstellung erneut senden. Wenn die Nachricht zuvor vom Dienst verarbeitet wurde, sendet sie eine Leiste, die einen Duplicate Fehler enthält. Der Herausgeber sollte das erneute Senden dieser Nachricht beenden.

{
  "type": "ack",
  "ackId": 1,
  "success": false,
  "error": {
    "name": "Duplicate",
    "message": "Message with ack-id: 1 has been processed"
  }
}

Message duplicated

Abonnent

Clients, die Nachrichten von Ereignishandlern oder Herausgebern empfangen, werden als Abonnenten bezeichnet. Wenn Verbindungen aufgrund von Netzwerkproblemen abfallen, weiß der Web PubSub-Dienst nicht, wie viele Nachrichten an Abonnenten gesendet wurden. Um die letzte nachricht zu ermitteln, die vom Abonnenten empfangen wurde, sendet der Dienst eine Datennachricht mit einem sequenceId. Der Abonnent antwortet mit einer Sequenz-Ack-Nachricht:

Beispiel für eine Sequenzbestätigung:

{
  "type": "sequenceAck",
  "sequenceId": 1
}

Dies sequenceId ist eine inkrementelle Zahl in einer Verbindungs-ID-Sitzung. Abonnenten sollten die größte sequenceId Empfangene aufzeichnen, nur Nachrichten mit einer größeren sequenceIdNachricht akzeptieren und Nachrichten mit einer kleineren oder gleichen sequenceIdablegen. Der Abonnent sollte mit der größten sequenceId aufgezeichneten Nachricht ackn, sodass der Dienst die Neubelebung von Nachrichten überspringen kann, die Abonnenten bereits erhalten haben. Wenn der Abonnent z. B. mit einem sequenceAck "With sequenceId: 5" antwortet, sendet der Dienst nur Nachrichten mit einer sequenceId Größe von mehr als 5 erneut.

Alle Nachrichten werden an Abonnenten übermittelt, bis die WebSocket-Verbindung abbricht. Mit sequenceIddiesem Dienst kann der Dienst wissen, wie viele Nachrichtenabonnenten über WebSocket-Verbindungen in einer Sitzung empfangen haben. Nachdem eine WebSocket-Verbindung abgebrochen wurde, werden nachrichten vom Abonnenten nicht bestätigt. Der Dienst speichert eine begrenzte Anzahl unbekannter Nachrichten. Wenn die Anzahl der Nachrichten den Grenzwert überschreitet, schließt der Dienst die WebSocket-Verbindung und entfernt die Sitzung. So sollten Die Abonnenten so sequenceId schnell wie möglich cken.

Freigeben über