← rfc/
╔══════════════════════════════════════════════════════════════════════════╗
RFC 435 · telnet

TELNET Sorunları

Yazar
Kurum
Tarih
5 Ocak 1973
Durum
Network Working Group Yorum Talebi
Kanal
telnet/

Network Working Group B. Cosell
Request for Comment: 435 BBN-NET
NIC: 13675 D. Walden
Category: TELNET, Protokoller, Yankılama BBN-NET
Referanslar: 318, 357 5 Ocak 1973

TELNET Sorunları

Bu RFC, bizi bir süredir rahatsız eden TELNET ile ilgili bir dizi konuyu ele almaktadır [1]. Çıkış noktamız olan temel ve merkezi sorun yankılama meselesiydi. Yaşadığımız zorluklardan aşağı doğru inerek memnuniyetsizliğimizin kökündeki temel ilkeleri ortaya çıkardık ve oradan yeniden yukarı doğru ilerleyerek daha iyi olduğuna inandığımız bir düzen tasarladık. Bu notta hem alternatif düzeni hem de onun altında yatan ilkeleri tartışacağız.

Bir tür konu dışı olarak, yankılamayı tartışmadan önce olası bir engeli doğrudan saf dışı bırakmayı uygun görüyoruz. GİRDİNİZİ GİZLEYİN iyi bir fikir olabilir ya da olmayabilir; bu soru şu anda bizi ilgilendirmemektedir. Her durumda, girdinin gizlenmesi konusu yankılama konusundan kesinlikle ayrılabilir. Bu nedenle, bu işlevin NO ECHO komutu üzerinde çoklanması yerine, STOP HIDING YOUR INPUT komutunun onaylanmasını şiddetle tavsiye ediyoruz. Bu yapıldıktan sonra, HIDE YOUR INPUT ve STOP HIDING YOUR INPUT komut çifti birlikte tutulabilir ya da birlikte kaldırılabilir ve yankılama konusunu bunlardan bağımsız olarak tartışabiliriz.

Yankılama

Yankılama ile ilgili yaptığımız temel gözlem, sunucuların, ya kendi yankılamasını yapan ya da yapmayan terminalleri en iyi şekilde ele alacak biçimde optimize edilmiş göründüğü, ancak her ikisini birden iyi ele alamadığıdır. Bu nedenle, sunucunun yankı modunda bir değişiklik başlatmasını yasaklayan mevcut TELNET yankılama kuralları aşırı derecede kısıtlayıcı görünmektedir. Sunucular, normalde olmak zorunda kalmayacakları “yanlış” modda bulunan kullanıcıların yükünü taşımakta; hem insan hem de makine kullanıcıları ise tüm farklı sunucular için uygun yankılama modunu hatırlama ve açıkça ayarlama yükü altındadır. Bu yasağın, sunucu ve kullanıcı aynı anda bir yankı modu ayarlamaya çalıştığında ortaya çıkabilecek yarış durumları nedeniyle döngülerin oluşmasını önlemek amacıyla sunuculara dayatıldığı anlaşılmaktadır. Her iki tarafın da yankı modunda bir değişiklik başlatabildiği ve bu yöntemin döngüye girmediği bir yöntemi açıklayacağız.

Bu alternatif tanım üç temel varsayıma dayanmaktadır. Birincisi, yukarıda belirtildiği gibi, hem sunucu hem de kullanıcı yankı modunu önerebilmelidir. İkincisi, tüm terminaller, ya dahili olarak ya da yerel Ana Makine aracılığıyla kendi yankılarını sağlayabilmelidir. Üçüncüsü, tüm sunucular, uzak bir terminalin kendi yankılarını sağladığını varsayan bir modda çalışabilmelidir. Bu son iki varsayım, üzerine inşa edilecek evrensel ve asgari bir temel arayışının sonucudur. Normalde yankı sağlayan bir Ana Makine için uygun kodu devre dışı bırakmak oldukça kolaydır; ancak yankılama yapmayan bir Ana Makine için bu tür yordamları sistemine entegre etmek zor olacaktır. Benzer şekilde, yerel bir Ana Makine’nin kendi yankısını sağlayamayan bir terminale yankı sağlaması daha kolaydır; ancak otomatik yankılama donanıma yerleşik olan bir terminalde yankılamayı geri almak neredeyse imkânsızdır.

Önerdiğimiz tanım, mevcut ECHO ve NO ECHO komutlarını aşağıdaki şekilde kullanacaktır:

Bunlar elbette komutların hâlihazırda sahip olduğu anlamlara neredeyse aynıdır; ancak mevcut uygulamaların çoğu sunucudan kullanıcıya olan anlamları tersine çevirmiş görünmektedir.

Bizim tanımımızda, bir bağlantı açıldığında hem sunucu hem de kullanıcı, kullanıcının yerel olarak yankılama yaptığını varsayar. Kullanıcı gerçekte sunucunun yankılamasını tercih ediyorsa, ECHO komutunu gönderebilir. Benzer şekilde, sunucu yankılamayı kendisi yapmayı tercih ediyorsa (örneğin sunucu sistemi son derece etkileşimli yankılama için optimize edilmişse), sunucu da bir ECHO komutu gönderebilir. Hiçbiri bir şey yapmak zorunda değildir; bu tamamen bir tercih meselesidir.

Taraflardan biri tarafından gönderilen herhangi bir komut alındığında, eğer bu kabul edilebilir bir çalışma modu ise, alıcı bu modda çalışmaya başlamalıdır ve eğer bu işlem bir mod değişikliğini yansıtıyorsa, değişimin (ve ne zaman gerçekleştiğinin) onaylanması için aynı komutla yanıt vermelidir. Alınan komut kabul edilemez bir çalışma modu talep ediyorsa, reddetme olarak komutun tersi gönderilmelidir (bu mutlaka NO ECHO olmalıdır, çünkü taraflardan hiçbiri NO ECHO moduna geçişi reddedemez).

Bu kuralları daha biçimsel olarak ifade edersek:

  1. Hem sunucu hem de kullanıcı, bir bağlantının başlangıçta NO ECHO modunda olduğunu varsayar.
  2. Hiçbir taraf NO ECHO moduna geçme isteğini reddedemez.
  3. Her iki taraf da, istenmeden gönderilen bir komutu yalnızca mod değişikliği talep etmek için gönderebilir.
  4. Bir taraf, yankı modunu yalnızca kabul edilebilir bir istek aldığında değiştirir.
  5. Bir komut alındığında, taraf, isteği karşılamak için modunu değiştirmek zorunda kalmadıysa hariç olmak üzere, yankı modunu yanıt olarak gönderir.

Bu düzenin dikkate değer bazı özellikleri şunlardır:

  1. NO ECHO, nominal bağlantı modu olarak korunur. Bir bağlantı ECHO modunda yalnızca her iki taraf da bu şekilde çalışmayı kabul ettiğinde çalışır.
  2. Bu yordam döngüye giremez. Hangi tarafın (ya da her ikisinin) bir değişikliği başlattığından veya zaman sırasından bağımsız olarak, taraflar arasında en fazla üç komut gönderilir [2].
  3. Sunucular, tercih ettikleri çalışma modunu belirtmekte serbesttir. Böylece insan ya da makine kullanıcılarının her sunucu için uygun modu öğrenmesi gerekmez.

Üç İlke

Bu notun başında değindiğimiz genel ilkeleri belirtelim. İlkeler şunlardır: varsayılan gerçekleştirim, müzakere edilen seçenekler ve simetri.

Varsayılan gerçekleştirim ilkesi, tüm seçenekler için uygulanması zorunlu varsayılanların tanımlandığını belirtir. Bu ilke, her seçenek için “asgari” olanı aramamıza (herkes üzerindeki zorunlu yükü olabildiğince küçük tutmak için) yol açar ve protokolde döngüleri önler.

Müzakere edilen seçenekler ilkesi, seçeneklerin ilgili tüm (iki) tarafça kabul edilmesi gerektiğini ifade eder. Bu ilke, olumlu/olumsuz onay şemasını belirleyen etkendir.

Simetri ilkesi, hiçbir tarafın sunucu mu yoksa kullanıcı mı olduğunu “bilmek” zorunda kalmaması gerektiğini ifade eder. Şu ana kadar tanımladığımız düzen tamamen simetrik değildir; bu konuyu daha sonraki bir bölümde ele alacağız.

Yukarıda belirtilen ilkelerle birlikte tanımladığımız yankılama düzeni, TELNET protokolüne ilişkin yorumlarımızın özünü oluşturmaktadır. Bu notun geri kalanı, protokolün hangi yollarla genişletilebileceğine dair ek önerilerden oluşmaktadır. Genel olarak, bu önerilerin tümü, daha önce ortaya koyduğumuz ilkelerin yalnızca uygulanması ve geliştirilmesidir. Bununla birlikte, bu genişletmelerin verimliliği ve verdikleri “iyi his”, özgün önerilerimizin “doğruluğuna” olan inancımızı daha da artırmaktadır.

Şu ana kadar, derhal onaylanması gerektiğine inandığımız basit ve somut bir öneri sunduk. Ancak bu önerinin ötesine bakmak, daha fazla sayıda, daha iddialı değişiklikler önermemize yol açtı. Bu RFC’nin geri kalanı, yukarıdaki öneri kadar aciliyet taşımadığını düşündüğümüz, ancak ağ topluluğu protokolü elden geçirmeye karar verirse yine de akılda tutulması gereken fikirleri açıklamaktadır.

Eşzamanlama

Mevcut yankılama modu oluşturma kuralı hakkında duyduğumuz bir şikâyet, yankılama modu değişikliğini kullanıcıdan sunucuya giden veri akışıyla eşzamanlamaya yönelik bir hükmün bulunmamasıdır; bizim düzenimiz de bu açıdan kusurludur. Hawaii Üniversitesi’nden John Davidson, RFC 357’de, bu sorunu taşımayan daha ayrıntılı bir yankılama düzenini belgelemiştir.

Ancak biz, Davidson tarafından tanımlanan son derece etkileşimli düzenin gerektirdiği maliyetten daha mütevazı bir bedelle, normal yankı modu değişiklikleriyle ilgili sorunların çoğunu ortadan kaldırmanın mümkün olduğunu düşünüyoruz. Bunu, söz konusu düzenin küçük bir parçasını ödünç alarak yapabiliriz. Dahil edeceğimiz kural şudur: Bir taraf yankı modunda bir değişiklik talebini başlattığında, olumlu ya da olumsuz bir onay alana kadar, kullanıcıdan sunucuya giden veri akışındaki tüm verileri, iletmeden ya da işlemeden arabelleğe alır; onay alındığında ise arabelleğe alınan verilerle yeni müzakere edilen modda ilgilenir. Hem önerdiğimiz düzen hem de mevcut düzen açısından böyle bir isteğin mutlaka onaylanması garanti edildiğinden, arabelleğe alma süresi sınırlıdır.

Bu eşzamanlama sorununu ortadan kaldırma tekniğinin önemli bir yönü, bunun hiçbir zaman resmi protokolün bir parçası olmak zorunda olmamasıdır. İşleyişi tamamen sunucuya ya da kullanıcıya içsel olduğundan, her biri zarafet değerini gerekli kod ve arabellek alanının maliyetiyle bağımsız olarak tartabilir.

Diğer Seçenekler

Abhay Bushan, kullanıcı ve sunucunun satır-bazında mı yoksa karakter-bazında mı çalışacağının (bkz. RFC 318) da müzakere edilen bir seçenek olması gerektiğini bize önermiştir. Ayrıca, terminalin TELNET satır sonu kuralını izleyip izlemeyeceğinin de müzakere edilmesi gerektiğini önermiştir. Böylece bir bağlantı açıldığında, NO ECHO moduna ek olarak, terminal LINE-AT-A-TIME ve EOL modlarına da ayarlanmış olacaktır. Komut alanını LINE, NO LINE (= CHARACTER), EOL ve NO EOL (= ayrı CR ve LF) gibi yeni komutlarla genişletebiliriz.

Bu yönde ilerlemeye başladıktan sonra, birkaç ek uygulama daha bulduk. HIDE YOUR INPUT bir seçenek haline getirilebileceği gibi, Davidson’un yankılama düzeni ve hatta kullanılacak karakter kümesi de seçenek yapılabilir. Bir APL alt sisteminin, bağlantı için EBCDIC kullanılmasını kullanıcısına önermesinin oldukça makul olabileceğini düşünün.

Karakter kümesinin müzakere edilebileceğinden bahsederken, 7 bitlik USASCII’nin varsayılan olduğu örtük olarak ifade edilmişti. Varsayılanın doğrudan ikili olması olasılığı da kendiliğinden ortaya çıkmaktadır. Protokolü, ardından gelen baytın her zaman veri olarak yorumlanacağı bir QUOTE karakteri ile genişletirsek, 128–255 kodları, kullanılan veri modundan bağımsız olarak, yalnızca bu bölgedeki tüm veri baytlarının önüne bir QUOTE eklenerek “TELNET komut alanı” olarak korunabilir. BINARY izin verilen bir veri modu olsaydı, örneğin Dosya Aktarımı ve Grafikler gibi birçok daha üst düzey protokolün TELNET protokolünün üzerine ve içine inşa edildiğini hayal etmek kolaydır.

Böylece TELNET’i kısıtlı, terminal odaklı bir protokol olmaktan çıkarıp, her tür bayt odaklı iletişim için esnek ve genel bir protokol konumuna yükseltmiş olurduk. Böyle bir omurga ile, üst düzey protokollerin çoğu daha hızlı ve daha az zahmetle tasarlanıp gerçekleştirilebilirdi—bu koşullar da kuşkusuz evrensel kabul ve erişilebilirliklerini hızlandırırdı [3].

Geleceğin daha iyi bir dünyasına bakarak, daha derli toplu ve esnek bir komut düzeni ortaya koyduk. Bunu bir sonraki bölümden sonra açıklayacağız.

Simetri

TENEX grubundan bazı kişiler (özellikle Thomas, Burchfiel ve Tomlinson), protokol kurallarını simetrik hale getirmiş olmamıza rağmen, komutların anlamlarını simetrik hale getirmediğimize dikkat çekmiştir. Örneğin, ECHO komutunun “Sana ben yankılayacağım” ve “Bana sen yankıla” şeklindeki yorumları, örtük olarak hem sunucunun hem de kullanıcının hangisinin hangisi olduğunu bildiğini varsayar. Bu, yalnızca hangi tarafın kullanıcı olduğunun açık olmadığı sunucu-sunucu bağlantıları için değil, aynı zamanda Teletypeların birbirine bağlanması gibi kullanıcı-kullanıcı bağlantıları için de bir sorundur; çünkü bu durumlarda hangi tarafın sunucu olduğu net değildir.

Buna yanıt olarak, bir bağlantı çiftinde yankılama için yalnızca beş makul çalışma modu olduğunu anladık [4]:

Yankılama Modları

A. Hiçbir uç yankılamaz

B. Bir uç kendisi için yankılar

C. Bir uç diğer uç için yankılar

D. Her iki uç kendisi için yankılar

E. Bir uç her iki uç için yankılar

TENEX grubu, tamamen simetrik yankılamayı ele almak için dört komutun yeterli olduğunu bize önermiştir. Aslında bu dört komuttan daha önce zaten bahsetmiştik—ECHO ve NO ECHO’nun her biri için olası iki anlam. Açıkça ifade edersek, komutlar I'LL ECHO TO YOU, YOU ECHO TO ME, DON'T ECHO TO ME ve I'LL NOT ECHO TO YOU olacaktır. Yankılama artık iki seçeneğin müzakere edilmesidir ve başlangıçtaki varsayılan modlar DON'T ECHO TO ME ve I'LL NOT ECHO TO YOU’dur.

Sunucunun ya da kullanıcının hangisi olduğunu bildiği durumlarda, düzende yapılacak değişiklik asgaridir; çünkü bu durumlarda komutların anlamları hiçbir zaman belirsiz olmamıştır. Bir “uç” gerçekten hangisi olduğunu bilmiyorsa, işler biraz daha karmaşık hale gelir—örneğin her iki ucun da I'LL ECHO TO YOU modunda olduğunu düşünün; ancak bu durumda bile sorunlar aşılmaz değildir.

Simetri ilkesi benimsendiğinde, bir işlevi iki farklı şekilde kullanmak artık mümkün değildir. RFC 318’in 5. ve 6. sayfalarında Postel, INS ve SYNC için, kullanıcıdan sunucuya bir “break”i benzetmek üzere kullanıldıklarını, ancak sunucudan kullanıcıya giden çıktı arabelleklerini temizlediklerini belirten bir açıklama verir. Biz simetriye inandığımızdan, INS/DATA-MARK’ın her iki yönde de aynı şekilde ele alınmasını ve yeni bir CLEAR YOUR BUFFER seçeneğinin eklenmesini öneriyoruz.

Komut Biçimi

Önerdiğimiz diğer seçenekler boyunca tam simetriyi genişleterek, daha önce atıfta bulunulan sıkıştırılmış komut biçimini şimdi tanımlayabiliriz.

Her seçenek için dört ayrı komut (I WILL, I WON'T, YOU DO, YOU DON'T) yerine, her seçeneğe adanmış tek bir komuttan önce kullanılacak dört “ön ek” olacaktır—WILL, WON'T, DO, DON'T—ve WON'T ile DON'T varsayılan modlar olacaktır. Bir örnek vermek gerekirse, WILL ve WON'T için kodların 140 ve 141, ECHO REMOTE ve HIDE INPUT için kodların 132 ve 133 olduğunu varsayalım. O zaman olası komut birleşimlerinden bazıları şunlar olurdu:

140 133 -- DO HIDE INPUT
140 132 -- DO ECHO REMOTE
141 132 -- WON'T ECHO REMOTE
141 133 -- WON'T HIDE INPUT

Var olması gerektiğine inandığımız bazı komutlar şunlardır:

Bu komut yapısının ve genel bakış açımızın önemli bir erdemi, Host'ların artık tüm seçeneklerin neler olduğunun farkında olmalarına bile gerek kalmamasıdır. Her alternatifin varsayılan durumunda olduğu çalışma kipine NVT dersek, bir sitenin elbette bir NVT'yi ele alması gerekir; ancak bunun ötesinde, anlamadığı herhangi bir komuta yalnızca hayır yanıtını veriyorsa, uygulamayı tercih etmediği seçenekleri tamamen göz ardı edebilir. Böylece, seçenekler gerçekten isteğe bağlı olur (bir değişiklik olarak); yalnızca onları çağırmamayı seçebilecek kullanıcı için değil, artık onları sunmamayı seçebilecek sistem geliştiricileri için de.

Burada, açıkladığımız ilkeleri somutlaştıran bir TELNET sürümünü, ağ topluluğu tarafından yeterli görülen herhangi bir karmaşıklık düzeyinde, titizlikle tanımlamayı gönüllü olarak üstleniyoruz.

Ek: Örnek Bir Gerçekleme

Açıkladığımız temel şema, üzerinde düşündüklerimizin büyük kısmını temsil etmektedir; ek uzantılar ise yalnızca uzantılardır. Ancak, ruhen bizimle aynı çizgide olan bazı kişilerin, önerdiğimiz tüm değişikliklerin büyüklüğü karşısında gözlerinin korkabileceğinden endişe ediyoruz. Buna karşı koymak için, burada temel şemanın TIP [5] için ne kadar basit ve doğrudan bir biçimde gerçeklenebileceğine dair bir örnek sunuyoruz.

Her bir kullanıcı terminali için TIP üç durum biti tutacaktır: terminalin kendi kendine yankılama yapıp yapmadığı (NO ECHO her zaman) ya da yapmaması (ECHO kipi mümkün), (insan) kullanıcının ECHO ya da NO ECHO kipinde çalışmayı tercih edip etmediği ve bu terminale olan bağlantının ECHO ya da NO ECHO kipinde olup olmadığı. Bu üç bite P(hysical), D(esired) ve A(ctual) adını veriyoruz.

Bir terminal TIP'e arama yaptığında, P-biti uygun şekilde ayarlanır, D-biti ona eşitlenir ve A-biti NO ECHO olarak ayarlanır. Kullanıcı isterse P- ve A-bitleri doğrudan komutlarla elle yeniden ayarlanabilir; örneğin, Hawaii'de "full-duplex" bir terminalde bulunan bir kullanıcı, ana karadaki bir sunucunun tercihinden bağımsız olarak, uydu gecikmesi nedeniyle terminalinin NO ECHO kipinde çalışmasının daha iyi olacağını bilebilir — bu durumda TIP'e D-bitini ECHO'dan NO ECHO'ya değiştirmesini söyler.

TIP terminalinden bir sunucuya bağlantı açıldığında, TIP, P- ve D-bitlerinin MIN'i (NO ECHO, ECHO'dan küçüktür) A-bitinden farklıysa, sunucuya bir ECHO komutu gönderir. Sunucudan bir NO ECHO ya da ECHO gelirse, TIP A-bitini alınan isteğin, P-bitinin ve D-bitinin MIN'ine ayarlar. Bu işlem A-bitinin durumunu değiştirirse, uygun onayı gönderir; değiştirmezse, değişiklik yapılmaması isteğin reddedilmesi anlamına geliyorsa (yani P- ve D-bitlerinin MIN'i alınan A-isteğinden küçükse), uygun reddi gönderir. Bir bağlantı açıkken TIP terminal kullanıcısı P- ya da D-bitlerinden birini değiştirirse, TIP yukarıdaki sınamaları yineler ve gerekirse bir ECHO ya da NO ECHO gönderir. Bağlantı kapatıldığında, TIP A-bitini NO ECHO olarak sıfırlar.

TIP'in gerçeklemesi, sunucuya ECHO ya da NO ECHO komutlarının yalnızca bağlantı açıldığında ya da kullanıcı açıkça yankılama kipini değiştirdiğinde gönderilmesini içerecek olsa da, daha büyük Host'ların bu komutları oldukça sık gönderebileceğini varsayıyoruz. Örneğin, bir JOSS alt sistemi çalışırken sunucu kullanıcıyı NO ECHO kipine alabilirken, DDT çalışırken sunucu kullanıcıyı ECHO kipine alabilir.

Kaynaklar ve Notlar

  1. TELNET'in, Jon Postel tarafından RFC 318'de önerildiği şekilde tanımlandığını varsaydık.
  2. Hatalı bir gerçeklemenin, daha önce reddedilmiş bir komutu tekrar tekrar göndererek bir döngü etkisi elde edebileceğine dikkat ediniz. Bunu genel şemanın değil, gerçeklemenin bir özelliği olarak görüyoruz; reddedilmiş bir komut, bir şey değişene kadar — örneğin farklı bir program başlatılana kadar — tekrarlanmamalıdır.
  3. Will Crowther, TELNET'in üzerine daha üst düzey protokoller inşa etme düşüncesiyle, TELNET'e (mevcut SYNCH ile karıştırılmaması gereken) bir SYNC komutu ve bir SYNC REPLY eklenmesini önermiştir. Örneğin, bir sunucu, bağlantıyı kapatma ya da bağlantıyı başka bir sunucuya devretme gibi bir işlem yapmadan önce kullanıcının terminalinin çıktı arabelleğinin boşalmasını beklemek isteyebilir. Komut çiftinin şu anda belirgin bir kullanımını görmesek de, yeterince kullanışlı bir yapı taşı gibi göründüklerinden dahil edilmelerini öneriyoruz.
  4. Ağdaki bağlantıların çoğunun, tam çift yönlü olan TELNET bağlantıları olduğunu belirtmek belki de yerindedir. Tüm Host/Host protokol bağlantılarını, simplex yerine tam çift yönlü yapmak makul olmaz mıydı? Eğer herhangi bir nedenle gerçekten bir simplex bağlantıya ihtiyaç varsa, ters yön her zaman yok sayılabilir.
  5. TIP'e aşina olmayan okuyucular TIP Users Guide—NIC 10916'yı okuyabilir.

Bu RFC, Helene Morin tarafından, Via Genie aracılığıyla, 12/99 tarihinde çevrimiçi RFC arşivlerine girilmek üzere makine tarafından okunabilir biçime dönüştürülmüştür.