Vytvoření spolehlivého websocketu pomocí subprotocolu

Článek
11/14/2023

Když připojení klientů Protokolu Websocket klesne kvůli přerušovaným problémům se sítí, můžou se zprávy ztratit. V pub/subsystému jsou vydavatelé odděleni od odběratelů, takže vydavatelé nemusí zjistit vyřazené připojení nebo ztrátu zpráv odběratele. Pro klienty je zásadní překonat přerušované problémy se sítí a udržovat spolehlivé doručování zpráv. Abyste toho dosáhli, můžete vytvořit spolehlivého klienta Websocket pomocí spolehlivých subprotokolů Azure Web PubSub.

Reliable Protocol

Služba Web PubSub podporuje dvě spolehlivé subprotocoly json.reliable.webpubsub.azure.v1 a protobuf.reliable.webpubsub.azure.v1. Aby klienti dosáhli spolehlivosti, musí dodržovat části podprotokolu vydavatele, odběratele a obnovení. Selhání správné implementace subprotocol může vést k tomu, že doručení zprávy nefunguje podle očekávání nebo služba ukončuje klienta kvůli porušení protokolu.

Snadný způsob – použití klientské sady SDK

Nejjednodušší způsob, jak vytvořit spolehlivého klienta, je použít klientskou sadu SDK. Klientská sada SDK implementuje specifikaci klienta Web PubSub a ve výchozím nastavení ji používá json.reliable.webpubsub.azure.v1 . Rychlý start najdete v tématu Publikování a přihlášení k odběru klientů .

Tvrdá cesta – implementace ručně

Následující kurz vás provede důležitou součástí implementace specifikace klienta Web PubSub. Tato příručka není určená pro lidi, kteří hledají rychlý start, ale chtějí znát princip dosažení spolehlivosti. Pro rychlý start použijte klientskou sadu SDK.

Inicializace

Chcete-li použít spolehlivé subprotocols, je nutné nastavit subprotocol při vytváření připojení Websocket. V JavaScriptu můžete použít následující kód:

Použijte spolehlivý dílčí souhrn JSON:

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

Používejte protobuf reliable subprotocol:

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

obnovení Připojení

Připojení obnovení je základem dosažení spolehlivosti a musí být implementováno při použití json.reliable.webpubsub.azure.v1 protokolůprotobuf.reliable.webpubsub.azure.v1.

Připojení protokolu Websocket využívají protokol TCP. Když se připojení neodhodí, zprávy se doručují bezeztrátově a doručují se v pořadí. Aby se zabránilo ztrátě zpráv nad ukončenými připojeními, služba Web PubSub uchovává informace o stavu připojení, včetně informací o skupině a zprávě. Tyto informace slouží k obnovení klienta při obnovení připojení.

Když se klient znovu připojí ke službě pomocí spolehlivých dílčích protokolů, klient obdrží Connected zprávu obsahující a connectionIdreconnectionToken. Identifikuje connectionId relaci připojení ve službě.

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

Jakmile připojení WebSocket klesne, měl by se klient pokusit znovu připojit se stejným connectionId způsobem, aby se obnovila stejná relace. Klienti nemusí s serverem vyjednávat a získat access_token. Místo toho, aby se připojení obnovilo, měl by klient vytvořit požadavek připojení WebSocket přímo ke službě s názvem hostitele služby a connection_idreconnection_token:

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

Připojení obnovení může selhat, pokud se problém se sítí ještě neobnovil. Klient by se měl pokusit znovu připojit, dokud:

Připojení Websocket je uzavřeno se stavovým kódem 1008. Stavový kód znamená, že id připojení bylo ze služby odebráno.
Selhání obnovení trvá déle než 1 minutu.

Vydavatel

Klienti, kteří odesílají události obslužné rutině událostí nebo publikují zprávy do jiných klientů, se nazývají vydavatelé. Vydavatelé by měli ve zprávě nastavit ackId potvrzení o přijetí potvrzení ze služby Web PubSub, která zprávu publikovala úspěšně nebo ne.

Jedná se ackId o identifikátor zprávy, každá nová zpráva by měla používat jedinečné ID. Při opětovném odeslání zprávy by se měl použít původní ackId text.

Ukázková skupina pro odeslání zprávy:

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

Ukázková odpověď ack:

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

Když služba Web PubSub vrátí odpověď ack s success: true, zpráva byla zpracována službou a klient může očekávat, že zpráva bude doručena všem odběratelům.

Když služba dojde k přechodné vnitřní chybě a zpráva nemůže být odeslána odběrateli, vydavatel obdrží akci s success: false. Vydavatel by měl přečíst chybu a zjistit, jestli chcete zprávu znovu odeslat. Pokud se zpráva znovu odešle, měla by se použít stejná ackId .

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

Message Failure

Pokud dojde ke ztrátě odpovědi ack služby, protože došlo k vyřazení připojení WebSocket, měl by vydavatel zprávu po obnovení znovu odeslat se stejnou zprávou ackId . Když služba dříve zprávu zpracovala, odešle zprávu obsahující Duplicate chybu. Vydavatel by měl ukončit opětovné odeslání této zprávy.

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

Message duplicated

Odběratel

Klienti, kteří přijímají zprávy z obslužných rutin událostí nebo vydavatelů, se nazývají odběratelé. Když dojde k poklesu připojení kvůli problémům se sítí, služba Web PubSub neví, kolik zpráv bylo odesláno odběratelům. Chcete-li určit poslední zprávu přijatou odběratelem, služba odešle datovou zprávu obsahující sequenceId. Odběratel odpoví sekvenční zprávou:

Ukázková sekvence ack:

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

Jedná se sequenceId o přírůstkové číslo uint64 v relaci ID připojení. Odběratelé by měli zaznamenat největší sequenceId přijaté zprávy, přijmout pouze zprávy s větší sequenceId, a vypustit zprávy s menší nebo rovnou sequenceId. Odběratel by měl mít největší sequenceId záznam, aby služba mohl přeskočit opětovné nasazení zpráv, které odběratelé už obdrželi. Pokud například odběratel odpoví pomocí sequenceAcksequenceId: 5příkazu s , služba odešle pouze zprávy s sequenceId větším než 5.

Všechny zprávy se doručí odběratelům v pořadí, dokud připojení WebSocket neupadne. Díky sequenceIdtomu může služba zjistit, kolik odběratelů zpráv obdrželo připojení WebSocket v relaci. Po ukončení připojení WebSocket služba znovu potvrdí zprávy, které odběratel nepotvrdí. Služba ukládá omezený počet nevěděných zpráv. Pokud počet zpráv překročí limit, služba zavře připojení WebSocket a odebere relaci. Předplatitelé by tedy měli co nejdříve postupovat sequenceId .