İsrail ve Orta Doğu'daki bazı ülkelerde ortaya çıkan büyük P2P sorunu

 (github.com/ValveSoftware)
1 puan yazan GN⁺ 4 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • Mevcut durum Open ve ValveSoftware üyeleri, SDR kullanan partnerlerle birlikte "Share IP Address" ayarına neden uyulmadığını araştırmak için bu vakayı kullanabileceklerini belirtiyor
  • Yaklaşık 13 Mart 2026'dan itibaren Steam Networking kullanan P2P oyunlarda sorunlar görülmeye başlandı; Street Fighter 6'da İsrail'deki PC-to-PC maçların yaklaşık 120ms, Avrupalı oyuncularla maçların 60~80ms, PC-to-PS5 maçların ise 5~10ms olduğu bildirildi
  • İsrail topluluğundan onlarca kişi, birden fazla ISP'de aynı sorunu yaşadıklarını; ISP ile görüşme ve port forwarding sonrasında da ağ kaynaklı bir sorun bulamadıklarını; Steam Networking kullanmayan Tekken 8'de ise sorun olmadığını bildirdi
  • Çinli oyuncular da Warhammer: Vermintide 2'de her iki taraf da "Share IP Address" seçeneğini açsa bile doğrudan P2P bağlantısının kurulmadığını ve tüm oyuncu verisinin Steam'in SDR relay'i üzerinden geçtiği için gecikmenin ciddi biçimde arttığını bildirdi
  • SDR sunucu trafiğini engelleyip doğrudan P2P bağlantısını zorlamaya çalışıldığında çevrim içi maçın başlamadığına dair ek yeniden üretim raporu da paylaşıldı
  • Geçici geçici çözüm olarak steamwebrtc64.dll dosyasını Steam kurulum dizininden oyunun Binaries, Binaries/Win64, Binaries_dx12 klasörlerinden birine kopyalayıp her iki oyuncu da bunu uyguladığında "NAT traversal successful, IP shared" mesajının göründüğü ve P2P bağlantısının geri geldiği aktarıldı
  • Bu geçici çözümün Deep Rock Galactic, Warhammer: Vermintide 2 ve Far Far West'te çalıştığı paylaşıldı; daha sonra Street Fighter 6 ve Melty Blood için de uygulama örnekleri eklendi
  • Melty Blood'da steam_api.dll kullanıldığı için steamwebrtc64.dll yerine steamwebrtc.dll kullanılması gerektiği; Binaries klasörü yoksa dosyanın steam_api64.dll ile aynı klasöre yerleştirildiği not edildi
  • Bir kullanıcı, eski Steam istemcisinin STUN ile doğrudan P2P kurduğunu ancak yeni istemcinin bilinmeyen bir nedenle bunu denemediğini özetledi; tam olarak hangi değişikliğin buna yol açtığı ise bilinmiyor

İlgili okumalar

1 yorum

 
GN⁺ 4 시간 전
Hacker News görüşleri

  • Burada mesele Valve'in bir şeyi bozmasından çok, Orta Doğu’daki çatışmanın siber uzaya taşınıp sivil kullanıcıları da etkilemeye başlaması gibi görünüyor
    Zamanlama ve etkilenen ülkelere bakınca öyle duruyor; Çin de zaten özgür internetiyle bilinen bir yer değil
    WebRTC yedek yol olarak çalışıyor, şifreli ve başka amaçlarla kötüye kullanılması da zor
    Buna karşılık STUN şifreli değil ve protokolün kendisi DDoS yansıma/yükseltme için kullanılabildiğinden, silahlaştırılmış olması ya da gerçek zamanlı engelleme/analiz sırasında bağlantının bozulması da şaşırtıcı olmaz

    • STUN/TURN, WebRTC’de neredeyse icanhazip gibi bir rol oynuyor
      STUN herkese açık IP:port bilgisini veriyor; TURN da benzer ama gerçek adres yerine sorgu anında dinamik olarak atanmış bir IP:port döndürüyor
      WebRTC istemcisi bağlantıyı kurmak için bu STUN/TURN yanıtını lobi sunucusu sohbeti gibi bant dışı sinyal yoluyla eşe gönderiyor ve böylece her iki taraftaki NAT tablolarında sanki dışarı giden bir bağlantıymış gibi kayıt oluşturulabiliyor
      Sadece STUN/TURN ile P2P bağlantı kurulamaz; bunlar yalnızca WebRTC için gerekli araçlardır
    • WebRTC üzerinde WireGuard benzeri bir P2P VPN yapmıştım ve performans 300Mbps’nin üzerinde, gayet iyiydi
      Son kullanıcıların güvenlik duvarı sorunlarıyla ya da IPv4/IPv6 farklarıyla uğraşmak zorunda kalmaması sayesinde, IP tabanlı çözümler yerine WebRTC’nin gerçek zamanlı P2P oyunlar veya kurumsal ağ iletişimi gibi alanlara uyarlanabileceğini düşünüyorum
    • Sanırım ters anlamışsınız. WebRTC çalışmıyor ama STUN çalışıyor
    • Bizim ağ yazılımımız da P2P yapıyor; bu yüzden STUN, TURN gibi genel yöntemler yerine her şeyi tamamen bant içi işleme ile uyguluyoruz
      Bu tür yöntemler engellenebiliyor ve güvenlik açısından da çoğu zaman zayıf oluyor
      STUN için artık silahlaştırmayı azaltıcı önlemler var ama yine de berbat bir protokol ve gerek STUN’da gerek TURN’de ayrı bir sinyal yolu olmadan rendezvous yapmanın hiçbir yolunun bulunmamasını anlamıyorum. Kolayca eklenebilirdi
    • IPv6 ve niş, karmaşık özellikler olmadan assembly ile en minimal ağ kodu yeterli

  • Herkesin zaten bildiği bir şey olabilir ama, açık kaynak ya da kaynak kodu açık kütüphane ve uygulamalardaki en iyi şeylerden biri bu tür hata raporları ve PR tartışmaları
    Farklı insanların kendi semptomlarını, geçici çözümlerini ve neden hipotezlerini bir araya getirmesini görmek gerçekten iç ısıtıcı

    • GitHub tartışmaları da platformun daha çok uzmanlara yönelik olduğu dönemde çok daha yüksek kaliteliydi
      Bugünlerde birçok tartışmanın fiilen reddit/4chan başlığı gibi aktığını sık sık görüyorum; gitmek için bir neden daha

  • Başlık, GitHub issue’nun asıl başlığı olan "Major P2P issues in Israel and possibly other middle east countries" ile uyuşmuyor

  • Bu HN usulü sert bir tahmin ama GitHub issue’yu sonuna kadar okursanız kullanıcıların STUN hatası bildirdiğini görüyorsunuz
    Yani P2P bağlantısı kurulamıyor ve onun yerine gecikmesi yüksek relay sunucuları devreye giriyor
    Birçok kullanıcı sorunu eski bir Valve WebRTC dll sürümünü elle değiştirerek aştı; Valve geliştiricilerinin olay sonrası analizini okumak isterim

  • Başlıktan neden "in Israel and possibly other middle east countries" kısmı çıkarılmış? Tıklama tuzağı mı?

    • Ya da dünyada zaten yeterince fazla İsrail/Filistin tartışması başlığı var ve bunun bir yenisine dönüşmesini önlemek istemiş olabilirler
    • Burada uzun süredir bulunan biriyseniz, o ifadeyi de ekleyince başlık karakter sınırının aşılacağını bilirsiniz

  • Gerçekten moral bozucu bir gönderi ve bu kadar oy almış olmasına inanmak zor
    İnsanlar sanırım başlıktaki Valve’i görüp bunu önemli saydı ama asıl issue içeriği başlıkla bile uyuşmuyor

  • İlk başta İsrail ve bazı Orta Doğu ülkelerindeki büyük bir P2P sorunu gibi görünüyordu ama ek araştırmalar sonucunda bunun küresel bir sorun olabileceği anlaşılıyor

    • Şu ana kadarki "küresel", İsrail, Rusya ve Çin anlamına geliyor
      Bunların hiçbiri internet özgürlüğüne özel bir sevgi duyan ülkeler değil; gözetim ve sansür konusunda uzun geçmişleri var, dolayısıyla bu durum sansürcü ISP’lerin etrafından dolaşmayı zorlaştırmaya yönelik P2P ağ politikalarının bir yan etkisi olabilir

  • Bu, Valve kaynaklı bir sorun gibi görünmüyor
    Bildirilen sorunlar sadece bağlantıları çok agresif şekilde tarayıp filtreleyen ülkelerde ortaya çıkıyor gibi ve P2P bu tür müdahalelere duyarlı
    SDR, şifreli bir relay ağı; onion routing gibi şeylere benziyor
    Kötü niyetli bir aktörün bir P2P oyun dağıtıp o oyun üzerinden SDR üzerinde iletişim çalıştırabileceği iyi bilinen bir şey
    Böyle bölgelerde bu trafiği incelemek istemeleri kolayca hayal edilebilir

  • Çin’deyim; yaklaşık 3 hafta önce Steam’in Spacewar geliştirici oyununu kullanarak üçüncü taraf bir oyun oynadım, muhtemelen Steam P2P açıktı ve sorunsuz çalıştı

  • Yalnızca başlığa bakınca sanki her yerde bozulmuş gibi görünüyor