Ağ Çalışma Grubu

Yorum İsteği (Request for Comments): 492
NIC: 15357
Tarih: 18 Nisan 1973
Yazar: E. Meyer, MIT-Multics

RFC 467'YE YANIT

Bolt, Beranek ve Newman, Inc. bünyesinden Jerry Burchfiel ve Ray Tomlinson, Ağ kullanıcılarını rahatsız eden iki probleme bir çözüm öneren bir Ağ Yorum İsteği (#467) yayımlamıştır. Bu belge, problemleri ve önerilen çözümleri kısaca açıklayacak ve yorumlar ile alternatif öneriler sunacaktır.

ARKA PLAN

Ağ üzerinden iki ana bilgisayar arasında bir veri bağlantısı kurmak için, Host-Host protokolü bir ana bilgisayarın Bağlantı İsteği göndermesini ve ikinci ana bilgisayarın olumlu yanıt vermesini gerektirir. Hedef ana bilgisayardaki istenen soket ("port") halihazırda kullanımda ise, hedef ana bilgisayar olumsuz yanıt verir. Bir bağlantı kurulduktan sonra, veri iletimi, bağlantının okuma ucundaki ana bilgisayar tarafından gönderilen veri tahsis mesajları ile kontrol edilerek devam edebilir. Yazma tarafındaki ana bilgisayar, protokol gereği, yalnızca okuma tarafı tarafından izin verilen kadar veri göndermekle sınırlıdır. Tahsisini tüketirse, yeni bir veri tahsis kontrol mesajı alınana kadar beklemek zorundadır. Daha sonra tekrar veri gönderebilir.

Problemlerden biri, mesajların iletim yolu üzerinde düşük fakat düzenli bir sıklıkla görünüşe göre kaybolmasından kaynaklanmaktadır. Açık bir bağlantı ile ilgili bir tahsis kontrol mesajı kaybolursa, bağlantı üzerinden veri iletiminin kalıcı olarak durduğu bir durum ortaya çıkabilir. Bunun nedeni, gönderme tarafındaki ana bilgisayarın tahsisini tükettiğine inanması ve okuma tarafından yeni bir veri tahsis mesajı gelmesini beklediği için göndereceği verileri tutarak beklemesidir. Ancak okuma tarafı aslında tahsisi göndermiştir, fakat mesaj kaybolmuştur. Okuma tarafı, gönderme tarafının devam edebileceğini düşünür ve bağlantı üzerinden veri gelmesini bekler. Bu durum "kayıp tahsis" olgusu olarak bilinir.

Bununla birlikte, bir veri mesajı kaybolursa ve gönderme tarafı, okuma tarafı tarafından yeni bir tahsis verilmeden önce tahsisini tüketirse benzer belirtiler ortaya çıkabilir. Gönderme tarafı yeni bir tahsis bekler, ancak okuma tarafı veri mesajlarından birini almamıştır ve hâlâ bir miktar tahsis kaldığına inanır. Her iki durumda da sonuç, kalıcı olarak bloke olmuş bir bağlantıdır. Bu durum, Ağ üzerinden yabancı ana bilgisayarlara daktilo bağlayan kullanıcılar için rahatsız edici olacak kadar düzenli biçimde meydana gelmektedir. Bu gerçekleştiğinde, mevcut tek çözüm bağlantıyı kesmek ve yeni bir bağlantı kurmaktır.

RFC 467'nin bu probleme önerdiği çözüm, biri gönderme tarafı (RCS) ve diğeri okuma tarafı (RCR) tarafından kullanılmak üzere bir çift tahsis sıfırlama kontrol mesajı tanımlamaktır. İstediği zaman, taraflardan herhangi biri, kendi tahsis sayacını sıfıra ayarlayarak ve karşı tarafa bir RCS veya RCR kontrol mesajı göndererek tahsis sıfırlama dizisini başlatabilir. Mesajı alan ana bilgisayar, o bağlantı için kendi tahsis sayacını sıfıra ayarlayacak ve yanıt olarak bir RCR veya RCS gönderecektir. Artık her iki tarafın tahsisleri eşzamanlıdır (sıfırdır) ve okuma tarafı tarafından yeni bir tahsis gönderildiğinde veri iletimi yeniden başlayabilir.

Bu prosedürün, taraflardan herhangi biri bağlantının şüpheli derecede uzun bir süre sessiz kaldığını düşündüğünde başlatılması amaçlanmaktadır. RFC 467'de bu kontrol mesajı çiftinin gerçek tanımı daha karmaşıktır; çünkü gönderme tarafı bir RCS kontrol mesajı göndermeden önce iki taraf arasındaki boru hattının veri mesajlarından boş olması gerekir.

İkinci problem, açık bir bağlantının bir tarafındaki ana bilgisayarın çökmesi ve yeniden ayağa kalktığında tablolarını temizlemesi, buna karşın bağlantının diğer ucundaki ana bilgisayarın herhangi bir şey olduğunu fark etmemesi durumunda ortaya çıkar. (Benzer bir durum, iki ana bilgisayar arasındaki Ağ yolunun geçici olarak başarısız olması, ancak yalnızca bir ana bilgisayarın bu başarısızlığı fark edip bağlantıyı kapatması durumunda da meydana gelir.) Çöken ana bilgisayar bağlantıyı yeniden kurmaya çalışırsa, diğer uçtaki ana bilgisayar bunu reddeder; çünkü bağlantı isteğinin hedeflediği soket görünüşte zaten açık bir bağlantıya dahildir.

Bazı sistemlerin terminal destek yazılımlarının kendine özgü özellikleri nedeniyle, bazı konsollardaki kullanıcılar, terminallerini destekleyen yerel sistem çöktüğünde bağlı oldukları uzak sisteme yeniden bağlanamayabilirler. Bu durum, orijinal bağlantıların hâlâ açık olduğuna inanan sistem iç durumunu sıfırlayana kadar süresiz olarak devam edebilir. Buna "yarı kapalı" olgusu denir ve RFC 467'de bir çözüm önerilmektedir.

RFC 467 önerisinin temel ilkesi, açık bağlantıya sahip olan tarafın, bu bağlantı ile ilgili herhangi bir iletişim gerçekleştiğinde bir tutarsızlığı algılayabilmesidir. Bunu yaptığında, normal protokole bakmaksızın sessizce bağlantıyı kapatması ve daha önce bağlı olunan porta yönelik bağlantı isteklerini karşılamaya hazır olması beklenir.

"Yarı kapalı" tutarsızlığın ortaya çıktığı iki tür etkileşim vardır. İlk durum, bağlı olan tarafın bir yazma bağlantısı üzerinden mesaj göndermesiyle ortaya çıkar. Bağlantıyı kaybetmiş olan taraf bunu, açık bir bağlantıya karşılık gelmeyen bir veri mesajı olarak alır ve bir Hata Raporu kontrol mesajı ile yanıtlar. Bağlı taraf bunu aldığında, bağlantının artık gerçekten var olmadığını fark eder ve kendi tablolarından siler.

İkinci durum, bağlantıyı kaybetmiş olan ana bilgisayarın, önceki bağlantıda yer alan soketlerin aynısını belirterek diğer ana bilgisayara bir bağlantı isteği göndermesiyle ortaya çıkar. Bu isteği alan ana bilgisayar tutarsızlığı fark eder; çünkü yerel soket yalnızca bağlı olmakla kalmaz, bağlantı isteğinde belirtilen yabancı soketin aynısına bağlıdır. Kendi içindeki bağlantı kaydını siler, böylece yerel soketi serbest bırakır ve bağlantı isteğine normal şekilde yanıt verir.

YORUMLAR VE ALTERNATİF ÖNERİLER

Project MAC Bilgisayar Sistemleri Araştırma Bölümü, bu RFC'deki her iki protokol değişikliği önerisine de karşıdır. Yarı kapalı bağlantıların ele alınmasına yönelik öneriye orta düzeyde karşı çıkıyoruz; çünkü problemin tüm yönlerini dikkate almamakta ve protokolü daha da karmaşıklaştırmaktadır. Ancak tahsis yeniden eşzamanlama önerisine çok güçlü biçimde karşıyız; çünkü bu öneri hastalığın kendisine değil semptomuna saldırmakta ve ayrıca potansiyel olarak çok ciddi bir ağ probleminin teşhisini maskeleme eğilimi göstermektedir.

RFC 467, bir bağlantının her iki ucundaki tahsis sayaçlarını yeniden eşzamanlamak amacıyla tek işlevi bu olan iki kontrol mesajının, Gönderici Tarafından Bağlantı Sıfırlama (RCS) ve Alıcı Tarafından Bağlantı Sıfırlama (RCR), eklenmesini önermektedir. Bu şekilde, ALL (allocate) kontrol mesajlarının iletim sırasında bir şekilde kaybolması nedeniyle gönderme tarafının veri iletimine devam edemediği "kayıp tahsis" olgusu çözülmüş olmaktadır. Eğer gerçekten bir "kayıp tahsis" problemi olsaydı, bu uygulanabilir bir çözüm olurdu. Ancak bunun gerçekte, her tür mesajın iletim sırasında kaybolduğu çok daha ciddi bir "kayıp mesaj" problemi olduğunu düşünüyorum.

ALL mesajları bazı ana bilgisayarlarla yapılan iletişimlerde çok sık olabilir ve en sık kaybolanlar bunlar olabilir; ancak mesajlar gerçekten ağ içinde kayboluyorsa, benzer belirtiler sağlayacak şekilde veri mesajları da kayboluyor olabilir. Bir Telnet bağlantısındaki kayıp mesaj, insan kullanıcı tarafından fark edilip aşılabilir; ancak iletilen bir dosyanın ortasından kaybolan ve fark edilmeyen bir mesaj, özellikle geçersiz dosya bir kez fark edilse bile belki de düzeltilemeyeceği için, felaket sonuçlara yol açabilir.

Bu "çözüm", acil problemi geçici olarak örtbas etmeye ve hem mekân hem de zaman bakımından çok uzak bir noktaya taşımaya eğilimli olduğundan, burada anlaşılmaz bir felaket olarak ortaya çıkar ve bu nedenle güçlü biçimde karşı çıkılmalıdır.

Gerçek problem, iletim yolunun bir yerlerinde mesajların rastgele ve fark edilmeden kaybolması gibi görünmektedir. Bu problemin gerçek bir çözümü ya (a) mesajların fark edilmeden kaybolmasına neden olan sebebi ortadan kaldırmak ya da (b) güvenilmez bir fiziksel iletim yoluyla başa çıkmak üzere tasarlanmış yeni bir protokole geçmektir. Bu çözümlerin her ikisi de şu anda belirli bir mesafe uzaktadır. Mevcut GVB ve RET komutlarını değiştiren ve ayrıca bunları bir ölçüde basitleştirme özelliği olan önerilen geçici bir çözüm aşağıda özetlenmiştir.

Bir alıcı ana bilgisayar, herhangi bir zamanda bir bağlantı için Give-Back allocation (GVB) kontrol mesajı gönderebilir.

    8       8        8        8
+-------+-------+--------+--------+
|  GVB  | link  | f =255 | f =255 |
|       |       |  m     |  b     |
+-------+-------+--------+--------+

Bu GVB mesajının biçimi, f(m) ve f(b) kesir alanlarının tüm bitleri 1 olacak şekilde zorunlu kılınması dışında, şu anda tanımlı olanla aynıdır. Bu, yukarı doğru uyumluluk sağlamak amacıyla tasarlanmıştır. Değiştirilmiş protokol altında çalışan bir ana bilgisayar kesir alanlarını yok sayacaktır; ancak mevcut protokol altında bu mesaj, her şeyin geri verilmesi anlamına gelir.

Bir GVB kontrol mesajı alan gönderici ana bilgisayar, belirtilen bağlantı üzerinde iletimi derhal durdurur. Gönderilen son mesajdan gelen RFNM alındığında (boru hattının boş olduğunu gösterir), gönderici ana bilgisayar kalan tahsisi geri veren bir Return Allocation (RET) kontrol mesajı gönderir.

     8      8        16         32
+------+------+-----------+-----------+
| RET  | link | msg space | bit space |
+------+------+-----------+-----------+

Değiştirilmiş RET komutu, şu anda tanımlı olanla aynı biçime sahiptir. İki fark şudur: veri iletimi durmadan ve son RFNM alınmadan gönderilemez ve gönderme bağlantısı için kalan tüm tahsisi geri vermelidir (yani tahsis sayaçları sıfıra ayarlanır).

Bağlantının okuma tarafındaki ana bilgisayar RET mesajını aldığında, gönderme tarafındaki tahsis sayaçları sıfırdır ve boru hattı boştur. Dolayısıyla, bağlantı sırasında herhangi bir hata oluşmamışsa, RET mesajında geri verilen tahsis, bağlantının okuma tarafındaki sayaçlarda bulunan tahsisle aynı olmalıdır. Eğer öyleyse, okuma tarafı, hiçbir mesajın kaybolmadığı bilgisiyle güven içinde yeni bir tahsis göndermeye devam edebilir.

İki değer kümesi uyuşmuyorsa, iletilen verilerde bir hata meydana gelmiş olabilir. Bu durumda ne yapılacağı yerel ana bilgisayarın bir tercihidir. Bazı ana bilgisayarlar bağlantıyı kapatmayı seçebilirken, diğerleri gönderme tarafına yeni bir tahsis göndererek iletime devam etmeyi seçebilir. Bana göre asgari olarak bir ana bilgisayar, hatayı hem kullanıcıya hem de ağ performansını izlemekten sorumlu ana bilgisayardaki bir insana bildiren bir mesaj göndermelidir.

Bu değiştirilmiş kontrol mesajı çifti, hem başlangıçta amaçlanan işlevini yerine getirebilmekte hem de alıcı tarafça başlatıldığında hataları algılayıp (istenirse) tahsisleri yeniden eşzamanlayabilmektedir. Bu şemanın, tahsis denetimini her iki taraftan başlatamaması yalnızca küçük bir dezavantajdır ve olumlu özellikleriyle fazlasıyla telafi edilmektedir: bu şema bir hatanın meydana geldiğine dair olumlu bir gösterge sağlar (önerilen RCS/RCR yöntemi hataları gizler) ve protokoldeki bu küçük değişiklik, NCP'lerde de karşılık gelen küçük bir değişiklik anlamına gelebilir.

RFC 467'de önerilen "yarı kapalı" problemine yönelik çözüm hakkında olumsuz görüşlerim vardır. RTS ve STR komutlarına ek yük bindirmek, protokolü gereksiz yere karmaşıklaştırmakla kalmaz, aynı zamanda bir anlamda işletimi daha az hataya dayanıklı ve problemleri daha belirsiz hâle getirebilir.

Ana itirazım, alıcı NCP'nin mevcut durumu ile çelişen kontrol mesajları alındığında yapılması önerilen eylemle ilgilidir. Bu öneri, bağlı olduğunu düşündüğü bir soket için bir STR veya RTS alan bir NCP'nin, yabancı NCP'nin durumu hakkında bir varsayımda bulunmasını (yabancı NCP'nin bağlantıyı kapattığı varsayımı) ve kendi durumunu otomatik olarak diğer uçta varsayılan duruma uyacak şekilde değiştirmesini (kendi ucundaki bağlantıyı kapatmasını) önermektedir.

Bu, varsayım doğruysa ve uygulamalar hatasızsa iyi çalışabilir. Ancak aşağıdaki durumlar, teşhisi zor olabilecek problemlere yol açabilir:

Yabancı NCP'nin, bağlı bir soket için bir RTS veya STR göndermesine neden olan bir hatası vardır.
Yabancı NCP, mevcut protokolün kuyruklama seçeneğini, zaten bağlı soketler için RFC gönderilmesine izin veriyor şeklinde yorumlamayı seçer.
Yerel NCP'nin, farklı bir ana bilgisayardan gelen ya da aynı yabancı ana bilgisayardan gelmekle birlikte farklı bir yabancı soketle ilgili olan RFC'leri, hedef sokete bağlı açık bağlantıyla ilgiliymiş gibi yanlışlıkla değerlendirmesine neden olan bir hatası vardır.

İkinci bir itiraz, bu önerinin tüm olasılıkları kapsamamasıdır. Olası iki durum şunlardır:

Başka bir soket (herhangi bir ana bilgisayardan), ölü bağlantıya dahil olan sokete bağlanmaya çalışır.
Okuma soketlerinden birine bağlı bir bağlantıyı kaybeden ana bilgisayar, farklı soketlerle başka bir bağlantı kurar, ancak önceki bağlantıyı gerçekleştiren aynı bağlantı numarasını kullanır.

İkinci durum, protokole ek karmaşıklıklar getirilerek ele alınabilir. Ancak birinci durum, gerçekten zaten bağlı olan bir soket için bir RFC gönderilmesi durumu ile belirtiler açısından aynıdır. Bu yaklaşımla ele alınamaz.

Mevcut Reset Host (RST) kontrol mesajının daha titiz bir şekilde kullanılmasının, "yarı kapalı" olgusunun nedenlerinin çoğunu ortadan kaldıracağına inanıyorum; yani bağlantıya dahil olan ana bilgisayarlardan biri, yeniden ayağa kalktığında bir RST göndermeden devre dışı kalır; ya da iki ana bilgisayar arasındaki ağ bölünür ve bunu yalnızca bir ana bilgisayar fark eder. Gerekli görülürse, diğer nedenlerden kaynaklanan "yarı kapalı" olgusu durumlarıyla başa çıkmak için, tekil bir bağlantıyı sıfırlamak üzere bir çift Reset Link kontrol komutu protokole eklenebilir.

Burada, "yarı kapalı" olgusunu hafifletmekle en azından dolaylı olarak ilişkili olduğunu düşündüğüm bir dizi ilkeyi kayda geçirmek istiyorum. Bunların hiçbiri mevcut Host-Host protokol belgesinde açıkça ifade edilmemiştir; ancak bunların dile getirilmesinin, ağ ve ana bilgisayar arızalarının yol açtığı karışıklığı azaltma eğiliminde olacağına inanıyorum.

Bir ana bilgisayar hakkında Imp-to-Host mesajı türü 7 (Host Dead) alan bir NCP, o ana bilgisayar ile olan tüm bağlantıları veya bağlantı girişimlerini ölü kabul etmeli ve tablolarından temizlemelidir.
Bir yabancı ana bilgisayarı ölü olarak not ettikten sonra ("Host Dead" Imp-to-Host mesajı alarak), bir NCP bu ana bilgisayardan Reset Host (RST) kontrol mesajı dışında herhangi bir mesaj alırsa, mesajı silmeli ve bir RST ile yanıtlamalıdır. Alınan bir RST'ye normal şekilde yanıt vermelidir.
İki ana bilgisayar, diğer herhangi bir iletişim biçiminden önce RST–RRP sıfırlama denetim iletisi çiftini değiş tokuş etmelidir. Yerel NCP çalışmaya başladıktan sonra veya yabancı NCP’nin kapalı olduğunu fark ettikten sonra, bu ana bilgisayar çifti daha önce sıfırlanmamışsa, iletişimi başlatmak isteyen bir NCP tarafından önce bir RST gönderilmelidir. Bunun, bir NCP’nin her çalışmaya başladığında diğer tüm ana bilgisayarlara sıfırlama göndermesini gerektirmediğine dikkat edin.
Açık bir bağlantıyı gerçekleştiren bir yazma bağlantısı ile ilgili olarak Imp-to-Host ileti türü 9 (Eksik İletim) alan bir NCP, kendi tercihine bağlı olarak, bir RFNM alınana kadar veya NCP vazgeçene kadar son iletinin yeniden iletimi için birkaç deneme yapabilir. Ancak, ileti sonunda yabancı ana bilgisayara başarıyla iletilmezse, NCP bağlantıyı iptal etmeli ve bir CLS denetim iletisi göndermelidir. Yeniden iletimin başarılı bir şekilde uygulanması, yeniden ileten ana bilgisayarın bir sonraki iletiyi göndermeden önce bir veri bağlantısı üzerinde RFNM beklemesine ve tüm ana bilgisayarların tamamen alınmamış iletileri göz ardı edebilmesine bağlıdır.
Geçerli durumuyla tutarsız görünen bir yabancı ana bilgisayardan ileti alan bir NCP, bu durumu değiştirmek için herhangi bir eylemde bulunmamalıdır. Bunun yerine, tutarsızlığın türünü belirten bir ERR hata denetim iletisi göndermeli ve tutarsız iletiyi göz ardı etmelidir. Bir ERR iletisi alan NCP, bunu insan incelemesi için kaydetmeli ve ardından tutarsızlığı gidermek amacıyla iç durumunu sessizce değiştirmesine veya denetim iletileri göndermesine izin verilir. (Bu, RFC 467’de bir NCP’nin, ilgili bağlantının bilinmediğini belirten bir ERR iletisi aldığında bir bağlantıyı silmesi gerektiği yönündeki önerinin bir genişletmesidir.)

[Bu RFC, çevrimiçi RFC arşivlerine giriş için makine tarafından okunabilir biçime Helene Morin tarafından, Via Genie aracılığıyla, 12/1999 tarihinde dönüştürülmüştür]