Rrahjet e zemrës së WebSocket në shfletues kërkojnë një protokoll aplikacioni
Dizajnoni një rrahje zemre aplikacioni të rënë dakord kur JavaScript i shfletuesit nuk mund të dërgojë drejtpërdrejt korniza WebSocket Ping.
API-ja WebSocket e shfletuesit ka send(). Ajo nuk ofron një metodë ping() të përgjithshme që JavaScript të dërgojë korniza Ping të protokollit.
Nëse aplikacioni juaj dërgon një mesazh teksti si {"type":"heartbeat"}, ato janë të dhëna aplikacioni. Serveri duhet ta kuptojë mesazhin dhe të përcaktojë një përgjigje. Një server që nuk e zbaton atë kontratë nuk është i detyruar të përgjigjet me një Pong protokolli vetëm sepse teksti përmban fjalën ping.
Përcaktoni çfarë do të thotë një konfirmim, si e identifikon rrahjen e zemrës në pritje dhe kur një konfirmim i vjetër është tepër i vonuar. Mbani këtë të ndarë nga konfirmimi i një operacioni biznesi.
Edhe një kohëmatës JavaScript ka kufizime planifikimi. Skedat në sfond dhe rrjedhat kryesore të zëna mund t'i vonojnë kthimet. Mos e interpretoni një kufi të saktë kohëmatësi të humbur si provë përfundimtare se përfaqësuesi ndaloi së përcjelli.
Shfletuesi mund t'i përpunojë brenda vetes kornizat e kontrollit të protokollit, por kjo nuk i jep kodit të aplikacionit një pamje të transportueshme të çdo Ping ose Pong. Nëse faqja ka nevojë për vendimin e vet të gjallërisë, përdorni një kontratë të qartë aplikacioni dhe një politikë rikuperimi.
Një prizë, readyState e së cilës është OPEN, konsiderohet lokalisht e hapur; nuk është një matje e pavarur që aplikacioni i largët e përpunoi mesazhin tuaj të fundit. Përdorni provat që përputhen me pyetjen së cilës vërtet duhet t'i përgjigjeni.