Post rekonekto de prokseita WebSocket, restarigu ankaŭ la seancon

La rekonekta retrovoĉo ruliĝas kaj la nova ingo malfermiĝas. Tio estas transporta restarigo. Ĝi ne nepre signifas, ke viaj abonoj, mesaĝaj konfirmoj aŭ la aplikaĵa seanco daŭris tie, kie la antaŭa konekto haltis.

Eĉ la sama proksea finpunkto povas produkti novan eliran konekton. Ŝanĝita elira IP ankaŭ povas ekigi la propran seanpolitikon de la celo. Traktu la novan ingon kiel novan konekton kaj sekvu la dokumentitan restarigan interŝanĝon de la aplikaĵo. Decidu, ĉu la laborfluo konservu sian proksean vojon dum rekonekto.

Konservu iom pli ol la lastan URL-on

Utila restariga stato povas inkluzivi rajtigitan seancidenton, deziratajn abonojn, la identigilon de la laste konfirmita okazaĵo kaj operaciojn ankoraŭ atendantajn konfirmon. Tiuj kampoj apartenas al la aplikaĵa protokolo; WebSocket ne difinas universalan daŭrigan ĵetonon.

Decidu, ĉu daŭrigi de kursoro, akiri novan momentfoton aŭ akcepti breĉon. Se okazaĵfonto ne ofertas interfacon por reludado, pli rapida rekonekto ne povas pruvi, ke neniu mesaĝo perdiĝis.

Sendi dufoje povas signifi fari dufoje

Mesaĝo lokita en vicigo loke antaŭ malkonekto eble neniam forlasis la klienton. Alia eble atingis la servilon dum ĝia konfirmo perdiĝis. Blinde resendi ĉiun nekonfirmitan komandon traktas tiujn du kazojn kiel identajn.

Uzu la petidentigilojn de la servo, subtenon por idempotenteco aŭ interkonsiligajn mekanismojn, kie ili disponeblas. Transporta rekonekto ne povas igi aplikaĵan agon renversebla nek aŭtomate deduplici ĝin.

Tenu rekonektajn provojn limigitaj kaj laŭtaktaj laŭ la politiko de la aplikaĵo. RFC 6455 rekomendas retropaŝon post nenormala fermo; aro da klientoj, kiuj tuj reprovas, povas pliigi la ŝarĝon de la interrompo.

Notu, kiun proksean vojon ĉiu provo elektis, sed tenu vojrestarigon aparta de aplikaĵa restarigo. “Denove konektita” estas utila pruvo. “Sukcesis rekapti kaj pretas sendi pli da laboro” bezonas la plian aplikaĵan interŝanĝon, kiu tion establas.