WebSocket-korbatoj en la retumilo bezonas aplikaĵan protokolon
Projektu interkonsentitan aplikaĵan korbaton, kiam la JavaScript de la retumilo ne povas rekte sendi WebSocket Ping-kadrojn.
La WebSocket-API de la retumilo havas send(). Ĝi ne elmetas ĝeneralan metodon ping() por ke JavaScript sendu Ping-kadrojn de la protokolo.
Se via aplikaĵo sendas tekstan mesaĝon kiel {"type":"heartbeat"}, tio estas aplikaĵaj datumoj. La servilo devas kompreni la mesaĝon kaj difini respondon. Servilo, kiu ne realigas tiun kontrakton, ne devas respondi per protokola Pong nur ĉar la teksto enhavas la vorton ping.
Difinu, kion signifas konfirmo, kiel ĝi identigas la atendatan korbaton, kaj kiam malnova konfirmo estas tro malfrua. Tenu ĝin aparte de la konfirmo de komerca operacio.
Ankaŭ JavaScript-tempigilo havas planadajn limigojn. Fonaj langetoj kaj okupitaj ĉefaj fadenoj povas prokrasti retrovokojn. Ne interpretu maltrafitan precizan tempigilan limon kiel konkludan pruvon, ke la prokurilo ĉesis plusendi.
La retumilo povas interne pritrakti kontrolkadrojn de la protokolo, sed tio ne donas al la aplikaĵa kodo porteblan vidon de ĉiu Ping aŭ Pong. Se la paĝo bezonas propran decidon pri vivkapablo, uzu eksplicitan aplikaĵan kontrakton kaj reakiran politikon.
Ingoto, kies readyState estas OPEN, estas loke konsiderata malfermita; tio ne estas sendependa mezuro, ke la fora aplikaĵo pritraktis vian lastan mesaĝon. Uzu la pruvojn konformajn al la demando, kiun vi efektive devas respondi.