Չատը կենդանի պահել, երբ հեռախոսը քնում է

Mythex-ի agent-ը կարող է մի հարցումով աշխատել րոպեներ շարունակ, և դուք հավանաբար հեռախոսից եք դիտում։ Հեռախոսը կողպվում է, փոխում է հավելվածները և ցանցեր, երբ աշխատում է։ Երկու սխալ այդ ժամանակ խնդիր էր առաջացնում։ Մեկում չատը ամեն «էջը նորից տեսանելի է» ազդանշանը համարում էր, որ իր կապը մեռել է, և կրկնվում էր, մինչև մնում էր «Connecting…»-ի վրա։ Մյուսում հեռախոսը, որ քնել էր նոր չատի առաջին պատասխանի ընթացքում, վերադառնում էր միայն պատասխանի առաջին մի քանի կտորով, մինչև ձեռքով թարմացնեիք էջը։ Երկուսն էլ շտկված են։

Ինչպես է չատը հետևում աշխատող քայլին

Agent-ի աշխատանքի ընթացքում չատը բաց է պահում stream մեր սերվերներից. յուրաքանչյուր քայլ՝ մտածում, գործիքի կանչ, պատասխանի կտոր, գալիս է որպես իրադարձություն։ Եթե stream-ը ընկնում է, չատը նորից միանում է, և սերվերը նորից է ուղարկում վերջին իրադարձությունները buffer-ից, որը պահում է վերջին 120 վայրկյանը։ Երբ քայլն ավարտվում է, չատը նաև սերվերից խնդրում է պահված պատմությունը և համեմատում այն, ինչ ցույց էր տվել, պահվածի հետ։ Այդ վերջին քայլը բռնում է այն ամենը, ինչ stream-ը բաց էր թողել։

Ոչինչ չկատարվելու ժամանակ կապն ողջ է թե ոչ՝ որոշելու համար, սերվերը յուրաքանչյուր 15 վայրկյանը մեկ ուղարկում է փոքրիկ «ping»։

Սխալ 1. արթնանալը սպանում էր առողջ stream-ը

Բրաուզերները էջին ասում են, երբ այն նորից տեսանելի է դառնում. ներդիրը փոխելուց հետո, էկրանը ապակողպելուց հետո։ Մենք դա օգտագործում էինք որպես նշան ստուգելու կապը, և գործնականում՝ կտրելու stream-ը և նորից միանալու, ենթադրելով, որ այն մեռել է, երբ թաքնված էր։

Հեռախոսներում և ներկառուցված բրաուզերներում այդ իրադարձությունները շատ ավելի հաճախ են գործարկվում, քան stream-երն են մեռնում. յուրաքանչյուր ներդիրի փոփոխության, յուրաքանչյուր ապակողպման ժամանակ, և որոշ ներկառուցված բրաուզերներում մոտավորապես յուրաքանչյուր մի քանի վայրկյանը մեկ։ Յուրաքանչյուրը կտրում էր առողջ stream-ը։ Չատը նորից էր միանում, վերարկվում էր, նորից կտրվում էր և վերջում մնում էր «Connecting…»-ի վրա։ Ապա ասում էր, որ քայլն ավարտվել է, մինչ agent-ը դեռ աշխատում էր։

Լուծում. դատել stream-ը ըստ նրա, թե խոսո՞ւմ է արդյոք

Չատն այժմ գրանցում է, թե յուրաքանչյուր նախագծի stream-ը երբ վերջին անգամ ինչ-որ բան է ստացել՝ և՛ իրադարձություններ, և՛ 15-վայրկյանանոց ping-ներ։ «Նորից տեսանելի» ազդանշանը կտրում է միայն այն stream-ը, որը 25 վայրկյան լուռ է եղել. ավելի երկար, քան ping-ի միջակայքը գումարած դանդաղ ցանցային թռիչքը, այնպես որ կենդանի stream-ը երբեք չի համարվում մեռած։ Թեստերը ստուգում են, որ ping-ը համարվում է կյանքի նշան, և որ այն stream-ը, որ նոր է ping արել, չի համարվում մեռած։

Կանոնը, որ սրանից վերցրինք. էջի տեսանելիությունը ասում է ինչ-որ բան էջի մասին, ոչ թե ցանցային կապի։ Հարցրեք կապին։

Սխալ 2. հեռախոսը արթնանալուց հետո՝ կես պատասխան

Սա մենք կարող էինք ամեն անգամ վերարտադրել iOS simulator-ում․

1. Սկսեք նոր չատ և ուղարկեք հարցում, որը որոշ ժամանակ է տևում։
2. Թողեք, որ հեռախոսը քնի կառուցման ընթացքում։
3. Վերադարձեք, երբ քայլն ավարտված է, և երկու րոպեանոց replay buffer-ի ժամկետը սպառվել է։

Չատը ցույց էր տալիս պատասխանի առաջին մի քանի բլոկները՝ նշված որպես ավարտված, և մնում էր այդպես մինչև էջի թարմացումը։

Ինչու

Նոր չատը ունի thread՝ պահված զրույց, միայն երբ առաջին հաղորդագրությունը ստեղծում է այն։ Դա տեղի է ունենում send ֆունկցիայի ներսում, այն բանից հետո, երբ send-ն արդեն գրավել էր reconcile քայլը, որը դեռ կարծում էր, թե thread չկա։ Ուստի առաջին քայլի ավարտին reconcile-ը thread չէր տեսնում և անհետևանք վերադառնում էր՝ առանց որևէ բան խնդրելու։

Սովորաբար ոչ ոք չէր նկատում, քանի որ stream-ը ամբողջ քայլն արդեն հասցրել էր առաքել։ Բայց հեռախոսը, որ քնել էր քայլի ընթացքում և վերադարձել էր այն բանից հետո, երբ 120-վայրկյանանոց replay buffer-ի ժամկետը սպառվել էր, չէր կարող բաց թողած իրադարձությունները ստանալ stream-ից։ Իսկ reconcile-ը, որ պետք է լրացներ բացը, երբեք չէր աշխատել։

Լուծումը

• Send-ը ասում է reconcile-ին, թե որ thread-ին է պատկանում քայլը, ուստի նոր չատի առաջին քայլը reconcile է լինում ինչպես ցանկացած այլ։ Եթե մինչ պատասխանը վերադառնալը բացել եք այլ չատ, արդյունքը հանվում է, այլ ոչ թե ցուցադրվում սխալ տեղում։
• Ձախողված reconcile-ը կրկնվում է։ Հեռախոսը, որ արթնանում է վատ կապի վրա, կարող է գտնել, որ քայլն արդեն ավարտված է, բայց չկարողանալ այն բերել։ Դա այժմ հիշվում է, և չատը նորից հարցնում է, երբ ներդիրը նորից ցուցադրվում է կամ ցանցը վերադառնում է։
• «Worked for»-ը ազնիվ է։ Յուրաքանչյուր պատասխան ցույց է տալիս, թե որքան ժամանակ է աշխատել agent-ը։ Եթե ներդիրը երբեք չէր տեսել սերվերի ավարտի հաղորդագրությունը, այն լրացնում էր այդ տվյալը սեփական ժամացույցից՝ Send-ից մինչև հեռախոսի արթնանալը, ներառյալ բացակայության ժամանակը։ Այժմ այդ թիվը նշված է որպես գնահատական, և փոխարինվում է պահված տևողությամբ, երբ պատմությունը գալիս է։

Ինչ սովորեցինք

• Փորձարկեք այն սարքի վրա, որը մարդիկ իրոք օգտագործում են, այն ձևով, ինչ իրենք են օգտագործում։ Երկու սխալն էլ ապրում էին «աշխատող stream»-ի և «գրպանում հեռախոսի» միջև եղած բացում։
• Պահուստային մեխանիզմ, որ երբեք չի աշխատում, պահուստային չէ։ Reconcile քայլը գոյություն ուներ հենց այս դեպքը բռնելու համար, և լուռ բաց էր թողնում այն։
• Կրկնեք նաև վերականգնումը։ Հեռախոսի արթնանալու պահը հաճախ այն պահն է, երբ նրա կապը ամենավատն է։
• Մի ցուցադրեք ենթադրությունը որպես փաստ։ Սխալ ժամացույցից եկած տևողությունը ավելի վատ է, քան բացակայությունը. նշեք այն կամ փոխարինեք։

Այս աշխատանքը նաև մաքրեց մի քանի բան, որ կտեսնեք քայլի ընթացքում․ shell քայլերը պիտակավորվում են այն հրամանով, որ կատարում է աշխատանքը, այլ ոչ թե cd-ով, չատի սքրինշոթները պահում են էջի վերին ձախ մասը և տեղավորվում սյունակում, իսկ նոր նախագիծը վերցնում է իր ստեղծված անունը՝ առանց թարմացնելու։

Եթե դուք հեռախոսների համար հավելված եք կառուցում, մեր ուղեցույցները հեռախոսին հարմարված վեբ հավելված կառուցելու և native և progressive web հավելվածների մասին հիմունքները են բացատրում։ Չատի մասին ավելին չատի փաստաթղթերում է։