Network Working Group David Walden Request for Comments: 716 Joel Levin NIC #35534 24 Mayıs 1976

BBN Raporu 1822 Ek F için Geçici Revizyon

Son birkaç ay içinde, bir IMP’ye bağlı bir Host’un Çok Uzak Host (Very Distant Host veya VDH) olarak nasıl çalıştırılacağı konusunda bazı karışıklıklar olduğunun farkına vardık. Bu nedenle, BBN Raporu 1822 ("Bir Host ile bir IMP’nin Birbirine Bağlanmasına İlişkin Özellikler") bir sonraki revize edilişinde, bir VDH bağlantısının IMP tarafının nasıl çalıştığı ve Host tarafının en verimli şekilde nasıl çalışabileceği hakkında ek bilgiler ekleyeceğiz. Geçici bir önlem olarak, BBN Raporu 1822’nin Ek F bölümüne (mantıksal) bir güncelleme niteliği taşıyan bu RFC’yi dağıtıyoruz.

Ek F’nin F-6 sayfasında, ikinci dipnotu silin.

F-7 sayfasında, sayfanın 17. satırındaki "... and the odd/even bit is complemented." ifadesini bulun. Sayfanın geri kalanını silin ve aşağıdaki metni ekleyin:

Standart bir Host–IMP arayüzünde, mesajlar belirli bir sırada iletilir ve aynı sırada alınır. Bir Çok Uzak Host arayüzü de benzer şekilde çalışır; örneğin, mesajlar IMP’den kendi RTP’sine sırayla aktarılır ve Host’un RTP’si daha sonra bunları alıcı sürecine aynı sırada iletir. Ancak, bu iki yazılım arayüzü arasında sıralama konusunda herhangi bir şey söylenmediğini özellikle belirtmek önemlidir. Özellikle, özel arayüz bir pakette bir hata tespit ederse, örneğin, alıcı RTP paketi atar. Bir sonraki paket, gönderen RTP atılan ve onaylanmamış paketi yeniden göndermeden önce başka bir mantıksal kanaldan gelebilir ve alıcının bu paketi sırasız olarak kabul etmeye hazır olması gerekir.

Yukarıda tanımlanan protokol, RTP’ler arasında bu tür sırasız davranışlara açıkça izin verir; yalnızca RTP’nin iletim kısmının kanallarını sırayla doldurmasını (biri kanal sıfıra, biri kanal bire, biri kanal sıfıra, vb.) ve RTP’nin alım kısmının kanallarını sırayla boşaltmasını şart koşar. Ayrıca, doğru sıralamayı güvence altına almak için, başlatmadan sonra doldurulan veya boşaltılan ilk kanal kanal sıfır olmalıdır. Boş (null) paketler gönderildiklerinde ne bir kanal ne de bir kanal numarası kullanır ve alındıklarında onaylanmazlar.

Paketlerin onaylanana kadar yeniden iletilmesi gerektiğinde, işlem ve iletim gecikmeleri onayın birden fazla iletim süresi boyunca gecikmesine neden olabilir. Gereksiz yeniden iletim, yeni iletimlere engel olabileceği gibi hem alıcıya hem de göndericiye ek bir yük bindirir. Bu nedenle, onaylanmamış bir paketi yeniden göndermeye karar vermeden önce programlanmış bir gecikme öneriyoruz. Bu gecikme miktarı ayarlanabilir olmalıdır, ancak deneme değeri olarak 100 ms öneriyoruz. RTP, bir önceki paket onaylanmamışken bir sonraki paketin onaylandığını fark edebilirse ek verimlilik sağlanabilir; bu durumda, ilk paketin doğru alınmadığı açıktır ve programlanmış gecikmenin dolmasını beklemeden derhal yeniden gönderilebilir. Ancak, bu seçenek şu anda IMP’de uygulanmış değildir.