Ağ Çalışma Grubu
John M. McQuillan
Yorum Talebi #394
Bolt Beranek and Newman Inc.
NIC 11856
27 Eylül 1972

Kategoriler: B.1
Günceller: RFC #381
Geçersiz Kılar:

IMP-HOST PROTOKOLÜNE İLİŞKİN İKİ ÖNERİLEN DEĞİŞİKLİK

Bu not, BBN Raporu 1822’de tanımlanan ve RFC 381’de gözden geçirilen IMP-Host iletişim protokolünde iki değişikliği açıklamaktadır. Birincisi, IMP’den Host’a arayüzü ve IMP’nin Host’a yaptığı her iletimdeki 30 saniyelik zaman aşımı mekanizması ile ilgilidir. İkincisi ise Host’tan IMP’ye arayüzü ele almakta ve yeni bir zaman aşımı mekanizması önermektedir. Bu değişiklikler, ifade ve uygulama açısından birbirinden bağımsızdır. Her bir öneri hakkında görüşlerinizi bekliyoruz. Olumsuz görüşler alınmazsa, ağ üzerinde Salı, 10 Ekim tarihinde devreye alınacaklardır (ciddi olumsuz görüşler alınırsa, işlem Kasım başına kadar ertelenecektir).

1) Yanıt vermeyen bir Host’un ağ açısından ölü ilan edilmesi

Halihazırda, bir Host’a düzenli bir mesajın her paketi için 30 saniye tanınmakta ve ayrıca düzensiz mesajları kabul etmesi için de 30 saniye verilmektedir. Host bu süre boyunca yanıt vermezse, IMP aşağıdaki işlemleri gerçekleştirir:

• a) Host için tutulan tüm mesajlar atılır.
• b) Atılan her mesaj için kaynak Host’a tür 9, alt tür 0 mesajı (Eksik İletim – Hedef Host Gecikmeli) gönderilir.
• c) IMP hazır hattı düşürülür ve yeniden yükseltilir.
• d) Host’a 3 adet tür 4 mesajı (NOP) gönderilir.
• e) Host’a bir adet tür 10 mesajı (IMP-Host Arayüz Sıfırlaması) gönderilir.

Buna ek olarak, IMP’nin Host’u ağ açısından ölü ilan etmesini öneriyoruz. Host’tan gelen bir sonraki bitin alınmasıyla birlikte, IMP Host’u canlı ilan edecek ve Host’un artık canlı olduğu bilgisinin ağ genelinde yayılması sırasında 30 saniyelik gecikmeyi başlatacaktır.

Bu değişiklik, hazır hatları açık olduğu halde IMP’den bit kabul edemeyen Host’ların neden olduğu bazı sorunları hafifletme amacı taşımaktadır. Birkaç Host bu kategoriye girmektedir. Bazı Host’ların hazır hatları, sürekli açık olacak şekilde kablolanmıştır. Terminal kullanımı sırasında ve tarama programları çalıştırılırken, bir Host’un yanıt vermediğini anlamak için 30 saniye beklemek can sıkıcıdır. Diğer bazı Host’lar ise sistem hata ayıklaması için bazen birkaç dakika boyunca “break-point modu”na girer. NCP yazılımı çalışmaz ve mesajlar ağda birikir ve atılır. Bu tür Host’ların, IMP’ye bir mesaj* gönderene kadar ölü ilan edilmesi ve ardından iletişim kurmaya çalışan herhangi bir kaynak Host’un, hedef Host’un ölü olduğu konusunda derhal bilgilendirilmesi daha tercih edilir görünmektedir.

2) Host’tan IMP’ye mesajların 15 saniyede zaman aşımına uğratılması

IMP bir Host’tan bir mesaj aldığında, mesajı işleyebilmek için çeşitli dahili kaynakları edinmek zorundadır. Mesaja bir mesaj numarası atamalı, dahili bir tabloda bir kayıt oluşturmalı ve benzeri işlemleri yapmalıdır. Bu IMP kaynaklarından herhangi biri mevcut değilse, IMP basitçe mevcut hale gelene kadar bekler. Bu sırada Host’tan başka mesaj alamaz ve arayüz durdurulur. Bu durum genellikle anlıktır, ancak olağandışı koşullar altında IMP, kabul etmeye başladığı bir mesajı birçok saniye boyunca işleyemeyebilir.

Bu durum, yarı çift yönlü arayüzlere sahip Host’lar için özellikle zor bir sorun oluşturur. IMP’nin bir mesajı işlemesi 30 saniye sürerse, 1) maddesinde belirtilen IMP’den Host’a zaman aşımı devreye girer ve Host son 30 saniyede kendisine gönderilen tüm mesajları kaybeder. (Yarı çift yönlü arayüzün, ölümcül bir kilitlenmenin nedeni olabileceği belirtilmelidir; örneğin, IMP’nin belirli bir mesajı işlemek için gerekli kaynakları edinememesinin nedeni, söz konusu Host’un kuyruğunda birkaç mesaj bulunması ve bunların depolamayı, mesaj numaralarını veya tablo yuvalarını meşgul etmesi olabilir. Ağa yeni mesajlar sokulabilmeden önce, Host’un bu mesajları kabul etmesi gerekir.) Tam çift yönlü arayüzlere sahip Host’lar için bile, bu durumun ortaya çıkması diğer yararlı iletişimleri engelleyebilir.

IMP’nin, kabul etmeye başladığı bir mesajı işlemeye devam edemediği durumlarda Host’u bilgilendirmesini öneriyoruz. IMP, mesajı 15 saniye boyunca işlemeye çalışacak ve ardından Host’a tür 9, alt tür 4 mesajı (bitler 30, 31, 32 = 100) gönderecektir; bu mesaj Eksik İletim – Kaynaklar Kullanılamıyor olarak tanımlanacaktır. Böyle bir durumda, IMP mesajın hiçbir bölümünü ağa göndermeyi başaramamıştır. IMP, mesajın geri kalanını alacaktır; bu noktada yarı çift yönlü arayüze sahip bir Host, IMP’den gelen mesajları kabul etmeye başlamalıdır; tam çift yönlü arayüze sahip bir Host ise başka bir mesaj iletmeye çalışabilir. Host, isterse eksik kalan mesajı yeniden iletmeyi deneyebilir.

* Bu nedenle bir Host, IMP’sinden bir tür 10 mesajı aldığında, IMP’sine en az iki NOP (veya başka mesajlar) göndermelidir.

Bu RFC, BBN Corp. tarafından Alex McKenzie’nin yönetimi altında, çevrimiçi RFC arşivlerine girilmek üzere makine tarafından okunabilir biçime dönüştürülmüştür. 1/97