બ્રાઉઝરમાં WebSocket હાર્ટબીટને એપ્લિકેશન પ્રોટોકોલની જરૂર છે
જ્યારે બ્રાઉઝર JavaScript સીધું WebSocket Ping ફ્રેમ મોકલી શકતું ન હોય ત્યારે સંમત એપ્લિકેશન હાર્ટબીટ ડિઝાઇન કરો.
બ્રાઉઝરના WebSocket API પાસે send() છે. તે JavaScript માટે પ્રોટોકોલ Ping ફ્રેમ મોકલવા માટે સામાન્ય ping() પદ્ધતિ ખુલ્લી કરતું નથી.
જો તમારી એપ્લિકેશન {"type":"heartbeat"} જેવો ટેક્સ્ટ સંદેશ મોકલે, તો તે એપ્લિકેશન ડેટા છે. સર્વરે સંદેશ સમજવો જોઈએ અને પ્રતિસાદ નક્કી કરવો જોઈએ. જે સર્વર તે કરાર અમલમાં મૂકતું નથી, તેણે ફક્ત ટેક્સ્ટમાં ping શબ્દ હોવાને કારણે પ્રોટોકોલ Pong સાથે જવાબ આપવો ફરજિયાત નથી.
સ્વીકૃતિનો અર્થ શું છે, તે બાકી હાર્ટબીટને કેવી રીતે ઓળખે છે અને જૂની સ્વીકૃતિ ક્યારે ઘણી મોડી થાય છે તે નક્કી કરો. તેને વ્યાવસાયિક કામગીરીની સ્વીકૃતિથી અલગ રાખો.
JavaScript ટાઇમરમાં પણ શેડ્યુલિંગ મર્યાદાઓ હોય છે. બેકગ્રાઉન્ડ ટૅબ અને વ્યસ્ત મુખ્ય થ્રેડ કૉલબૅકમાં વિલંબ કરી શકે છે. ચૂકી ગયેલી ચોક્કસ ટાઇમર મર્યાદાને પ્રોક્સીએ ફોરવર્ડ કરવાનું બંધ કર્યું તેનો નિર્ણાયક પુરાવો તરીકે અર્થઘટન ન કરો.
બ્રાઉઝર પ્રોટોકોલ નિયંત્રણ ફ્રેમ આંતરિક રીતે સંભાળી શકે છે, પરંતુ તે એપ્લિકેશન કોડને દરેક Ping કે Pongનું પોર્ટેબલ દૃશ્ય આપતું નથી. જો પૃષ્ઠને પોતાનું જીવંતતા નિર્ણય જોઈએ, તો સ્પષ્ટ એપ્લિકેશન કરાર અને રિકવરી નીતિ વાપરો.
જે સોકેટનું readyState OPEN છે તે સ્થાનિક રીતે ખુલ્લું ગણાય છે; દૂરની એપ્લિકેશને તમારો છેલ્લો સંદેશ પ્રક્રિયા કર્યો તે માટે તે સ્વતંત્ર માપન નથી. તમે ખરેખર જે પ્રશ્નનો જવાબ આપવો છે તેને અનુરૂપ પુરાવો વાપરો.