Tek yönlü ağ gecikmesini ölçme

Bu, oluşturduğum ağ gecikmesini ölçme hakkında bir bilmecedir. Çözümün imkansız olduğuna inanıyorum ama arkadaşlar aynı fikirde değil. Her iki şekilde de ikna edici açıklamalar arıyorum. (Bir bulmaca olarak sunulmasına rağmen, NTP'den bahsetmemek için çevrimiçi oyunlarda olduğu gibi iletişim protokollerinin tasarımı ve deneyimine uygulanabilirliği nedeniyle bu web sitesine uyduğunu düşünüyorum.)

İki robotun, aşağıdaki grafikte gösterildiği gibi farklı tek yönlü gecikme sürelerine sahip bir ağa bağlı iki odada olduğunu varsayalım. A robotu B robotuna bir mesaj gönderdiğinde, bunun gelmesi 3 saniye sürer, ancak B robotu A robotuna bir mesaj gönderdiğinde 1 saniye sürer. Gecikmeler asla değişmez.

Robotlar aynıdır ve paylaşılan bir saati yoktur, ancak zamanın geçişini ölçebilirler (örneğin, kronometreleri vardır). Hangilerinin robot A (mesajları 3 saniye gecikmeli) ve hangilerinin robot B (mesajları 1 saniye gecikmeli) olduğunu bilmiyorlar.

Gidiş-dönüş süresini keşfetmek için bir protokol:

whenReceive(TICK).then(send TOCK)

// Wait for other other robot to wake up
send READY
await READY
send READY

// Measure RTT
t0 = startStopWatch()
send TICK
await TOCK
t1 = stopStopWatch()
rtt = t1 - t0  //ends up equalling 4 seconds

Tek yönlü açma gecikmelerini belirleyen bir protokol var mı? Robotlar hangisinin daha uzun mesaj gönderme gecikmesine sahip olduğunu bulabilir mi?

Yazdığım bir blog gönderisinden aşağıdaki şema imkansız olduğuna dair görsel bir kanıttır:

Tek yönlü gecikmeler değişse bile (ve hatta negatif olur!) Her iki taraftaki paket varış sürelerinin nasıl aynı kaldığına dikkat edin. İlk paket sunucuya her zaman sunucunun saatinde 1,5 sn'de ulaşır, ikincisi her zaman istemcinin saatinde 2 saniyede istemciye ulaşır, vb. Paket içeriği ve yerel varış saatleri protokolün temel alabileceği tek şeydir , ancak Asimetri ilk saat eğimini de değiştirerek değiştiğinden içerik ve varış süreleri sabit tutulabilir.

Temel olarak, tek yönlü gecikmelerdeki asimetri tam olarak saat eğimine benziyor . Sorun, ilk saat çarpıklığını veya tek yönlü gecikme asimetrisini bilmemeye başladığımızı ve birini değiştirmek, diğerini değiştirmek gibi göründüğünden, etkilerinin ayırt edilemez olması nedeniyle, çözmek için katkılarını ayıramayız. tek yönlü gecikme asimetrisi. Bu imkansız.

Daha resmi olarak, sadece döngü uzunlukları verildiğinde kenar uzunlukları için çözemezsiniz. Döngü temeli, katılımcılardan birine göre n - 1 bilinmeyen saat eğimine karşılık gelen serbestlik derecesine sahiptir . Çok sayıda katılımcı olsa bile, her zaman tek yönlü gecikmeleri gizleyebilirsiniz:$n-1$$n-1$

Eğer görsel olarak eğimli değilseniz, başka bir sezgisel argümanım var. Gelecekte yüz yıllık bir zaman portalı düşünün. Karşı taraftaki biriyle sohbet ederken, yüz yıllık asimetriye tek yönlü gecikmelerde rağmen konuşmanın tamamen normal olduğunu fark ediyorsunuz. Bu ölçekte gözlemlenebilir herhangi bir etki açık olurdu!

Ben sadece kronometreleri karşılaştırarak tek yönlü gecikme anlamanın imkansız olduğunu düşünüyorum.

$A$$B$$C_{A1}$
$B$$C_{B1}=1$
$A$$C_{A2}=9$
$B$$C_{B2}=5$
$A$$B$

Belki bir ödül sorusu yaparsanız, birisi onu kıracaktır. O zamana kadar kudos.

Hangi düğümü kim (yani kim daha uzun mesaj gecikmesi olan) keşfetmek İYİ bir yol bulduk ve tek yönlü yolculuk gecikme tahmin. Diğer cevaplar doğru olmakla birlikte, SADECE elbette işe yaramayacak doğrudan saat ölçümü düşünülür. Ancak burada kanıtladığım gibi yukarıdaki için benim çalışma algoritması olduğu gibi bu hikayenin sadece bir parçasıdır:

Gerçek hayatta olduğu gibi varsayın:

• Sonlu bant genişliği b

• Her düğümün benzersiz bir adresi vardır (örneğin A ve B)

• Paket boyutu p, bant genişliği * gecikme ürününden çok daha küçük

• A ve B düğümleri kanalı doldurabilir

• Düğümlerin rastgele () işlevi vardır

Her düğüm kanalı kendi paketleriyle doldurur (sırasıyla A veya B olarak işaretlenir) VEYA diğer düğümlerden aldığı paketleri aşağıdaki gibi iletir:

Always fill the channel with my own packets except:
if I receive a packet from another node then
   Randomly choose to 
          either forward that packet from the other node
          or discard that packet and forward my own packet

Sezgisel Açıklama A'nın bant genişliği * gecikme ürünü daha yüksek olduğundan (gecikme daha yüksek olduğu için) A, B'den daha fazla paket almayı başaracaktır, bu nedenle her Düğüm diyagramda kim olduklarını bilebilir .

Ayrıca, algoritmanın üzerinde çalışacak yeterli yakınsama süresi ile A'nın B paketlerinin oranı, A'dan B'ye RTT gecikmesinin gerçek oranını ve dolayısıyla istenen OTT'yi gösterecektir .

SİMÜLASYON SONUÇ İZİ İşte yukarıdakileri kanıtlayan ve A'nın 3 saniye gecikmeye nasıl başarılı bir şekilde dönüştüğünü ve B'nin yaklaşık 1 saniye gecikmeye yaklaştığını gösteren bir simülasyon:

Şekillerin Açıklaması: Her çizgi 1 saniyeyi temsil eder (paket boyutu netlik için 1 saniye iletim süresine sahip olacak şekilde seçilir). Her bir düğümün belirli bir sırada veya zamanda olmayan herhangi bir zamanda algoyu başlatabileceğini unutmayın. Sütunlar aşağıdaki gibidir:

• NODE A şunları alır: A düğümü alıcı tarafında gördüğü şey (bu ayrıca aşağıdaki P4'tür)

• NODE A enjekte eder: A düğümü gönderir (bunun A veya rastgele A veya B olduğunu unutmayın)

• P1, P2, P3: A ve B arasında geçiş sırasında (sırayla) üç paket (1 saniyelik iletim 3 paketin 3 gecikme süresi boyunca geçişte olduğu anlamına gelir)

• NODE B şunları alır: B'nin alıcı tarafında gördüğü şey (bu P3'tür)

• NODE B enjekte eder: B'nin gönderdiği şey (bunun B olduğunu veya algo başına rastgele A veya B olduğunu unutmayın)

• P4: B'den A'ya geçişte olan paket (ayrıca bkz. P1, P2, P3)

• A sayar A: Gördüğü A paketleri için ne A sayar

• A sayar B: Gördüğü B paketleri için ne A sayar

• B sayar A: Gördüğü A paketleri için B hangi sayar

• B sayar B: Gördüğü B paketleri için hangi B sayar

• A-> B: A'nın B'ye karşı tahmin ettiği gecikme (görülen paketlere göre RTT'nin 4 saniyelik oranı)

• B-> A: B'nin A'ya göre tahmin ettiği gecikme (görülen paketlere göre 4 saniyelik RTT oranı)

Her iki düğümün de birbirine yakınlaştığını ve gerçek gecikmelerinin etrafında kaldığını görebildiğimiz için (aslında A için görmüyoruz çünkü yakınsama için daha fazla saniye gerekiyor, ancak B ile aynı davranışı birleştiriyor)

Daha iyi filtreler daha hızlı birleşebilir, ancak her ikisinin de gecikmeleri için doğru değerler etrafında nasıl birleştiklerini açıkça görebiliriz, bu nedenle gecikmelerini tam olarak bilebilirler (tahminlerini yalnızca gösterim için göstermeme rağmen).

Ayrıca, bağlantılar arasındaki bant genişlikleri farklı olsa bile, yukarıdaki yöntem hala bant genişliği tahminlerini anlamak için paket çiftleri kullanarak ve daha sonra sadece yukarıdaki orantı denklemine uygulanarak (daha kesin olmak için daha fazla düşünmek zorunda kalacak) tutabilir.

Sonuç A ve B için ağdaki konumlarını bilmek ve yukarıdaki diyagram için diğer düğüme olan gecikmelerini bilmek için bir algoritma sağladık. Özyinelemeli saat senkronizasyonu sorunu nedeniyle gerçekten bir çözüme yol açamayan saat tabanlı yaklaşımlar yerine bir ağ ölçüm tahmin yöntemi kullandık.

Not Şimdi bu simülasyonu tüm simülasyonları sağlayarak düzenledim, çünkü kimse bana inanmayacaktır, ilk yorumlarda gördüğünüz kadar çözdüm. Umarım bu sonuçlarla birileri daha ikna olabilir ve bu ağ ölçüm bulmacasında herkesin en azından bir hata veya doğruluk bulmasına yardımcı olabilir!

Bu @ user3134164 için bir yanıttır, ancak yorum yapmak için çok büyük.

$P_x$$x$$R_x$$x$

• $R_1 = (1 - R_2) \times (1 - P_2)$$R_2 = (1 - R_1) \times (1 - P_1)$$1 - R_2$$1 - P_2$
• $R_1$$R_2$$\frac{R_1}{1 - R_1}$$\frac{R_2}{1 - R_2}$

Bu yüzden bunun sizi hiçbir yere götürmeyeceğine inanıyorum. Lütfen bu akıl yürütme sırasında yapabileceğim herhangi bir hatayı belirtin.