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

Մեկ տեղադրիչ, շատ գործընթացներ

Ժամանակակից խաղային ծրագրերը փոքր համաստեղություն են։ Կա հաճախորդ, որը ձեզ մուտք է գործում, թարմացնող, որը ներբեռնում է բովանդակություն, գործարկիչ, որը սկսում է խաղը, և խաղի գործարկվող ֆայլ, որը կարող է ինքն ստեղծել երկրորդ գործընթաց՝ խարդախության դեմ պայքարի կամ խաղերի համապատասխանեցման շերտի համար։ Նրանցից յուրաքանչյուրը կարող է պահել իր սեփական կապերը դեպի իր նպատակակետերը։

Բացառման կանոնը սովորաբար անվանում է նրանցից մեկին։ Թե որին է անվանում, ամբողջովին կախված է VPN հաճախորդի աջակցած նույնացուցիչից, և դա այն մասն է, որը օգտատերերը հազվադեպ են ստուգում։ Որոշ հաճախորդներ համապատասխանեցնում են գործարկվող ֆայլի ուղին, ոմանք՝ փաթեթի կամ bundle-ի նույնացուցիչը, և ոմանք՝ գործընթացի անուն, որը երկու անկապ բինար ֆայլեր կարող են կիսել։ Կարդացեք կանոնը նախքան գործընթացների ցանկը, որովհետև կանոնը սահմանափակում է նույնիսկ այն, ինչ կարող եք արտահայտել։

Ուստի ախտանիշը «բաժանված թունելը կոտրված է» չէ։ Այն «կանոնն ընդգրկում է մի գործընթաց, որը ինձ համար կարևոր երթևեկությունը կրող գործընթացը չէ» ձևակերպումն է, որը շատ ավելի նեղ և շատ ավելի ուղղելի պնդում է։ Երբ այդպես ասեք, հաջորդ քայլն այլևս գուշակություն չէ։

Գտեք այն գործընթացը, որին պատկանում է խաղի կապը

Սկսեք խաղը, մտեք խաղի մեջ և նայեք, թե ում են պատկանում սոքեթները, այլ ոչ թե ինչ է էկրանին։ Windows-ում գործընթացների ցանկը գումարած յուրաքանչյուր գործընթացի սոքեթի հարցումը դրան պատասխանում են երկու հրամանով՝

Get-Process | Where-Object { $_.ProcessName -match 'launcher|game|client' } | Select-Object Id,ProcessName,Path
Get-NetTCPConnection -State Established | Select-Object OwningProcess,RemoteAddress,RemotePort | Sort-Object OwningProcess

Երկրորդ հրամանը տպում է գործընթացի ID, ոչ թե անուն, ուստի միացրեք երկու արդյունքները ID-ով։ Ձեր փնտրած տողն այն է, որի հեռավոր հասցեն պատկանում է խաղի ծառայությանը, և դրա սեփականատեր գործընթացը այն գործարկվող ֆայլն է, որը ձեր կանոնը պետք է անվանի։

Linux-ում նույն հարցը պահանջում է մեկ հրաման յուրաքանչյուր սոքեթի տեսակի համար, և արժե ստուգել երկուսն էլ, որովհետև խաղի կապը կարող է UDP լինել, մինչդեռ մնացած ամեն ինչ TCP է՝

ss -tunp state established | grep -i game
ss -tunp | awk 'NR==1 || /udp/'

Եթե խաղը աշխատում է կոնտեյներում կամ համատեղելիության շերտում, ձեր գտած գործընթացը կարող է shim լինել, ոչ թե ձեր տեղադրած բինար ֆայլը։ Այդ դեպքում կարևոր նույնացուցիչը այն է, ինչ տեսնում է հաճախորդը, որը կարող է shim-ի ուղին լինել, և բնօրինակ ֆայլի խմբագրումը որևէ ազդեցություն չի ունենա։

Համապատասխանեցրեք ձեր հաճախորդի աջակցած նույնացուցիչը

Կարդացեք հաճախորդի փաստաթղթերը բացառման կանոնի մասին նախքան որևէ բան ավելացնելը։ Երեք սովորական մոդելները տարբեր կերպ են վարվում, և նրանցից մեկը թակարդ է։

IdentifierHow it behavesFailure mode
Executable pathMatches exactly the file at that pathBreaks when an update moves the binary
Process nameMatches any binary with that nameToo broad; catches unrelated software
Package or bundle idMatches a signed application groupMay include services you did not intend

Ուղու կանոնները ամենաճշգրիտ և ամենափխրունն են։ Գործարկիչի թարմացումը, որը տեղափոխում է գործարկվող ֆայլը, կանոնը թողնում է ցույց տալու այլևս չաշխատող ֆայլի, և ախտանիշը վերադառնում է առանց որևէ ակնհայտ փոփոխության։ Փաթեթի կանոնները դրան դիմանում են, և կարող են նաև լուռ ծածկել օժանդակ գործընթացներ, որոնց մասին երբեք չեք մտածել, ինչը հարմար է կամ անհանգստացնող՝ կախված օժանդակից։

Ինչ էլ աջակցի հաճախորդը, մի ավելացրեք գրառումներ յուրաքանչյուր գտած գործարկվող ֆայլի համար։ Փորձի և սխալի միջոցով հավաքված ցանկը, մինչև մեկ նստաշրջան աշխատեց, վերանայելի չէ, և լուռ կկուտակի բացառություններ անկապ ծրագրերի համար։ Անվանեք ձեր գտած գործընթացը և գրեք, թե ինչի համար էր։

Ստուգեք խաղի վրա, ոչ թե ներբեռնման վրա

Գործարկիչի ներբեռնման արագությունը հնարավոր ամենավատ ստուգումն է, որովհետև այն աշխատեցնում է հենց այն գործընթացը, որն արդեն բացառված էր։ Օգտագործեք այն, ինչը ձախողվում էր, և ստուգեք ուղին, այլ ոչ թե խաղի սեփական աշխատանքի ցուցիչը՝

ip route get 203.0.113.55
Get-NetTCPConnection -State Established | Where-Object RemotePort -eq 27015

Առաջին հրամանին պետք է այն հասցեն, որին լուծվել է խաղի սերվերը, որը կարող է տալ խաղի կապի մատյանը կամ ձեր հաճախորդը։ Եթե երթուղին անվանում է ֆիզիկական ինտերֆեյսը, կանոնն աշխատում է։ Երկրորդը ցույց է տալիս՝ ընդհանրապես նստաշրջան կա արդյոք, ինչը տարանջատում է «բացառված է, բայց սերվերը անջատված է» և «բացառված չէ» վիճակները։

Փորձարկման ընթացքում տարածաշրջանը և մուտքի ցանցը պահեք անփոփոխ։ Խաղը, որը յուրաքանչյուր փորձի ժամանակ տարբեր տվյալների կենտրոնում է վայրէջք կատարում, տարբեր հասցեներ է առաջացնում, և դուք ի վերջո կհետապնդեք շարժվող թիրախի՝ կանոնը վավերացնելու փոխարեն։ Նույն հասցեով երկու գործարկումն ավելի արժեքավոր է, քան տարբեր հասցեներով տասը։

Նորից ստուգեք հաջորդ թարմացումից հետո

Ուղու վրա հիմնված ցանկացած կանոն ունի շերտերի ցիկլերով չափվող պահպանման ժամկետ։ Երբ խաղը մեկ ամիս անց դադարի հարգել բացառությունը, առաջինը ստուգեք՝ արդյոք գործարկվող ֆայլը տեղափոխվել է, և երկրորդը՝ արդյոք կողքին հայտնվել է նոր օժանդակ գործընթաց։

Մեկ հաճախորդի կողմից փաստաթղթավորված հավելվածների բացառման մոդելը ողջամիտ հղում է այն բանի, թե ինչպես են նկարագրում այս կանոնները, թեև մանրամասները տարբերվում են ապրանքների միջև։ Կարդացեք ձերը, գրանցեք օգտագործած նույնացուցիչը և նշեք ամսաթիվը։ Այդ գրառումն է, որ հաջորդ անգամ գործարկիչի թարմացում ուղարկելիս առեղծվածը դարձնում է հինգ րոպեանոց ուղղում։

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

Առնչվող հոդվածներ