UDP kullanarak onay güvenilirliği

UDP hakkında bir sorum var. Bağlam için gerçek zamanlı bir aksiyon oyunu üzerinde çalışıyorum.

UDP ve TCP arasındaki farkları biraz okudum ve onları oldukça iyi anladığımı hissediyorum, ancak hiç doğru hissetmeyen tek bir parça var ve bu güvenilirlik ve özellikle teşekkür ediyor . UDP'nin varsayılan olarak güvenilirlik sağlamadığını anlıyorum (yani paketler atılabilir veya sipariş dışı olabilir). Bazı güvenilirlik gerektiğinde, gördüğüm çözüm (kavramsal olarak mantıklıdır) onayları kullanmaktır (yani sunucu istemciye bir paket gönderir ve istemci bu mesajı aldığında, sunucuya bir onay gönderir) .

Kabul iptal edildiğinde ne olur?

Yukarıdaki örnekte (bir istemciye bir paket gönderen bir sunucu), sunucu bu paketler için onaylar alınana kadar paketleri her kareyi yeniden göndererek potansiyel paket kaybını ele alır. Hala bant genişliği veya bozuk mesajlarla karşılaşabilirsiniz, ancak yalnızca paket kaybı açısından sunucu kapsanır.

Ancak, istemci hiçbir zaman ulaşmayacak bir bildirim gönderirse, sunucunun bu mesajı göndermeyi durdurmaktan başka seçeneği kalmazdı, bu pakette bulunan bilgiler gerekirse oyunu bozabilir. Sunucuya benzer bir yaklaşım uygulayabilirsiniz (yani, ack için bir ack alana kadar onay göndermeye devam edebilir misiniz?), Ancak bu yaklaşım sonsuza kadar geri dönmenizi sağlayacaktır (ack için ack için bir ack'e ihtiyacınız olacağı için) ve bunun gibi).

Temel mantığımın burada doğru olduğunu hissediyorum, bu da beni iki seçenekle bırakıyor.

1. Tek bir onay paketi gönderin ve en iyisini umun.
2. Bir avuç onay paketi gönderin (belki 3-4) ve hepsinin düşürülmeyeceğini varsayarak en iyisini umun.

Bu sorunun bir cevabı var mı? Temelde bir şeyi yanlış mı anlıyorum? Farkında olmadığım UDP kullanma garantisi var mı? Mantıkımın sağlam olduğundan rahat olana kadar çok fazla ağ kodu ile ilerlemekte tereddüt hissediyorum.

Bu, İki General Sorununun bir biçimidir ve haklısınız - makbuzu mükemmel bir şekilde garanti etmek için hiçbir yeniden deneme yeterli değildir.

Oyunlarda pratikte, teknik olarak güvenilir bir şekilde gelse bile, bilginin gerçekten önemli olmadığı bir zaman ufku vardır. 2 saniye önce mükemmel bir kafa vuruşuna sahip olduğunuzu öğrenmek gibi - oyuncunun bu bilgileri şimdi kullanması için çok geç.

Paket kaybınız o kadar yüksekse, gerekli bilgileri rutin bir şekilde sıkı bir reaksiyon penceresi içinden alamazsınız, o zaman gerçek zamanlı bir oyun için oyuncuyu tekmelemek ve onlar için başka bir yerde daha iyi bir eşleşme bulmaya çalışmaktan daha iyi olabilirsiniz. güvenilir bir bağlantı taklit etmek için paketi göndermeye devam edin.

Bu nedenle, bazı oyun çoğaltma sistemleri onaylamayı atlar ve yeniden dener ve en yeni güncelleştirmeyi olabildiğince sık spam olarak seçer. Biri düşerse veya çok geç gelirse, çok kötü, atlayın, bir sonrakini alın ve devam edin, boşluğu düzeltmek ve oyuncu tarafından görülen hıçkırıkları en aza indirmek için tahmin ve enterpolasyon sistemlerine güvenerek.

Aniden, geçmişte problemleri nasıl göz ardı ettiği ve şimdiki zamanda yaşamaya çalıştığı için bu "Simba Replikasyonu" adını vermeye başlamak istiyorum. ;)

Hibrit bir çözüm, yeni güncellemeyi göndermek için ileriye doğru yarışmaktır VE (oyun durumu güncellemeleri genellikle oldukça küçük / sıkıştırılabilir olduğundan ) son güncellemeyi de paketleyebilir ve belki ondan önce olanı ... Yani istemci onları kaçırdığında , bulmak ve düzeltmek için tam bir yolculuk süresi beklemek zorunda değilsiniz. Çoğu zaman istemci bunu zaten gördü, bu nedenle bu şekilde gereksiz veriler var, ancak cevapsız bir mesajı düzeltme gecikmesi daha düşük. İstemcinin güncellemeleri, gördükleri en son ardışık güncelleştirmenin dizin numarasını içerebilir, böylece bir sonraki güncelleme paketine kaç tane eski güncelleştirmeyi eklediğiniz konusunda en az tutucu olabilirsiniz.

Ayrıca, kısa ömürlü durumun güvenilir olmayan hızlı ateş tarzında çoğaltıldığı ve uzun vadeli durumun TCP veya kendi güvenilirlik uygulamanızı yüksek bir yeniden deneme ile güvenilir bir şekilde senkronize edildiği başka bir hibrit türü olarak iki katmanlı bir sistem de uygulayabilirsiniz. Miktar. Bu, yönetmek için daha karmaşık hale gelir, çünkü bakım yapmak için iki mesajlaşma sisteminiz vardır ve iki anlık görüntü, birbiriyle senkronize olmayabilir ve yepyeni bir kenar durumu sınıfı ekler.

TCP'nin kullandığı yaklaşım, gönderenin bir onay alana kadar paketi yeniden göndermeye devam etmesidir. Alıcı, yinelenen paketleri yok sayar, ancak yine de onlar için teşekkür gönderir. Gönderen, yinelenen onayları yok sayar.

Bir paket kaybolursa, gönderici bildiğiniz gibi yeniden gönderir.
Bir onay kaybolursa, gönderen, orijinal paketi tekrar gönderir ve bu da alıcının onayı yeniden göndermesine neden olur.

Belli bir süre içinde bir onay alınmazsa (belki 60 saniye veya 20 tekrar), oyuncunun oyunla bağlantısı kesilmiş sayılır. Sen gerekir zaman aşımı kuralının aksi halde ağ kablosu sonsuza sunucu üzerinde kaynaklarını bağlayabilir olacak unplugs bir oyuncunun bir çeşit uygulamak.

TCP'yi yeniden icat etmek istiyorsanız, ilk önce açıkladığınız sorunla ilgilenen TCP'ye bakmak mantıklıdır (çözümün bir kısmı, yeniden deneme girişimleri ve zaman aşımları için kullanıcı tanımlı değerleri kullanmaktır).

2 kanal, bir TCP kanalı (güvenilir iletişim için) ve bir UDP (düşük gecikme süresi iletişimi için) kanalı kullanan çözümler nadir değildir.

Bazı çözümler, bir istemcinin çok uzun süre bazı bilgileri eksik olduğunu algılar ve UDP veya TCP kullanabilen bir yeniden eşitleme başlatır.

Başka bir yaygın yaklaşım, iletişimi, hiç bir şekilde kabul edilmeyecek şekilde tasarlamaktır, ancak bu sorunun kapsamı dışındadır.

Bir RTS'de TCP gibi bir protokolü gerçekten kullanamazsınız ve UDP'yi de güvenilir hale getiremezsiniz. Eğer denerseniz, bir ağ bağlantısı olduğunda oyun donacaktır.

Bunun yerine, protokolü, kaçırılan paketlerin çok fazla önemli olmayacağı şekilde tasarlarsınız.

Kısa versiyon, şu anda nerede olduklarını bildiğiniz sürece diğer oyuncuların son karenin nerede olduğunu umursamamanızdır . Uzun versiyon daha karmaşıktır.

Daha sonra soru, bir paket kaybolduğunda ne yaparsınız? Ve cevap ... sanırım. Oyuncu muhtemelen düz bir çizgide ilerliyor, değil mi? Onları bu çizgi boyunca bir adım ileri taşıyın. ... hayır RTS oyuncu hariç hiç bir çizgide hareket eder. Ve sonra bir çarpışma tespiti var.

Bu zor. Birçok oyun yanlış anlıyor. Buna doğru bir cevap olmadığı, sadece takas edilebilecek çeşitli yanlışların olduğu iddia edilebilir.

Bu oyunların iyi çalışmasının nedeni, sadece bu sorunlar hakkında uzun ve zor düşündükleri değil, aynı zamanda internetin oldukça güvenilir hale gelmesidir. Hemen hemen tüm UDP paketleri hedeflerine zamanında ulaşır. (Güvenlik duvarı gibi kalıcı bir sorun olmadığı sürece)