Ձեր բաժանված թունելը բացառում է գործարկիչը, ոչ թե խաղը
Գործարկիչը խաղի համար սկսում է մեկ այլ գործարկվող ֆայլ, և այդ գործընթացն ունի իր սեփական սոքեթները։ Գտեք իրական գործընթացը, համապատասխանեցրեք ճիշտ նույնացուցիչը, ապա ստուգեք։
Դուք գործարկիչը ավելացնում եք բացառությունների ցանկին, ներբեռնումը թռչում է դանդաղից արագ, և խաղը դեռ վայրէջք է կատարում հեռավոր սերվերում։ Ոչինչ կոտրված չէ։ Գործարկիչը և խաղը երկու գործընթաց են՝ սոքեթների երկու հավաքածուով, և մեկին բացառելը ոչինչ չի ասում մյուսի մասին։ Ներբեռնումն արագացավ, որովհետև ներբեռնումը գործարկիչի երթևեկությունն էր. իսկ խաղը ուրիշի կապն է, որը բացել է ձեր կանոնի կողմից երբեք չտեսած գործարկվող ֆայլ։
Մեկ տեղադրիչ, շատ գործընթացներ
Ժամանակակից խաղային ծրագրերը փոքր համաստեղություն են։ Կա հաճախորդ, որը ձեզ մուտք է գործում, թարմացնող, որը ներբեռնում է բովանդակություն, գործարկիչ, որը սկսում է խաղը, և խաղի գործարկվող ֆայլ, որը կարող է ինքն ստեղծել երկրորդ գործընթաց՝ խարդախության դեմ պայքարի կամ խաղերի համապատասխանեցման շերտի համար։ Նրանցից յուրաքանչյուրը կարող է պահել իր սեփական կապերը դեպի իր նպատակակետերը։
Բացառման կանոնը սովորաբար անվանում է նրանցից մեկին։ Թե որին է անվանում, ամբողջովին կախված է 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-ի ուղին լինել, և բնօրինակ ֆայլի խմբագրումը որևէ ազդեցություն չի ունենա։
Համապատասխանեցրեք ձեր հաճախորդի աջակցած նույնացուցիչը
Կարդացեք հաճախորդի փաստաթղթերը բացառման կանոնի մասին նախքան որևէ բան ավելացնելը։ Երեք սովորական մոդելները տարբեր կերպ են վարվում, և նրանցից մեկը թակարդ է։
| Identifier | How it behaves | Failure mode |
|---|---|---|
| Executable path | Matches exactly the file at that path | Breaks when an update moves the binary |
| Process name | Matches any binary with that name | Too broad; catches unrelated software |
| Package or bundle id | Matches a signed application group | May include services you did not intend |
Ուղու կանոնները ամենաճշգրիտ և ամենափխրունն են։ Գործարկիչի թարմացումը, որը տեղափոխում է գործարկվող ֆայլը, կանոնը թողնում է ցույց տալու այլևս չաշխատող ֆայլի, և ախտանիշը վերադառնում է առանց որևէ ակնհայտ փոփոխության։ Փաթեթի կանոնները դրան դիմանում են, և կարող են նաև լուռ ծածկել օժանդակ գործընթացներ, որոնց մասին երբեք չեք մտածել, ինչը հարմար է կամ անհանգստացնող՝ կախված օժանդակից։
Ինչ էլ աջակցի հաճախորդը, մի ավելացրեք գրառումներ յուրաքանչյուր գտած գործարկվող ֆայլի համար։ Փորձի և սխալի միջոցով հավաքված ցանկը, մինչև մեկ նստաշրջան աշխատեց, վերանայելի չէ, և լուռ կկուտակի բացառություններ անկապ ծրագրերի համար։ Անվանեք ձեր գտած գործընթացը և գրեք, թե ինչի համար էր։
Ստուգեք խաղի վրա, ոչ թե ներբեռնման վրա
Գործարկիչի ներբեռնման արագությունը հնարավոր ամենավատ ստուգումն է, որովհետև այն աշխատեցնում է հենց այն գործընթացը, որն արդեն բացառված էր։ Օգտագործեք այն, ինչը ձախողվում էր, և ստուգեք ուղին, այլ ոչ թե խաղի սեփական աշխատանքի ցուցիչը՝
ip route get 203.0.113.55
Get-NetTCPConnection -State Established | Where-Object RemotePort -eq 27015
Առաջին հրամանին պետք է այն հասցեն, որին լուծվել է խաղի սերվերը, որը կարող է տալ խաղի կապի մատյանը կամ ձեր հաճախորդը։ Եթե երթուղին անվանում է ֆիզիկական ինտերֆեյսը, կանոնն աշխատում է։ Երկրորդը ցույց է տալիս՝ ընդհանրապես նստաշրջան կա արդյոք, ինչը տարանջատում է «բացառված է, բայց սերվերը անջատված է» և «բացառված չէ» վիճակները։
Փորձարկման ընթացքում տարածաշրջանը և մուտքի ցանցը պահեք անփոփոխ։ Խաղը, որը յուրաքանչյուր փորձի ժամանակ տարբեր տվյալների կենտրոնում է վայրէջք կատարում, տարբեր հասցեներ է առաջացնում, և դուք ի վերջո կհետապնդեք շարժվող թիրախի՝ կանոնը վավերացնելու փոխարեն։ Նույն հասցեով երկու գործարկումն ավելի արժեքավոր է, քան տարբեր հասցեներով տասը։
Նորից ստուգեք հաջորդ թարմացումից հետո
Ուղու վրա հիմնված ցանկացած կանոն ունի շերտերի ցիկլերով չափվող պահպանման ժամկետ։ Երբ խաղը մեկ ամիս անց դադարի հարգել բացառությունը, առաջինը ստուգեք՝ արդյոք գործարկվող ֆայլը տեղափոխվել է, և երկրորդը՝ արդյոք կողքին հայտնվել է նոր օժանդակ գործընթաց։
Մեկ հաճախորդի կողմից փաստաթղթավորված հավելվածների բացառման մոդելը ողջամիտ հղում է այն բանի, թե ինչպես են նկարագրում այս կանոնները, թեև մանրամասները տարբերվում են ապրանքների միջև։ Կարդացեք ձերը, գրանցեք օգտագործած նույնացուցիչը և նշեք ամսաթիվը։ Այդ գրառումն է, որ հաջորդ անգամ գործարկիչի թարմացում ուղարկելիս առեղծվածը դարձնում է հինգ րոպեանոց ուղղում։
Եթե հաճախորդը պարզապես չի կարող արտահայտել ձեզ անհրաժեշտ սահմանը, հաստատված ավելի լայն քաղաքականությունն ավելի լավ է, քան չհաստատված բացառությունների կույտը։ Լայն և հասկանալին հաղթում է նեղ և սխալին, հատկապես երբ նեղ տարբերակն այն է, ինչ բոլորը հավատում են, թե ուժի մեջ է։