इज़राइल और मध्य पूर्व के कुछ देशों में सामने आई प्रमुख P2P समस्या

• मौजूदा स्थिति Open है, और ValveSoftware के एक सदस्य के अनुसार इस मामले का उपयोग यह जांचने के लिए किया जा सकता है कि SDR इस्तेमाल करने वाले पार्टनर्स के साथ "Share IP Address" का पालन क्यों नहीं हो रहा है
• लगभग 13 मार्च 2026 से Steam Networking इस्तेमाल करने वाले P2P गेम्स में समस्या सामने आई, और रिपोर्ट के अनुसार Street Fighter 6 में इज़राइल के PC-to-PC मैच लगभग 120ms थे, यूरोपीय खिलाड़ियों के साथ मैच 60~80ms, जबकि PC-to-PS5 मैच 5~10ms थे
• इज़राइली समुदाय के दर्जनों लोगों ने कई ISP पर यही समस्या झेली, और ISP से संपर्क करने व port forwarding करने के बाद भी कोई नेटवर्क समस्या नहीं मिली; वहीं Steam Networking का इस्तेमाल न करने वाले Tekken 8 में ऐसी समस्या नहीं थी
• चीनी खिलाड़ियों ने भी Warhammer: Vermintide 2 में रिपोर्ट किया कि दोनों तरफ "Share IP Address" चालू होने के बावजूद सीधा P2P connection स्थापित नहीं हो रहा था, और सभी खिलाड़ी डेटा Steam के SDR relay से गुजरने के कारण latency बहुत बढ़ गई
• अतिरिक्त पुनरुत्पादन में पाया गया कि SDR सर्वर ट्रैफिक को ब्लॉक करके सीधे P2P connection को मजबूर करने की कोशिश करने पर online match शुरू ही नहीं होता
• एक अस्थायी workaround यह है कि steamwebrtc64.dll को Steam installation directory से गेम फ़ोल्डर के Binaries, Binaries/Win64, Binaries_dx12 में से किसी एक में कॉपी किया जाए, और यदि दोनों खिलाड़ी इसे लागू करें तो "NAT traversal successful, IP shared" दिखाई देता है और P2P connection बहाल हो जाता है
• यह workaround Deep Rock Galactic, Warhammer: Vermintide 2, और Far Far West में काम करता पाया गया, और बाद में Street Fighter 6 तथा Melty Blood में भी इसके लागू होने के उदाहरण जोड़े गए
• Melty Blood में steam_api.dll इस्तेमाल होने के कारण steamwebrtc64.dll की जगह steamwebrtc.dll का उपयोग करना पड़ा, और यदि Binaries फ़ोल्डर न हो तो इसे steam_api64.dll वाले उसी फ़ोल्डर में रखा गया
• एक उपयोगकर्ता ने संक्षेप में कहा कि पुराना Steam client STUN के जरिए सीधा P2P सेट करता है, लेकिन नया client किसी कारण से ऐसा प्रयास नहीं करता; हालांकि सटीक बदलाव क्या है, यह अभी स्पष्ट नहीं है

[GN⁺]

Hacker News की राय

• यहाँ ऐसा कम और लगता है कि Valve ने चीज़ें बिगाड़ीं, बल्कि मध्य पूर्व का संघर्ष cyberspace तक फैल गया है और उसका असर आम users तक पहुँच गया है
  timing और प्रभावित देशों को देखें तो यही लगता है, और China भी free internet के लिए मशहूर जगह नहीं है
  WebRTC fallback path की तरह काम करता है, encrypted है, और इसका किसी दूसरे काम में दुरुपयोग करना भी आसान नहीं है
  इसके उलट STUN encrypted नहीं है, और protocol खुद DDoS reflection/amplification में इस्तेमाल हो सकता है, इसलिए इसका weaponize हो जाना या real-time blocking/analysis के दौरान connectivity टूट जाना कोई हैरानी की बात नहीं होगी

  • WebRTC में STUN/TURN लगभग icanhazip जैसी भूमिका निभाते हैं
    STUN public IP:port बताता है, और TURN भी कुछ ऐसा ही करता है, लेकिन actual address की जगह query के समय dynamically assigned IP:port लौटाता है
    WebRTC client उस STUN/TURN response को lobby server chat जैसे out-of-band signaling path से peer को भेजकर connection सेट करता है, और दोनों तरफ NAT table में ऐसे entry बनवा सकता है मानो वह बाहर जाने वाला connection हो
    सिर्फ STUN/TURN से P2P connection नहीं बनाया जा सकता; वे सिर्फ WebRTC के लिए ज़रूरी tools हैं
  • मैंने WebRTC के ऊपर WireGuard जैसी P2P VPN बनाई थी, और performance 300Mbps से ऊपर अच्छी थी
    end user को firewall issues या IPv4/IPv6 के फर्क की चिंता नहीं करनी पड़ती, इसलिए IP-based solution की जगह real-time P2P games या enterprise networking जैसी चीज़ों के लिए WebRTC को ढाला जा सकता है
  • लगता है बात उलटी समझी गई है। WebRTC काम नहीं कर रहा और STUN काम कर रहा है
  • हमारा networking software भी P2P करता है, इसलिए हम STUN, TURN जैसे सामान्य तरीकों की जगह सब कुछ in-band processing से implement करते हैं
    ऐसे तरीके block भी हो जाते हैं और security भी कई बार कमज़ोर होती है
    STUN में अब weaponization mitigation है, लेकिन फिर भी यह खराब protocol है, और समझ नहीं आता कि STUN या TURN किसी में भी अलग signaling path के बिना rendezvous करने का कोई तरीका क्यों नहीं है। यह आसानी से जोड़ा जा सकता था
  • IPv6 और assembly में minimal implementation वाला network code, बिना niche और complex features के, काफ़ी है

• यह तो सबको पहले से पता होगा, लेकिन open source या source-available libraries और applications की सबसे अच्छी बात यही bug reports और PR discussions हैं
  अलग-अलग लोग अपने symptoms, workarounds और root-cause hypotheses जोड़ते जाते हैं, यह देखना सच में अच्छा लगता है

  • GitHub discussions की quality भी तब बहुत ऊँची हुआ करती थी, जब platform ज़्यादातर experts के इस्तेमाल का था
    आजकल कई discussions practically reddit/4chan threads जैसी लगती हैं, इसलिए वहाँ से हटने का एक और कारण मिल गया

• यह शीर्षक GitHub issue के मूल शीर्षक "Major P2P issues in Israel and possibly other middle east countries" से मेल नहीं खाता

• यह HN-शैली की थोड़ी rough speculation है, लेकिन GitHub issue को आखिर तक पढ़ें तो users STUN failure report कर रहे हैं
  यानी P2P link बन नहीं रही और उसकी जगह high-latency relay server इस्तेमाल हो रहा है
  कई users ने पुरानी Valve WebRTC dll को manually बदलकर समस्या से बचाव किया, और Valve developers का postmortem analysis पढ़ना अच्छा लगेगा

• शीर्षक से "in Israel and possibly other middle east countries" वाला हिस्सा क्यों हटाया गया? clickbait है क्या?

  • या फिर यह सोचकर कि दुनिया में पहले से ही काफ़ी Israel/Palestine बहस threads हैं, और इसे एक और flamewar बनने से रोकना था
  • अगर आप यहाँ काफ़ी समय से हैं, तो आपको पता होगा कि वह हिस्सा जोड़ने पर title character limit पार हो जाती

• यह वाकई एक बेदम submission है, फिर भी इसे इतने upvotes मिले, यह हैरानी की बात है
  लगता है लोगों ने शीर्षक में Valve देखकर इसे अहम समझ लिया, लेकिन असली issue की सामग्री शीर्षक से मेल भी नहीं खाती

• शुरुआत Israel और कुछ मध्य पूर्वी देशों की बड़ी P2P समस्या के रूप में हुई थी, लेकिन आगे की जाँच से यह वैश्विक समस्या जैसी लगने लगी

  • अभी तक का यह "वैश्विक" दायरा Israel, Russia और China तक ही है
    ये सभी ऐसे देश हैं जिन्हें internet freedom से खास लगाव नहीं है और जहाँ surveillance व censorship का लंबा इतिहास है, इसलिए यह censorship-ISP bypass को कठिन बनाने वाली P2P network policy का side effect हो सकता है

• यह Valve की समस्या नहीं लगती
  reported issues शायद सिर्फ उन्हीं देशों में दिख रही हैं जहाँ connections को बहुत आक्रामक तरीके से scan और filter किया जाता है, और P2P ऐसे हस्तक्षेप के प्रति संवेदनशील होता है
  SDR एक encrypted relay network है, जो onion routing जैसी चीज़ों से मिलता-जुलता है
  यह अच्छी तरह जाना जाता है कि कोई malicious actor P2P game distribute करके उसी game के ज़रिए SDR पर communication चला सकता है
  इसलिए यह मानना आसान है कि ऐसे इलाकों में लोग उस traffic की जाँच करना चाहेंगे

• मैं China में हूँ; करीब 3 हफ़्ते पहले Steam के Spacewar developer game के ज़रिए third-party game खेला था, शायद Steam P2P enabled था, और वह ठीक से काम कर रहा था

• सिर्फ शीर्षक पढ़कर लगता है जैसे हर जगह सब टूटा हुआ है