Browserens WebSocket-API har send(). Den udstiller ikke en generel ping()-metode, som JavaScript kan bruge til at sende protokol-Ping-rammer.

Hvis din applikation sender en tekstbesked som {"type":"heartbeat"}, er det applikationsdata. Serveren skal forstå beskeden og definere et svar. En server, der ikke implementerer den kontrakt, er ikke forpligtet til at svare med et protokol-Pong, blot fordi teksten indeholder ordet ping.

Definer, hvad en kvittering betyder, hvordan den identificerer det ventende hjerteslag, og hvornår en gammel kvittering er for sent. Hold det adskilt fra kvittering af en forretningsoperation.

En JavaScript-timer har også planlægningsbegrænsninger. Baggrundsfaner og travle hovedtråde kan forsinke tilbagekald. Fortolk ikke en misset præcis timer-grænse som afgørende bevis for, at proxyen er stoppet med at videresende.

Browseren kan håndtere protokollens kontrolrammer internt, men det giver ikke applikationskode et portabelt billede af hver Ping eller Pong. Hvis siden har brug for sin egen levedygtighedsbeslutning, så brug en udtrykkelig applikationskontrakt og en gendannelsespolitik.

En socket, hvis readyState er OPEN, betragtes lokalt som åben; det er ikke en uafhængig måling af, at den fjerne applikation har behandlet din sidste besked. Brug de beviser, der passer til det spørgsmål, du faktisk skal besvare.

Relaterede artikler