თქვენ გამშვებს გამორიცხვების სიას უმატებთ, ჩამოტვირთვა ნელიდან სწრაფზე გადადის და მატჩი მაინც შორეულ სერვერზე ხვდება. არაფერი არ არის გატეხილი. გამშვები და თამაში ორი პროცესია ორი სოკეტების ნაკრებით და ერთის გამორიცხვა მეორეზე არაფერს ამბობს. ჩამოტვირთვა დაჩქარდა, რადგან ჩამოტვირთვა გამშვების ტრაფიკი იყო; მატჩი სხვისი კავშირია, რომელიც გახსნა შესრულებადმა ფაილმა, რომელიც თქვენს წესს არასდროს უნახავს.

ერთი ინსტალერი, ბევრი პროცესი

თანამედროვე თამაშური პროგრამა პატარა თანავარსკვლავედია. არის კლიენტი, რომელიც შეგიყვანთ, განახლება, რომელიც კონტენტს იწერს, გამშვები, რომელიც თამაშს იწყებს და თამაშის შესრულებადი ფაილი, რომელმაც შეიძლება თავად შექმნას მეორე პროცესი ანტიჩიტის ან მატჩების შესაბამისობის ფენისთვის. თითოეულ მათგანს შეუძლია საკუთარი კავშირები შეინახოს საკუთარ დანიშნულებებთან.

გამორიცხვის წესი ჩვეულებრივ ერთ მათგანს ასახელებს. რომელს ასახელებს, სრულიად დამოკიდებულია იდენტიფიკატორზე, რომელსაც 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

პირველ ბრძანებას სჭირდება მისამართი, რომელზეც მატჩის სერვერი გადაწყდა, რომელსაც თამაშის კავშირის ჟურნალი ან თქვენი კლიენტი მოგცემთ. თუ მარშრუტი ფიზიკურ ინტერფეისს ასახელებს, წესი მუშაობს. მეორე გვიჩვენებს, საერთოდ არსებობს თუ არა სესია, რაც გამოყოფს „გამორიცხულია, მაგრამ სერვერი გამორთულია“ მდგომარეობას „არ არის გამორიცხული“ მდგომარეობისგან.

ტესტირებისას რეგიონი და წვდომის ქსელი უცვლელად შეინახეთ. მატჩი, რომელიც ყოველ ცდაზე სხვა მონაცემთა ცენტრში ხვდება, სხვადასხვა მისამართს ქმნის და საბოლოოდ მოძრავ სამიზნეს დაედევნებით წესის გადამოწმების ნაცვლად. ერთი და იმავე მისამართით ორი გაშვება უფრო ღირებულია, ვიდრე ათი განსხვავებულით.

შემდეგი განახლების შემდეგ ხელახლა შეამოწმეთ

გზაზე დაფუძნებულ ნებისმიერ წესს აქვს პაჩის ციკლებით გაზომილი ვადა. როდესაც თამაში ერთი თვის შემდეგ შეწყვეტს გამორიცხვის პატივისცემას, პირველი, რაც უნდა შეამოწმოთ, არის თუ არა შესრულებადი ფაილი გადაადგილებული, და მეორე, გამოჩნდა თუ არა მის გვერდით ახალი დამხმარე პროცესი.

ერთი კლიენტის მიერ დოკუმენტირებული აპლიკაციების გამორიცხვის მოდელი გონივრული ცნობარია იმისთვის, თუ როგორ აღწერენ ამ წესებს, თუმცა დეტალები პროდუქტებს შორის განსხვავდება. წაიკითხეთ თქვენი, ჩაწერეთ გამოყენებული იდენტიფიკატორი და მონიშნეთ თარიღი. სწორედ ეს ჩანაწერი აქცევს საიდუმლოს ხუთწუთიან შესწორებად შემდეგ ჯერზე, როცა გამშვები განახლებას გამოუშვებს.

თუ კლიენტი უბრალოდ ვერ გამოხატავს იმ საზღვარს, რომელიც გჭირდებათ, დამტკიცებული უფრო ფართო პოლიტიკა სჯობს დაუდოკუმენტებული გამონაკლისების გროვას. ფართო და გასაგები სჯობს ვიწრო და არასწორს, განსაკუთრებით მაშინ, როცა ვიწრო ვერსია არის ის, რაც ყველას სჯერა, რომ ძალაშია.

დაკავშირებული სტატიები