Network Working Group John Davidson
Request for Comments: 357 Hawaii Üniversitesi
NIC: 10599 Will Crowther
Kategoriler: Uzaktan Kontrollü Yankılama, Uydu, TELNET BBN
Referanslar: RFC'ler 346, 355, 358, 318 John McConnell
ILLIAC
Jon Postel
UCLA
26 Haziran 1972

Uydu Bağlantıları İçin Bir Yankılama Stratejisi

I. Giriş

RFC 346'da (Jon Postel tarafından yazılan "Uyduya İlişkin Hususlar") belirtildiği gibi, ARPANET üzerinden tam çift yönlü terminaller için yankılama sağlayan etkileşimli sistemler, iletim gecikmeleri arttıkça kullanımı daha da zorlaşır. Bunun nedeni, elbette, bir karakterin gidiş-dönüş süresinin sunucunun kendine özgü yankılama gecikmesine eklenmesi ve bunun sonucunda terminal yankılamasının son derece ağır ve yavaş görünmesidir.

Sunucusundan tek bir uydu bağlantısı ile ayrılmış bir terminal için gecikme öyle olacaktır ki, sunucudaki yankılama anlık olsa bile, bir giriş karakterinin tuşlanması ile yazdırılması arasındaki gecikme neredeyse yarım saniye olacaktır. Buna ek olarak, karakter yüzey ağının bir bölümünden yönlendirilirse, gecikme elbette artacaktır. En az bir saniyelik yankı gecikmelerinin yaygın olmayacağı tahmin edilmemektedir.

Bu belge, basit yankılamayla ilişkili gecikmeyi ortadan kaldıracak ve iletim gecikmesinin yalnızca hesaplama maliyetinin içinde gizlenmesine olanak tanıyacak bir stratejiyi açıklamaktadır. Bu şema, mevcut Kullanıcı TELNET'lerine isteğe bağlı bir ek olarak önerilmektedir; kullanımı, işbirliği yapan bir sunucu sürecinin açık desteğini gerektirir.

II. Standart Yankılama Stratejisi

Yerel olarak bağlı tam çift yönlü terminaller için yankılama normalde sunucuda, (örneğin) Terminal Handler adı verilen yerleşik bir sistem görevi tarafından sağlanır. Terminal Handler, bire bir ya da basit ikame esasına göre yankılama yapar ve kullanıcının süreci adına yazılan tüm girdileri tamponlar.

Kullanıcı sürecinin en verimli şekilde çalışabilmesi için Terminal Handler, tam bir komut ya da parametre (ya da her neyse) yazılıncaya kadar karakterleri toplamalıdır. Daha sonra, varsayılan olarak, süreç anlamlı bir hesaplama yapabilir. Kullanıcı süreci, beklediği dizgenin sözdizimini bildiğinden, tamamlanmış parametreleri ayıran karakterleri Terminal Handler'a belirtebilir. Bu tür karakterlere uyandırma karakterleri denir; çünkü yankılandıklarında kullanıcı süreci uyandırılır.

Kullanıcı tarafından tuşlanan bazı komutlar, süreçten bir çıktı yanıtı gerektirecektir. Yazılan komutların yanıtı tarafından izlenmesi ve sonraki komutlardan ayrılması için Terminal Handler, kullanıcının önden yazdığı karakterlerin yankılanmasını askıya almalıdır. Süreç, çıktı yanıtını tamamladığını (örtük ya da açık olarak) belirttiği anda, yankılamayı (tampondaki yankılanmamış karakterlerle birlikte önden yazım için başlayarak) yeniden başlatabilir.

Terminal Handler'ın yankılamayı askıya almasına neden olan karakterlere kesme karakterleri denir. Bunlar, beklenen girdinin sözdizimine dayanarak kullanıcı süreci tarafından belirlenir. Normalde kesme karakterleri aynı zamanda uyandırma karakterleridir. Örnek olarak:

Bir metin düzenleyici, her nokta ya da soru işareti yankılandığında yazılmış İngilizce cümleleri alıp işleyebilir. Bu iki karakter yalnızca uyandırma karakterleridir. Yankılamayı askıya almaya gerek yoktur.
Bazı sistemlerde, bir ESC karakteri komut tanımayı başlatmak için kullanılır. Aşağıdakini yazan bir kullanıcı
```
CO [ESC] ABC [ESC] XYZ
```
çıktıda şunu görmelidir
```
COPY (FROM FILE) ABC (TO FILE) XYZ
```
ESC hem bir kesme hem de bir uyandırma karakteridir. Yazdırılan çıktı, kullanıcı ne kadar hızlı yazarsa yazsın aynı olmalıdır.

Sunucu, her kullanıcı sürecinin aşağıdakileri Terminal Handler'a iletebilmesi için bir araç sağlamalıdır:

uyandırma karakterleri kümesi,
kesme karakterleri kümesi,
hangi kesme karakterlerinin yankılanacağı ve hangilerinin yankılanmayacağı (bazı kesme karakterleri—örnek 2'deki ESC gibi—yankılanmamalıdır),
bir çıktı yanıtının tamamlanması,
karakterlerin yankılanıp yankılanmayacağı (yankılamamak, "girdini gizle" uygulamalarında kullanışlıdır).

Uygulama açısından, (1) ve (2), kullanıcı sürecinin her bir uyandırma karakteri için 1'lerin ayarlandığı 128 bitlik (bir ASCII aygıtı için) bir tablo ve her bir kesme karakteri için 1'lerin ayarlandığı başka bir tablo belirtmesine izin verilerek iletilebilir. Terminal sayısı arttıkça bu yaklaşım çekirdek bellek açısından oldukça pahalı hale gelir; çoğu durumda yankılama Terminal Handler tarafından yapılırken kullanıcı süreci çekirdekte olmayacağından, sistem bu bit tablolarını kendisi saklamak zorundadır.

Depolama gereksinimlerini azaltmak için sistem, tüm programcılarına, örneğin aşağıdakilerden her süreci için desteklenen sınırlı sayıda, diyelim ki 4, kesme karakteri kümesini duyurabilir:

alfasayısal karakterler,
noktalama karakterleri,
yankılanabilir kontrol karakterleri (zil ve CR dahil vb.), veya
yankılanamayan kontrol karakterleri (Control-C vb.),

hangi kesme küme(leri)nin kullanılacağını bir sistem çağrısında belirterek. Bu, terminal başına sistem depolamasında en fazla 4 bit ve 128 olası ASCII karakterinin her birinin hangi küme(ler)e ait olduğunu tanımlayan tek bir tablo gerektirir.

Kullanıcı sürecinin (3)'ü Terminal Handler'a iletebilmesi için (hangi kesme karakterlerinin yankılanacağı ve hangilerinin yankılanmayacağı), süreç, üyeleri yankılanacak olan kesme sınıfları için 1'lerin ayarlandığı başka bir 4 bitlik alan belirtebilir. Yukarıdaki 4 sınıf için, (d) sınıfının üyeleri tanım gereği yankılanamaz olduğundan yalnızca 3 bit gerekecektir.

Bir çıktı yanıtının tamamlanmasını (4) iletmek için, kullanıcı süreci açık bir sistem çağrısı yapabilir; ya da Terminal Handler, süreç kesmeden sonra gelen ilk karakter için girdi istediğinde tamamlanmayı varsayabilir.

"Girdini gizle" (5), aşağıdakilerden birini belirten bir sistem çağrısı ile iletilecektir:

(a) "her karakterde kes ve hiçbir kesme karakterini yankılama", ya da örneğin
(b) alfasayısal bir parola için "hiçbir şeyi yankılama ve noktalama ya da herhangi bir kontrol karakterinde kes",

saklanacak ifadenin sözdizimine bağlı olarak.

III. Tanımlar

Bazıları standart yankılama stratejisi açıklamasında kullanılan terimlerin doğrudan uzantıları olan birkaç yeni terimin tanımlanması gerekir. Sunulan dört tamponun hepsinin ayrı yapılar olarak uygulanmasında ısrar etmek için bir neden yoktur; aşağıdaki tartışmalarda açıklık sağlamak için mantıksal olarak ayrılmışlardır.

Uzaktan Kontrollü Yankılama (RCE)

Bu, bu belgede açıklanan yankılama stratejisinin adıdır. Yankılama (uzaktaki) sunucu tarafından kontrol edilecek ancak Kullanıcı TELNET tarafından gerçekleştirilecektir.

Girdi Tamponu

Bu, bir Kullanıcı TELNET tarafından, terminal klavyesinden alındıkları sırayla (NVT karakterlerine dönüştürüldükten sonra) karakterleri tutmak için kullanılan mantıksal bir tampondur.

İletim Tamponu

Bu, bir Kullanıcı TELNET tarafından, yazılmış ancak henüz sunucuya iletilmemiş NVT karakterlerini tutmak için kullanılan mantıksal bir tampondur.

Çıktı Tamponu

Bu, bir Kullanıcı TELNET tarafından sunucudan alınan NVT karakterlerini tutmak için kullanılan mantıksal bir tampondur.

Yazdırma Tamponu

Bu, karakterlerin sırayla terminal yazıcısına gönderileceği, Kullanıcı TELNET içinde bulunan mantıksal bir tampondur. (Çıktı tamponu, gerçek terminal tarafından kullanılan karakterlere dönüştürülmesi gerekebilecek NVT karakterlerini içerir.)

Kesme Sınıfları

Ağ Sanal Terminali tarafından kullanılan 128 olası (7 bitlik) ASCII karakteri, birkaç yarı eşdeğerlik sınıfına (örneğin alfabetik, sayısal, noktalama karakterleri vb.) ayrılabilir. Bu sınıflar, her karakterin en az bir sınıfın üyesi olacağı, ancak birden fazlasına da ait olabileceği şekilde tanımlanabilir.

Bir sunucu süreci, bu sınıflardan bazılarının (ya da tümünün ya da hiçbirinin) kesme sınıfları olarak kabul edileceğini bir Kullanıcı TELNET'e bildirebilir. Yani bir kesme sınıfı, sunucu süreci için özel öneme sahip bir eşdeğerlik sınıfıdır. Bölüm II'deki tartışma açısından, sunucu, belirli bir süreç tarafından herhangi bir birleşimi kesme sınıfı olarak atanabilecek 4 eşdeğerlik sınıfı tanımıştır.

RCE uygulaması, kesme karakteri kümelerinin seçiminde daha fazla esneklik sağlamak için 4'ten fazla eşdeğerlik sınıfına (belki 8'e kadar) sahip olacaktır.

Kesme Eylemi

İki kesme eylemi mümkündür:

girdi tamponunda karşılaşılan bir kesme karakteri uygun zamanda yazdırma tamponuna taşınır, veya
girdi tamponunda karşılaşılan bir kesme karakteri yazdırma tamponuna taşınmaz.

Sunucu süreci, hangi kesme eyleminin izleneceğini belirtecektir. (Bu iki eylem, kesme karakterinin yankılanmasına ya da yankılanmamasına karşılık gelir.)

IV. Açıklama

(Bu açıklama, elbette bir Kullanıcı TELNET'i bünyesinde barındıran TIP cinsinden yazılmıştır.)

Uzaktan Kontrollü Yankılama, yankılama sorumluluğunu Terminal Handler'dan alıp TIP'e aktarmaya yönelik bir girişimdir; uyandırma işlemleri sunucuda ele alınmaya devam eder. Sürecin sunucunun Terminal Handler'ına olan arayüzünün (sistem çağrıları vb.) değişmesi gerekmez, ancak (kısaltılmış) Terminal Handler'ın (aslında bir Sunucu TELNET) sürecin yankılama gereksinimlerini TIP'e iletmenin bir yolunu bulması gerekir. Bunu TELNET komutları ve kontrol bilgileriyle yapar. Belirli bir hizmet veren ana makineye özgü sistem çağrıları ve yankılama parametreleri (kesme sınıfları vb.) Sunucu TELNET komutları tarafından yorumlanmalıdır.

Karakter Akışı

Şekil 1'e bakınız. Tam çift yönlü bir terminalden alınan bir karakter, NVT eşdeğerine dönüştürülecek ve hem iletim hem de girdi tamponlarına yerleştirilecektir. TIP'in iletim stratejisi, karakterin iletim tamponundan ne zaman çıkarılacağını belirler; sunucunun RCE kontrol komutları ise girdi tamponundan ne zaman çıkarılacağını belirler.

Sunucudan alınan bir karakter çıktı tamponuna yerleştirilecektir.

DISCARD, ECHO ve OUTPUT etiketli üç yoldan tam olarak biri her zaman etkin durumdadır. RCE komutları hangisinin olacağını belirler. Böylece karakterler:

DISCARD: girdi tamponundan sırayla çıkarılıp atılabilir,
ECHO: girdi tamponundan sırayla çıkarılıp yazdırma tamponuna yerleştirilebilir, veya
OUTPUT: çıktı tamponundan sırayla çıkarılıp yazdırma tamponuna yerleştirilebilir.

Yazdırma tamponundan NVT karakterlerinden dönüştürülecek ve derhal terminalin yazıcısına gönderileceklerdir.

                          +----------------------+
                          | Terminal Keyboard    |
                          +----------------------+
                                       |
                                   Convert to NVT characters
  To       +-------------------+       |
Server <---| Transmission Buffer|       |
           +-------------------+       |      +----- From Server
                    ^                  |      |
                    |------------------+      |
                    V                         V
            +-----------------+       +-----------------+
            | Input Buffer    |       | Output Buffer   |
            +-----------------+       +-----------------+
                |        |                    |
        DISCARD |        +-- ECHO ---+      +--- OUTPUT
                |                  |      |
                V                  V      V
               To          +----------------------+
          Oblivion         |     Print Buffer     |
                           +----------------------+
                                      |
                                  Convert from
                                 NVT Characters
                                      |
                                      V
                             To Terminal Printer

Şekil 1. TIP İçindeki Karakter Akışı

Komutlar: Sunucudan Ana Makineye

Aşağıdakiler, sunucu süreci tarafından TIP'e gönderilen önerilen TELNET komutlarıdır. RCE kullanılmıyorsa (2) ila (5) arasındaki komutlar gönderilmemelidir.

Uzaktan Kontrollü Yankılamayı Kullan. Sunucu, TIP'ten bu belgede açıklanan yankılama stratejisini kullanmasını ister. TIP, EVET (kullanacağım) ya da HAYIR şeklinde yanıt verebilir. (Yarış durumlarını ortadan kaldırmak için EVET yanıtının da "RCE Kullan" olması önerilir.)
Kesme Eylemini Ayarla. Bu aslında iki komuttur. Sunucu, kesme eylemini bir kesme karakterini yankılayacak ya da yankılamayacak şekilde ayarlayabilir.
Kesme Sınıflarını Ayarla. Bu komut, kesme sınıfları olarak kabul edilecek eşdeğerlik sınıflarını belirtir. İki (8 bitlik) baytlık bir komut olacaktır.

Not: Öngörülen uygulama, TIP'in ASCII karakter başına bir giriş içeren bir tabloya sahip olmasını gerektirir. Her giriş, her eşdeğerlik sınıfı için bir bit konumu olacak şekilde biçimlendirilir ve verilen karakterin o sınıfın üyesi olup olmamasına göre bir bit ayarlanır ya da sıfırlanır. Sunucu, TIP'e bir "Kesme Sınıflarını Ayarla" komutu (1. bayt) ve ardından, sunucu süreci için kesme sınıflarını temsil eden eşdeğerlik sınıfları için bit konumları ayarlanmış biçimlendirilmiş bir kontrol sözcüğü (2. bayt) gönderir.

Girdi tamponundan bir (sanal) karakter alındığında TIP, karakterle indekslenen bir tablo araması yapar. Tablo girişinin terminalin kontrol sözcüğü ile basit bir VE (AND) işlemi sıfırdan farklı bir sonuç verirse, bir kesme alınmıştır. (Bir kesme karakterinin alınması OUTPUT yolunu etkinleştirir.)

(4) Kesme Noktasına Taşı (MTB). Bu komut, TIP'e girdi tamponundan karakterleri sırayla yazdırma tamponuna taşımasını ve bir kesme karakteriyle karşılaşıncaya kadar devam etmesini söyler. Kesme karakteri, daha önce belirtilen kesme eylemine bağlı olarak taşınacak ya da atılacaktır. (Özünde, MTB ECHO yolunu etkinleştirir.)

(5) Kesme Noktasına Kadar Sil (DTB). Bu komut, TIP'e girdi tamponundan karakterleri sırayla alıp bir kesme karakteriyle karşılaşıncaya kadar atmasını söyler. Kesme karakteri de atılacaktır. Bu, kullanıcının girdisini gizlemek için kullanışlı bir mekanizma sağlar. (DTB DISCARD yolunu etkinleştirir.)

Komutlar: Kullanıcıdan Sunucuya

KULLANICI, (TIP aracılığıyla) sunucu sürecine "Uzaktan Kontrollü Yankılamayı Kullan" talebi gönderebilir; sunucu buna "EVET" ya da "HAYIR" şeklinde yanıt vermelidir.

Genel İşleyiş

Oldukça basit bir şekilde, Uzaktan Kontrollü Yankılama stratejisi şu şekilde çalışır: Sunucu TELNET, TIP'e (özünde)

bir mesajı yankılamasını,
sürecin bu mesaja verdiği yanıtı yazdırmasını,
bir sonraki mesajı yankılamasını,
o mesaja verilen yanıtı yazdırmasını

...

vb., yarı çift yönlü bir aygıt kullanıldığında dayatılacak olana benzer biçimde girdilerin ve yanıtların düzenli bir listelenmesini sağlamak için söyler.

Gerçek etkileşim denetim komutlarına bağlıdır. Bir terminal-hizmet süreci bir TIP kullanıcısı adına çağrıldığında, Sunucu TELNET "Use RCE" komutunu gönderir; TIP "YES" yanıtını verir. Ardından Sunucu TELNET, terminal-hizmet sürecinin talep ettiği kesme stratejisini doğru biçimde yansıtmak için "Set Break Action" ve "Set Break Classes" komutlarını gönderir. Son olarak, Sunucu TELNET bir MTB komutu gönderir. Bu, ECHO yolunu etkinleştirir.

TIP, giriş arabelleğinden karakterleri çıkarır ve bunları yazdırma arabelleğine yerleştirir. Bir kesme karakteriyle karşılaştığında, belirtilen kesme eylemini gerçekleştirir ve OUTPUT yolunu etkinleştirir.

Daha sonra karakterler sırasıyla çıkış arabelleğinden yazdırma arabelleğine taşınır. Bir MTB (veya DTB) ile karşılaşıldığında, bu atılır ve ECHO (DISCARD) yolu etkinleştirilir.

Vesaire.

Sunucu TELNET bir etkileşimden sonra kesme eylemini veya kesme sınıflarını değiştirebilir, ancak normalde bunu MTB veya DTB komutlarını göndermeden önce yapmalıdır. Bir MTB (DTB) komutunu yalnızca önceki iletiden gelen tüm süreç çıktıları gönderildikten sonra göndermelidir.

Bu Neden Çalışır?

Yukarıda açıklanan RCE stratejisi, kullanıcının terminalinde doğru sonucu üretir; çünkü özünde, hizmet verilen sitede normalde yankılamayı sağlayan Terminal Handler tarafından kullanılan düzenlemenin aynısıdır. Başlangıçta karakterler yazıldıkları anda yankılanır; ardından bir kesme karakteri tuşlanır ve yankılama askıya alınır. Süreç herhangi bir çıktı yanıtı üretirse, bu, sonraki girdinin yankılanmasından önce yazdırılır.

Bir sonraki komutun yankılanması, eğer önceden yazılmış karakterler varsa, giriş arabelleğindeki karakterlerle başlar ve giriş arabelleği boşaltılsa bile, ECHO yolu bir kesmeye kadar etkin kaldığından, terminalden tuşlanan girdinin anında yankılanması sağlanır.

Bir Örnek

(Aşağıda, tüm kesme karakterlerinin aynı zamanda uyandırma karakterleri olduğunu varsayıyor ve (dikkatsizce) bu ikisini birbirinin yerine kullanıyoruz.)

Bir TIP kullanıcısının, uygun biçimlendirilmiş mesajla uzak bir sunucuya giriş yapmaya çalıştığını varsayalım:

LOG NAME PASSWORD [CR]

ve Sunucu TELNET'in RCE kullanımını talep ettiğini düşünelim. Kesme (ve uyandırma) karakter kümelerinin boşluk ve CR'yi içerecek şekilde uygun biçimde tanımlandığını (ve kesme eyleminin bunların yankılanmasını belirttiğini) varsayarsak, TIP'i kullanıcının terminalinde doğru çıktıyı üretmeye yönlendirecek temel RCE komutları dizisi şudur:

MTB ("LOG " yazdırmak için) ve boşluk bir kesme karakteri olduğundan,
MTB ("NAME " yazdırmak için),
DTB ("PASSWORD [CR]" öğesini silmek için (bkz. Bölüm VI, madde 11)) ve muhtemelen ardından bir mesaj,
MTB (yankı yolunu yeniden etkinleştirmek için).

Süreç/Sunucu TELNET arayüzündeki etkileşimin bu komutların TIP'e gönderilmesine nasıl neden olduğunu biraz ayrıntılı olarak inceliyoruz.

EXEC çağrıldığında, kesme sınıflarını ayarlamak için bir sistem çağrısı yapar. Sunucu TELNET bu sistem çağrısını RCE tarafından desteklenen sınıflar cinsinden yorumlar ve uygun iki baytlık "Set Break Classes" (SBC) komutunu TIP'e gönderir. Boşluk, kesme kümesindeki karakterler arasındadır.

EXEC girdi ister, bu nedenle Sunucu TELNET MTB gönderir (yukarıdaki (1)). EXEC'in, bazı girdiler kullanılabilir olana kadar bloke olduğunu varsayıyoruz.

İlk boşluk geldiğinde EXEC uyandırılır; LOG komutunu LOGIN alt sistemine bir çağrı olarak tanır ve bunu (derhal!) çağırır.

LOGIN süreci kesme sınıflarını ayarlamak için bir sistem çağrısı yapar (bu kez hem boşluk hem de CR dahildir ve daha önce olduğu gibi Sunucu TELNET komutu bir SBC olarak iletir). Ardından girdi ister (dolayısıyla Sunucu TELNET MTB gönderir (yukarıdaki (2))) ve ikinci boşluk gelene kadar bloke olur.

LOGIN süreci NAME adlı bir kullanıcı varlığını doğruladığında, bir sonraki parametrenin (parolanın) yazdırılmasını bastırmak için bir sistem çağrısı yapar. Buna uygun olarak Sunucu TELNET DTB gönderir (yukarıdaki (3)).

Parola incelenip doğrulandıktan sonra, şu türden bir mesaj:

[CR][LF] LOGIN COMPLETED [CR][LF]

gönderilebilir ve ardından girdi isteği gelir. Sunucu TELNET böylece bir MTB iletir (yukarıdaki (4)) ve dizi tamamlanır.

Başka Bir Örnek

Yukarıdaki örnekte kullanıcının şu girişi yaptığını varsayalım:

LOG NAME[CR]

[LF]password =

gönderebilirdi; Sunucu TELNET bunu (LOGIN yazdırma bastırma istediğinde) DTB ile izlerdi. TIP çıktısını tamamladığında, DISCARD yolu etkinleştirilir ve kullanıcının terminali şunu yazdırmış olurdu:

LOG NAME[CR]
password =
           ^

imleç = işaretinin hemen arkasında konumlandırılmış olarak. TIP parola karakterlerini gizler.

Başka Bir Örnek

Bir kullanıcının İngilizce cümlelerden oluşan bir kaynak dosyası üretmek için TEXT adlı bir metin düzenleyici kullandığını varsayalım. TEXT alt süreci, kesme karakterleri olarak yalnızca biçimlendirme dışı denetim karakterlerine (örneğin, "Control-C") izin verebilir. RCE stratejisi, kullanıcı böyle bir denetim karakteri yazana kadar tüm girdisi için anında yankılamayı almasına olanak tanır.

V. Tartışma

Uzaktan Denetimli Yankılama Stratejisi, tam çift yönlü bir terminal için, sanki sunucusuna yerel olarak bağlıymış gibi yankılama sağlamak üzere tasarlanmıştır. Uzun iletim gecikmelerinin etkisi yalnızca bir kesmede gerçekleştirilen işlemenin artması olarak ortaya çıkar. Yalnızca en etkileşimli sistemlerde böyle bir gecikme sürekli olarak fark edilebilir. Örneğin, bir kullanıcı uzun bir FORTRAN derlemesi başlatırsa, başlangıcının yarım saniye gecikmesi normalde fark edilmeyecektir.

Ayrıca, birkaç iletinin önceden yazılmasına olanak tanıyan kullanıcılar, yalnızca ilk kesme etkileşimi sonucunda bir işleme gecikmesi fark edebilir; ardışık iletilerin hem iletimi hem de işlenmesi, önceki iletilerin yankılarının ve yanıtlarının yazdırılması sırasında gerçekleşebilir.

İletimle İlgili Hususlar

Standart yankılama düzeninde, karakterler tuşlandıkları sırada aynı sunucuda arabelleğe alınır. Ancak kullanıcı süreci, bir uyandırma karakteri yazılana kadar bunları görmez. Bu, RCE kullanan bir TIP'in, bir uyandırma gerçekleşene kadar karakterleri iletim arabelleğinde biriktirip ardından hepsini birden gönderebileceği anlamına gelir. Ne yazık ki basitlik adına, uyandırma karakterleriyle ilgili tüm bilgiyi hizmet verilen sitede tutmayı seçtik. Bu, TIP'in (eğer aynı zamanda bir kesme değilse) bir uyandırmanın ötesinde arabelleğe alabileceği ve sürecin bazı yararlı işleri yapmasını geciktirebileceği anlamına gelir. Ancak bu durumda süreçten herhangi bir çıktı beklenmediğinden, kullanıcıya fark edilir bir gecikme görünmez; yalnızca bir sonraki kesme etkileşimi biraz daha uzun sürebilir.

TIP iletimden önce girdiyi arabelleğe almayı seçerse, en azından her kesme karakterinde iletim yapacaktır. Sunucu, uygun olduğunda TIP'e daha sık iletim yapmasını söyleyebilmelidir.

Bir Örnek

Konuşmalı çıktı bağlama, iletim stratejisinin kesme ve uyandırma stratejilerinden ayrı olduğu bir örnektir. İletim her karakterde gerçekleşmelidir ki karakter her bağlı terminalde derhal yazdırılabilsin; ancak özel bir kaçış karakteri yazılana kadar herhangi bir kesme veya uyandırma gerçekleşmesi gerekmez (bu, örneğin EXEC'i yeniden uyandırır).

Konuşmalı çıktı bağlama ayrıca başka bir konuyu da gündeme getirir.

Kendiliğinden Gelen Çıktı

ECHO (veya DISCARD) yolu etkinleştirilmişken giriş arabelleği boşsa (yani anında yankılama gerçekleşiyorsa) ve çıkış arabelleğine bir şey gelirse ne olur? Bu "şey", daha önce tuşlanmış bir komuta yanıt olamaz; çünkü öyle olsaydı ECHO yolu devre dışı bırakılmış olurdu. (Bu ispat okuyucuya bırakılmıştır!) Büyük olasılıkla bu, şu türden bir sistem iletisidir:

[CR][LF]SYSTEM WILL GO DOWN IN 5 MINUTES[CR][LF]

veya başka bir bağlı terminalden gelen bir karakterdir.

Bu tür bir çıktı RCE düzenimize tam olarak uymadığından, aşağıdaki geçici çözüm önerilmektedir. Kendiliğinden gelen çıktı, OUTPUT yolunun etkinleştirilmesine neden olmalıdır. Bir MTB (DTB) oluşması ya da çıkış arabelleğinin boşalması, ECHO (DISCARD) yolunu yeniden etkinleştirir.

IV. Ortogonal Konular

TELNET'e önerilen bu ek içinde makul biçimde yer alabilecek birkaç başka mekanizma vardır. Daha fazla tartışma gerektiren sorunlar şunları içerir:

Sunucunun giriş, iletim, yazdırma ve çıkış arabelleklerini temizleyebilmesi için bir araç sağlanmalıdır.
Kullanıcının çıkış arabelleğini derhal temizleyebilmesi (yani uzun çıktının yazdırılmasını bastırabilmesi) için bir araç sağlanmalıdır.
Sunucu, yazdırılmayı bekleyen karakter sayısını sormak isteyebilir.
Giriş arabelleğinin nerede temizlendiğini belirtmek için özel bir etiket karakteri gerekebilir.
TIP'in iletim stratejisi sunucu tarafından belirtilebilir olmalıdır; belki bir "Set Wakeup Classes" komutu uygulanmalıdır.
Sunucu, karşılaşılan herhangi bir kesme karakterinden bağımsız olarak TIP'in n'inci giriş karakterinde kesme yapmasına neden olabilmelidir.
TAB gibi bir biçimlendirme denetim karakterinin doğru biçimde yankılanmasından TIP mi yoksa sunucu mu sorumlu olmalıdır?
ASCII karakterlerinin uygun eşdeğerlik sınıfları nihai hale getirilmelidir.
Bir CR nasıl yankılanmalıdır?
TIP tarafından bire bir yankı değiştirme (örneğin, ESC için "$"), yoksa çok karakterli ikame (örneğin, Control-A için "^A") mi sağlanmalıdır?
Önerilen DTB komutu, ayırıcı kesme karakterinin de atılmasını TIP'e yönlendirir. Kesme karakterinin atılması, DTB gönderilmeden önce Break Action'ın "don't echo" olarak ayarlanmasına mı bağlı olmalıdır?

Bu sorunların birkaçı RFC 358'de ele alınacaktır.

VII. Sonuç

Bu belge, User TELNET'e önerilen isteğe bağlı bir ek sunmuştur. Bir sonraki adım, bazı simülasyonlar yapmak ve RCE'yi TELNET'in deneysel bir sürümüne dahil etmektir.

Mevcut TELNET'in terk edilmesi yönünde herhangi bir öneri yapılmamaktadır. Örneğin, kendi yankılamasını yapan yarı çift yönlü aygıtlar için RCE kullanılmamalıdır. RCE yankılamanın alternatif bir yolu olarak benimsenirse, bunu uygulamayı seçmeyen TELNET'lerde yapılacak değişiklikler asgari düzeyde olmalıdır. RCE'den mevcut yankı mekanizmasına geçiş, kullanıcı ya da sunucunun bir "You Echo" (veya "I'll Echo") göndermesinin anında bir sonucudur.

RCE'yi uygulamak için gereken düzeneklerin büyük bir kısmı, sunucu süreci ile onun Terminal Handler'ı veya Sunucu TELNET'i arasındaki arayüzde zaten mevcuttur. Bu, hiçbir sunucu sürecinin değiştirilmesine gerek olmadığı, ancak sürecin kesme sınıflarını, kesme eylemlerini ve yankılama kurallarını belirtme yöntemlerinin Terminal Handler tarafından yorumlanıp karşılık gelen RCE komutları cinsinden TIP'e yeniden gönderilmesi gerektiği anlamına gelir.