Pagkatapos muling kumonekta ng WebSocket sa pamamagitan ng proxy, ibalik din ang session

Tumakbo ang callback ng muling pagkonekta at bumukas ang bagong socket. Iyon ay pagbawi ng transport. Hindi ito laging nangangahulugang nagpatuloy ang iyong mga subscription, pagkilala sa mensahe o session ng aplikasyon mula sa lugar kung saan huminto ang dating koneksyon.

Kahit ang parehong proxy endpoint ay maaaring gumawa ng bagong papalabas na koneksyon. Ang nabagong exit IP ay maaari ring mag-trigger ng sariling patakaran sa session ng destinasyon. Ituring ang bagong socket bilang bagong koneksyon at sundin ang dokumentadong palitan ng pagbawi ng aplikasyon. Magpasya kung dapat panatilihin ng workflow ang ruta nito sa proxy kapag muling kumonekta.

Magtabi ng kaunti pa sa huling URL

Ang kapaki-pakinabang na estado ng pagbawi ay maaaring kasama ang awtorisadong pagkakakilanlan ng session, mga gustong subscription, identifier ng huling nakumpirmang event at mga operasyong naghihintay pa ng pagkilala. Ang mga field na iyon ay pag-aari ng protocol ng aplikasyon; hindi naglalarawan ang WebSocket ng pangkalahatang resume token.

Magpasya kung magpapatuloy mula sa cursor, kukuha ng bagong snapshot, o tatanggap ng puwang. Kung ang pinagmulan ng event ay walang interface para sa replay, hindi mapapatunayan ng mas mabilis na muling pagkonekta na walang mensaheng napalampas.

Ang pagpapadala nang dalawang beses ay maaaring mangahulugang paggawa nang dalawang beses

Ang mensaheng inilagay sa lokal na pila bago ang pagkadiskonekta ay maaaring hindi kailanman umalis sa kliyente. Ang isa pa ay maaaring nakarating sa server habang nawala ang pagkilala nito. Ang walang pag-iisip na muling pagpapadala ng bawat hindi nakumpirmang utos ay itinuturing na pareho ang dalawang kasong iyon.

Gamitin ang mga request identifier ng serbisyo, suporta sa idempotency o mekanismo ng pagkakasundo kung mayroon. Ang muling pagkonekta ng transport ay hindi makagagawa ng aksyon ng aplikasyon na mababalik o awtomatikong mag-aalis ng duplikasyon nito.

Panatilihing may hangganan ang mga pagtatangkang muling kumonekta at ayon sa patakaran ng aplikasyon ang tulin. Inirerekomenda ng RFC 6455 ang pag-atras pagkatapos ng abnormal na pagsasara; ang isang pulutong ng mga kliyenteng agad na nagtatangkang muli ay maaaring magpataas ng karga ng pagkawala ng serbisyo.

Itala kung aling ruta sa proxy ang pinili ng bawat pagtatangka, ngunit ihiwalay ang pagbawi ng ruta sa pagbawi ng aplikasyon. Ang “kumonekta muli” ay kapaki-pakinabang na ebidensya. Ang “nakahabol at handang magsumite ng mas maraming trabaho” ay nangangailangan ng karagdagang palitan ng aplikasyon na nagtatatag niyon.