WebSocket Ping kontraŭ TCP Keepalive tra prokura servilo
Elektu vivkontrolon por la WebSocket-kunulo anstataŭ rigardi vivan TCP-ingon kiel pruvon, ke la aplika vojo respondas.
Viva TCP-ingo, respondanta WebSocket-kunulo kaj utila aplika progreso estas malsamaj observoj:
| Pruvo | Kion ĝi establas |
|---|---|
| Viveco je TCP-nivelo | La kontrolita transporta vojo respondas je tiu nivelo |
| Responda WebSocket Pong | La kunulo respondis al tiu kontrolkadro |
| Aplika konfirmo | La aplikaĵo konfirmis operacion laŭ sia propra protokolo |
Antaŭa prokuro kutime tenas apartajn konektojn al la kliento kaj al la celo. La TCP-kunulo de la kliento estas la prokuro, dum Ping ene de establita tunelo vojaĝas al la WebSocket-finpunkto.
Responda Pong
La protokolo postulas, ke responda Pong portu la aplikajn datumojn de la Ping. Uzu tiun korespondon por identigi pritraktatan provon. Ne petita Pong estas permesata, sed ĝi ne petas konfirmon; sendi unu post ĉiu datuma mesaĝo donas alian pruvon.
Preferu la subtenatan korbatadan mekanismon de la biblioteko. Retumila JavaScript bezonas anstataŭe apliknivelan korbatadan kontrakton. Elektu intervalojn kaj malsukcesajn sojlojn laŭ la laborŝarĝo kaj reta politiko. Planaj paŭzoj aŭ troloĝita eventbuklo povas maltrafi agreseman sojlon sen pruvi malsukcesan reton.
Tenu la ricevilon funkcianta
La kliento bezonas daŭran eneligon kaj eligon por ricevi kaj prilabori kontrolkadrojn. Blokado de tiu mekanismo povas igi lokan mankon aspekti kiel interrompon.
Ping kreas tunelan trafikon, sed ĉiu peranto mem decidas, kio kontentigas ĝian senaktivecan politikon. Neniu korbatado garantias protekton kontraŭ absoluta limo de la konekta vivdaŭro.
Kunulo povas respondi al Ping dum ĝia aplikaĵo ĉesas produkti ĝisdatigojn, kaj kvieta abono povas esti sana. Spuru la lastan validan Pong kaj la signifan aplikan eventon aparte, kiam ambaŭ gravas. Ĉe malsukceso konservu la vojon, pasintajn tempojn kaj la pritraktatan provon, poste fermu aŭ restaŭru per la subtenata vivociklo.