ਤੁਹਾਡਾ ਸਪਲਿਟ ਟਨਲ ਲਾਂਚਰ ਨੂੰ ਬਾਹਰ ਰੱਖਦਾ ਹੈ, ਗੇਮ ਨੂੰ ਨਹੀਂ
ਲਾਂਚਰ ਮੈਚ ਲਈ ਦੂਜੀ ਐਗਜ਼ੀਕਿਊਟੇਬਲ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ, ਅਤੇ ਉਸ ਪ੍ਰਕਿਰਿਆ ਦੇ ਆਪਣੇ ਸਾਕਟ ਹੁੰਦੇ ਹਨ। ਅਸਲ ਪ੍ਰਕਿਰਿਆ ਲੱਭੋ, ਸਹੀ ਪਛਾਣਕਰਤਾ ਮਿਲਾਓ, ਫਿਰ ਜਾਂਚ ਕਰੋ।
ਤੁਸੀਂ ਲਾਂਚਰ ਨੂੰ ਬਾਹਰ ਰੱਖਣ ਵਾਲੀ ਸੂਚੀ ਵਿੱਚ ਪਾਉਂਦੇ ਹੋ, ਡਾਊਨਲੋਡ ਹੌਲੀ ਤੋਂ ਤੇਜ਼ ਹੋ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਮੈਚ ਫਿਰ ਵੀ ਦੂਰ ਦੇ ਸਰਵਰ ਉੱਤੇ ਉਤਰਦਾ ਹੈ। ਕੁਝ ਵੀ ਟੁੱਟਿਆ ਨਹੀਂ। ਲਾਂਚਰ ਅਤੇ ਗੇਮ ਦੋ ਪ੍ਰਕਿਰਿਆਵਾਂ ਹਨ ਜਿਨ੍ਹਾਂ ਦੇ ਸਾਕਟ ਦੇ ਦੋ ਸੈੱਟ ਹਨ, ਅਤੇ ਇੱਕ ਨੂੰ ਬਾਹਰ ਰੱਖਣਾ ਦੂਜੇ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦਾ। ਡਾਊਨਲੋਡ ਤੇਜ਼ ਹੋਇਆ ਕਿਉਂਕਿ ਡਾਊਨਲੋਡ ਲਾਂਚਰ ਦਾ ਟ੍ਰੈਫਿਕ ਸੀ; ਮੈਚ ਕਿਸੇ ਹੋਰ ਦਾ ਕਨੈਕਸ਼ਨ ਹੈ, ਜੋ ਤੁਹਾਡੇ ਨਿਯਮ ਨੇ ਕਦੇ ਨਾ ਵੇਖੀ ਐਗਜ਼ੀਕਿਊਟੇਬਲ ਨੇ ਖੋਲ੍ਹਿਆ।
ਇੱਕ ਇੰਸਟਾਲਰ, ਕਈ ਪ੍ਰਕਿਰਿਆਵਾਂ
ਆਧੁਨਿਕ ਗੇਮ ਸਾਫਟਵੇਅਰ ਇੱਕ ਛੋਟਾ ਤਾਰਾਮੰਡਲ ਹੈ। ਇੱਕ ਕਲਾਇੰਟ ਹੈ ਜੋ ਤੁਹਾਨੂੰ ਸਾਈਨ ਇਨ ਕਰਾਉਂਦਾ ਹੈ, ਇੱਕ ਅਪਡੇਟਰ ਜੋ ਸਮੱਗਰੀ ਖਿੱਚਦਾ ਹੈ, ਇੱਕ ਲਾਂਚਰ ਜੋ ਗੇਮ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ, ਅਤੇ ਗੇਮ ਦੀ ਐਗਜ਼ੀਕਿਊਟੇਬਲ ਫਾਈਲ ਜੋ ਖੁਦ ਐਂਟੀ-ਚੀਟ ਜਾਂ ਮੈਚ ਮਿਲਾਣ ਪਰਤ ਲਈ ਦੂਜੀ ਪ੍ਰਕਿਰਿਆ ਬਣਾ ਸਕਦੀ ਹੈ। ਇਹਨਾਂ ਵਿੱਚੋਂ ਹਰ ਇੱਕ ਆਪਣੇ ਟਿਕਾਣਿਆਂ ਲਈ ਆਪਣੇ ਕਨੈਕਸ਼ਨ ਰੱਖ ਸਕਦਾ ਹੈ।
ਬਾਹਰ ਰੱਖਣ ਦਾ ਨਿਯਮ ਆਮ ਤੌਰ ਉੱਤੇ ਇਹਨਾਂ ਵਿੱਚੋਂ ਇੱਕ ਦਾ ਨਾਮ ਲੈਂਦਾ ਹੈ। ਕਿਸ ਦਾ ਨਾਮ ਲੈਂਦਾ ਹੈ ਇਹ ਪੂਰੀ ਤਰ੍ਹਾਂ VPN ਕਲਾਇੰਟ ਦੁਆਰਾ ਸਮਰਥਿਤ ਪਛਾਣਕਰਤਾ ਉੱਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ, ਅਤੇ ਇਹੀ ਉਹ ਹਿੱਸਾ ਹੈ ਜਿਸਨੂੰ ਵਰਤੋਂਕਾਰ ਘੱਟ ਹੀ ਜਾਂਚਦੇ ਹਨ। ਕੁਝ ਕਲਾਇੰਟ ਐਗਜ਼ੀਕਿਊਟੇਬਲ ਪਾਥ ਮਿਲਾਉਂਦੇ ਹਨ, ਕੁਝ ਬੰਡਲ ਜਾਂ ਪੈਕੇਜ ਪਛਾਣਕਰਤਾ, ਅਤੇ ਕੁਝ ਪ੍ਰਕਿਰਿਆ ਦਾ ਨਾਮ ਜੋ ਦੋ ਅਸੰਬੰਧਿਤ ਬਾਈਨਰੀ ਸਾਂਝਾ ਕਰ ਸਕਦੇ ਹਨ। ਪ੍ਰਕਿਰਿਆ ਸੂਚੀ ਤੋਂ ਪਹਿਲਾਂ ਨਿਯਮ ਪੜ੍ਹੋ, ਕਿਉਂਕਿ ਨਿਯਮ ਇਹ ਵੀ ਸੀਮਿਤ ਕਰਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਕੀ ਦੱਸ ਸਕਦੇ ਹੋ।
ਇਸ ਲਈ ਲੱਛਣ “ਸਪਲਿਟ ਟਨਲ ਟੁੱਟਿਆ ਹੈ” ਨਹੀਂ ਹੈ। ਇਹ “ਨਿਯਮ ਉਸ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਕਵਰ ਕਰਦਾ ਹੈ ਜੋ ਮੇਰੇ ਲਈ ਮਹੱਤਵਪੂਰਨ ਟ੍ਰੈਫਿਕ ਲਿਜਾਣ ਵਾਲੀ ਪ੍ਰਕਿਰਿਆ ਨਹੀਂ”, ਜੋ ਬਹੁਤ ਸੰਕੀਰਣ ਅਤੇ ਬਹੁਤ ਜ਼ਿਆਦਾ ਠੀਕ ਕਰਨ ਯੋਗ ਬਿਆਨ ਹੈ। ਇੱਕ ਵਾਰ ਇਸ ਤਰ੍ਹਾਂ ਕਹੋ, ਅਗਲਾ ਕਦਮ ਅੰਦਾਜ਼ਾ ਰਹਿੰਦਾ ਨਹੀਂ।
ਮੈਚ ਕਨੈਕਸ਼ਨ ਵਾਲੀ ਪ੍ਰਕਿਰਿਆ ਲੱਭੋ
ਗੇਮ ਸ਼ੁਰੂ ਕਰੋ, ਮੈਚ ਵਿੱਚ ਜਾਓ, ਅਤੇ ਸਕ੍ਰੀਨ ਉੱਤੇ ਕੀ ਹੈ ਦੀ ਬਜਾਏ ਸਾਕਟ ਕਿਸ ਕੋਲ ਹਨ ਵੇਖੋ। 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/'ਜੇ ਗੇਮ ਕੰਟੇਨਰ ਜਾਂ ਅਨੁਕੂਲਤਾ ਪਰਤ ਵਿੱਚ ਚੱਲਦੀ ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ ਮਿਲਣ ਵਾਲੀ ਪ੍ਰਕਿਰਿਆ ਤੁਹਾਡੇ ਵੱਲੋਂ ਸਥਾਪਿਤ ਬਾਈਨਰੀ ਨਹੀਂ, ਸ਼ਿਮ ਹੋ ਸਕਦੀ ਹੈ। ਉਸ ਸਥਿਤੀ ਵਿੱਚ ਮਹੱਤਵਪੂਰਨ ਪਛਾਣਕਰਤਾ ਉਹ ਹੈ ਜੋ ਕਲਾਇੰਟ ਵੇਖਦਾ ਹੈ, ਜੋ ਸ਼ਿਮ ਦਾ ਪਾਥ ਹੋ ਸਕਦਾ ਹੈ, ਅਤੇ ਮੂਲ ਫਾਈਲ ਵਿੱਚ ਕਿੰਨਾ ਵੀ ਸੰਪਾਦਨ ਕਰੋ ਇਸ ਉੱਤੇ ਅਸਰ ਨਹੀਂ ਪਵੇਗਾ।
ਉਹ ਪਛਾਣਕਰਤਾ ਮਿਲਾਓ ਜੋ ਤੁਹਾਡਾ ਕਲਾਇੰਟ ਸਮਰਥਨ ਕਰਦਾ ਹੈ
ਕੁਝ ਵੀ ਜੋੜਨ ਤੋਂ ਪਹਿਲਾਂ ਬਾਹਰ ਰੱਖਣ ਦੇ ਨਿਯਮ ਲਈ ਕਲਾਇੰਟ ਦਾ ਦਸਤਾਵੇਜ਼ ਪੜ੍ਹੋ। ਤਿੰਨ ਆਮ ਮਾਡਲ ਵੱਖਰੇ ਤਰੀਕੇ ਨਾਲ ਵਿਵਹਾਰ ਕਰਦੇ ਹਨ, ਅਤੇ ਉਹਨਾਂ ਵਿੱਚੋਂ ਇੱਕ ਜਾਲ ਹੈ।
| 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ਪਹਿਲੀ ਕਮਾਂਡ ਨੂੰ ਉਹ ਪਤਾ ਚਾਹੀਦਾ ਹੈ ਜਿਸ ਉੱਤੇ ਮੈਚ ਸਰਵਰ ਹੱਲ ਹੋਇਆ, ਜੋ ਗੇਮ ਦਾ ਕਨੈਕਸ਼ਨ ਲੌਗ ਜਾਂ ਤੁਹਾਡਾ ਕਲਾਇੰਟ ਦੇ ਸਕਦਾ ਹੈ। ਜੇ ਪਾਥ ਭੌਤਿਕ ਇੰਟਰਫੇਸ ਦਾ ਨਾਮ ਲੈਂਦਾ ਹੈ, ਨਿਯਮ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ। ਦੂਜੀ ਦਿਖਾਉਂਦੀ ਹੈ ਕਿ ਸੈਸ਼ਨ ਹੈ ਵੀ ਜਾਂ ਨਹੀਂ, ਜੋ “ਬਾਹਰ ਰੱਖਿਆ ਪਰ ਸਰਵਰ ਬੰਦ” ਅਤੇ “ਬਾਹਰ ਨਹੀਂ ਰੱਖਿਆ” ਵਿੱਚ ਫਰਕ ਕਰਦੀ ਹੈ।
ਜਾਂਚ ਦੌਰਾਨ ਖੇਤਰ ਅਤੇ ਪਹੁੰਚ ਨੈੱਟਵਰਕ ਸਥਿਰ ਰੱਖੋ। ਜੋ ਮੈਚ ਹਰ ਕੋਸ਼ਿਸ਼ ਵਿੱਚ ਵੱਖਰੇ ਡਾਟਾ ਸੈਂਟਰ ਵਿੱਚ ਉਤਰਦਾ ਹੈ ਉਹ ਵੱਖਰੇ ਪਤੇ ਬਣਾਉਂਦਾ ਹੈ, ਅਤੇ ਤੁਸੀਂ ਨਿਯਮ ਦੀ ਪੁਸ਼ਟੀ ਕਰਨ ਦੀ ਬਜਾਏ ਹਿਲਦੇ ਟਾਰਗੇਟ ਦਾ ਪਿੱਛਾ ਕਰੋਗੇ। ਇੱਕੋ ਪਤੇ ਨਾਲ ਦੋ ਰਨ ਵੱਖਰੇ ਪਤਿਆਂ ਨਾਲ ਦਸ ਤੋਂ ਵੱਧ ਕੀਮਤੀ ਹਨ।
ਅਗਲੇ ਅਪਡੇਟ ਤੋਂ ਬਾਅਦ ਦੁਬਾਰਾ ਜਾਂਚੋ
ਪਾਥ-ਆਧਾਰਿਤ ਕਿਸੇ ਵੀ ਨਿਯਮ ਦੀ ਪੈਚ ਚੱਕਰਾਂ ਵਿੱਚ ਮਾਪੀ ਉਮਰ ਹੁੰਦੀ ਹੈ। ਜਦੋਂ ਗੇਮ ਇੱਕ ਮਹੀਨੇ ਬਾਅਦ ਬਾਹਰ ਰੱਖਣ ਦਾ ਸਤਿਕਾਰ ਕਰਨਾ ਬੰਦ ਕਰ ਦਿੰਦੀ ਹੈ, ਪਹਿਲਾਂ ਜਾਂਚੋ ਕਿ ਐਗਜ਼ੀਕਿਊਟੇਬਲ ਹਿਲਿਆ ਹੈ ਜਾਂ ਨਹੀਂ, ਅਤੇ ਦੂਜਾ ਕਿ ਇਸਦੇ ਕੋਲ ਨਵੀਂ ਸਹਾਇਕ ਪ੍ਰਕਿਰਿਆ ਆਈ ਹੈ ਜਾਂ ਨਹੀਂ।
ਇੱਕ ਕਲਾਇੰਟ ਵੱਲੋਂ ਦਸਤਾਵੇਜ਼ਬੱਧ ਐਪਲੀਕੇਸ਼ਨ ਬਾਹਰ ਰੱਖਣ ਮਾਡਲ ਇਹਨਾਂ ਨਿਯਮਾਂ ਦੇ ਵਰਣਨ ਲਈ ਵਾਜਬ ਸੰਦਰਭ ਹੈ, ਹਾਲਾਂਕਿ ਵੇਰਵੇ ਉਤਪਾਦਾਂ ਵਿੱਚ ਵੱਖਰੇ ਹੁੰਦੇ ਹਨ। ਆਪਣਾ ਪੜ੍ਹੋ, ਵਰਤਿਆ ਪਛਾਣਕਰਤਾ ਦਰਜ ਕਰੋ, ਅਤੇ ਤਾਰੀਖ਼ ਲਿਖੋ। ਉਹੀ ਰਿਕਾਰਡ ਅਗਲੀ ਵਾਰ ਲਾਂਚਰ ਵੱਲੋਂ ਅਪਡੇਟ ਭੇਜਣ ’ਤੇ ਇੱਕ ਰਹੱਸ ਨੂੰ ਪੰਜ ਮਿੰਟ ਦੀ ਮੁਰੰਮਤ ਵਿੱਚ ਬਦਲਦਾ ਹੈ।
ਜੇ ਕਲਾਇੰਟ ਲੋੜੀਂਦੀ ਸੀਮਾ ਦੱਸ ਹੀ ਨਹੀਂ ਸਕਦਾ, ਤਾਂ ਮਨਜ਼ੂਰ ਵਿਆਪਕ ਨੀਤੀ ਅਦਸਤਾਵੇਜ਼ੀ ਅਪਵਾਦਾਂ ਦੇ ਢੇਰ ਤੋਂ ਬਿਹਤਰ ਹੈ। ਵਿਆਪਕ ਅਤੇ ਸਮਝਿਆ ਗਿਆ ਸੰਕੀਰਣ ਅਤੇ ਗਲਤ ਨੂੰ ਹਰਾਉਂਦਾ ਹੈ, ਖਾਸ ਕਰਕੇ ਜਦੋਂ ਸੰਕੀਰਣ ਸੰਸਕਰਣ ਹੀ ਉਹ ਹੈ ਜੋ ਸਾਰੇ ਲਾਗੂ ਹੋਣਾ ਮੰਨਦੇ ਹਨ।