WebSocket Ping ընդդեմ TCP Keepalive-ի՝ պրոքսիի միջով

Կենդանի TCP սոքեթը, պատասխանող WebSocket զուգընկերը և հավելվածի օգտակար առաջընթացը տարբեր դիտարկումներ են.

Առաջադիր պրոքսին սովորաբար առանձին կապեր է պահում դեպի հաճախորդը և դեպի նշանակակետը։ Հաճախորդի TCP զուգընկերը պրոքսին է, մինչդեռ հաստատված թունելի ներսում Ping-ը հասնում է WebSocket վերջնակետին։

Համապատասխան Pong

Արձանագրությունը պահանջում է, որ պատասխանող Pong-ը կրի Ping-ի հավելվածային տվյալները։ Օգտագործեք այդ համապատասխանությունը սպասող ստուգումը ճանաչելու համար։ Չպահանջված Pong-ը թույլատրվում է, բայց հաստատում չի պահանջում. այն ամեն տվյալային հաղորդագրությունից հետո ուղարկելը տալիս է այլ ապացույց։

Նախապատվություն տվեք գրադարանի աջակցած սրտազարկի մեխանիզմին։ Բրաուզերի JavaScript-ին փոխարենը պետք է հավելվածային մակարդակի սրտազարկի պայմանագիր։ Ընտրեք ինտերվալներն ու ձախողման շեմերը՝ ըստ ծանրաբեռնվածության և ցանցային քաղաքականության։ Ժամանակացույցի դադարները կամ ծանրաբեռնված իրադարձությունների հանգույցը կարող են բաց թողնել ագրեսիվ շեմը՝ առանց ցանցի ձախողում ապացուցելու։

Պահեք ստացողը աշխատունակ

Հաճախորդին անհրաժեշտ է շարունակական մուտք-ելք՝ կառավարման շրջանակները ստանալու և մշակելու համար։ Այդ մեխանիզմի արգելափակումը կարող է տեղային պակասը ներկայացնել որպես ընդհատում։

Ping-ը ստեղծում է թունելային երթևեկություն, սակայն յուրաքանչյուր միջնորդ ինքն է որոշում, թե ինչն է բավարարում իր պարապության քաղաքականությանը։ Ոչ մի սրտազարկ չի երաշխավորում պաշտպանություն կապի կյանքի բացարձակ սահմանից։

Զուգընկերը կարող է պատասխանել Ping-ին նաև այն ժամանակ, երբ նրա հավելվածը դադարել է թարմացումներ արտադրել, և լուռ բաժանորդագրությունը կարող է առողջ լինել։ Երբ երկուսն էլ կարևոր են, առանձին հետևեք վերջին վավեր Pong-ին և իմաստալից հավելվածային իրադարձությանը։ Ձախողման դեպքում պահպանեք երթուղին, անցած ժամանակները և սպասող ստուգումը, ապա փակեք կամ վերականգնեք աջակցվող կյանքի ցիկլի միջոցով։