@TRANSMIT EVERY #, biriktirilmekte olan iletinin mümkün olduğunca her #’inci karakterde gönderilmesine neden olmaya devam edecektir. Ancak, # için giriş arabelleğinin boyutundan daha büyük değerler verilmesi, arabellek neredeyse dolu olduğunda iletimin yapılmasına yol açacaktır; ve # için 0 değeri verilmesi, terminali başlangıç ayarına döndürecektir — TRANSMIT-ON-LINEFEED modu kapalı, TRANSMIT ON MESSAGE-END modu kapalı ve her karakterde iletim. Böylece TRANSMIT EVERY 0, kaldırılan @TRANSMIT ON NO CHARACTER komutunun etkisine sahip olacak, @TRANSMIT EVERY 1 ise kaldırılan @TRANSMIT ON EVERY CHARACTER komutunun etkisine sahip olacaktır.

Önerilerinizi ve şikâyetlerinizi mektuplar ve telefon dışında bize iletmenin iki yolu vardır: BBN-TENEX’e giriş yapıp WALDEN’a SNDMSG göndermek ya da NIC Journal sistemini kullanarak DCW3’e bir mesaj göndermek. Bu arada, Dave en çok mektupları seviyor.

TIP’in HELLO mesajındaki "NEWS" duyurusunu kaldıracağız. Sorun şudur: Herkesin en son haberleri ne zaman okuduğunu bilmiyoruz; dolayısıyla duyuruyu ne zaman kapatacağımızı da bilmiyoruz. Bu nedenle kapatamıyoruz. Bu nedenle de işe yaramaz. TIP’i her kullandığınızda NEWS’i kontrol edin. Haberler yazdırılmaya başladıktan sonra bunu zaten gördüğünüzü fark ederseniz, @CLOSE LF yazarak durdurabilirsiniz (2741 üzerinde önce "attention" tuşuna basın).

Bu mektubu aldığınız zamana kadar yeni bir TIP mesajı eklenmiş olacaktır; mesajın adı TIP GOING DOWN. Bu mesaj, TIP önleyici bakım, yeni yazılım sürümleri vb. için kapatılmadan kısa bir süre önce her TIP terminalinde yazdırılacaktır (bu konunun daha ayrıntılı tartışması için RFC #381’e bakınız). Bu mesaj yazdırıldığında, tüm TIP kullanıcıları bir Host ile yaptıkları işlemleri temiz bir şekilde durdurmalıdır. Zamanla bu mesaj, TIP’in ne kadar süre sonra kapanacağı, ne kadar süre kapalı kalacağı ve nedeni hakkında bilgileri içerecektir.

TIP mesajları konusuna girmişken, TIP’in ne yaptığına dair mevcut bazı karışıklıkları gidereceğine inandığımız bir dizi yeni mesaj ekleyeceğimizi belirtelim. Ne yazık ki mesaj metin dizgelerini saklamak için yeterli alanımız yok; bu nedenle yeni mesajlar için numaralar kullanacağız. Bu mesajların biçimi muhtemelen 46 numaralı mesaj için M46 gibi bir şey olacaktır. Belki TIP’ler daha fazla çekirdek belleğe sahip olduğunda, numaralı mesajları metinli mesajlarla değiştirebiliriz.

Tüm TIP LOGIN komutlarını, CLOSE komutlarına daha karşıt olan ve Host LOGIN ile karışmaya daha az müsait OPEN komutlarıyla değiştirmeyi düşünüyoruz.

TUG’un 12. sayfasında Host’ların bir TIP terminaline nasıl komut gönderebileceğine dair bir açıklama bulunmaktadır. Bu özelliği kullanmaya karar verirseniz uyaralım: TIP komut dilini yavaş yavaş değiştiriyoruz ve bazı Host’ların TIP komutları gönderiyor olması bu değişikliklerde bizi kısıtlamayacaktır. Bu nedenle, bir Host bir TIP’e komut gönderecekse, bunu kolayca değiştirilebilecek bir şekilde uygulamalıdır.

Bazı TIP kullanıcıları aşağıdaki sorunu yaşamaktadır. Bir Host ile iletişim hâlindeyken aniden DEAD mesajını alırlar. Host’a tekrar LOGIN etmeye çalışırlarsa DEAD mesajını almazlar; ancak Host ya hiçbir şey yapmayarak, bağlantıyı kapatarak ya da reddederek LOGIN’e izin vermez. Sorun, zaman zaman ağın kısa süreliğine bölünmesiydi; örneğin, iki kıtalararası hattan biri kapalıydı ve diğeri birkaç saniye boyunca kararsız hâle geldi. Ağın bölündüğü bir dönemde bir TIP kullanıcısı ulaşılamayan bir Host’a mesaj gönderirse, TIP DEAD yazar ve Host ile olan bağlantıyı kapatır. Öte yandan Host, ağ bölündüğünde TIP’e gönderim yapmaya çalışmıyor olabilir; bu durumda ağın bölündüğünü fark etmemiş ve dolayısıyla TIP ile hâlâ açık bir bağlantısı olduğunu düşünüyor olabilir. TIP daha sonra Host’a yeniden LOGIN etmeye çalıştığında, Host, o belirli TIP aygıtıyla zaten açık bir bağlantısı olduğu için reddeder.

Artık üç bağımsız kıtalararası yolumuz olduğundan bu sorunun sıkça ortaya çıkmasını beklemiyoruz; ancak olursa kısa vadeli bir çözüm göremiyoruz. Bir CLOSE’un bağlantıyı sıfırlamasına izin veremeyiz; çünkü kullanıcının hemen önceki LOGIN’i, Host tarafından sağlanan soket numaralarını yok etmiştir. Bu durumdan çıkmanın bir yolu, TIP’ten Host/Host protokol komutunu yürütmektir; bu komut, verilen TIP’teki, verilen Host ile konuşan tüm TIP kullanıcılarını sıfırlar; ancak bu biraz kaba bir çözümdür. Muhtemelen gereken şey, Host’un belirli bir kullanıcı (TIP) soketiyle olan bağlantılarını sıfırlayan bir Host/Host protokol komutudur; böyle bir komutun sonuçlarını anlamaya çalışacağız ve belki bir Host/Host protokol değişikliğinin desteklenmesini üstleneceğiz. Bu arada, yukarıdaki sorun sıklıkla ortaya çıktığında, başka bir TIP terminali hâlâ Host’a LOGIN edebilir ve ardından Host tarafından asılı kalmış terminalin işini durdurabilir. Başka bir bağlantı üzerinden geçmek mümkün değilse, Host’u arayıp işin kapatılmasını istemek gerekebilir. Ya da gerçekten o belirli Host ile konuşan başka hiçbir kullanıcı yoksa, sıfırlama komutu yürütülebilir — bu komut belgelenmemiştir, ancak her TIP sitesindeki sorumlu bir kişiye komutun nasıl yürütüleceğini anlatacağız.

Yukarıdaki sorunla ilişkili bir başka sorun da bazı TIP kullanıcıları tarafından görülmüştür. Zaman zaman, ağın bir yerinde bir IMP çöker ve bir mesajın bir paketini de beraberinde götürür. Sonunda, mesajın kaynağı ağdan eksik iletim bildirimi alır. TIP bu mesajı aldığında bağlantıyı kapatır ve hedefi dead olarak işaretler. Anladığımız kadarıyla, diğer Host’ların çoğu da aynı şeyi yapmaktadır. Daha makul bir yaklaşım, mesajı yeniden iletmek ya da kullanıcıyı bilgilendirip devam etmesine izin vermek olabilir; bunlardan birini yapmak isteriz. Ancak yeniden iletimden veya kullanıcının devam etmesine izin vermeden önce, TIP ile Host’un allocate sayaçlarının yeniden senkronize edilmesi gerekir. Ne var ki, TIP’in kullanabileceği kadar basit bir senkronizasyon yöntemi Host/Host protokolünde yoktur. Gerekli olan şey, basit bir Host/Host protokolü allocate sıfırlama komutu olabilir. Bu konuyu anlamaya çalışacağız ve yine belki bir Host/Host protokol değişikliğinin desteklenmesini üstleneceğiz.

Yukarıdaki iki sorun, "kayıp allocate"lerin bir kısmını açıklamaktadır, ancak tamamını değil. TIP programını, kalan kayıp allocate sorununu yakında bulmamıza yardımcı olacağını umduğumuz bir şekilde enstrümante ettik.

TIP’in logger’ı (opener?) kullanıcılara bazı sorunlar yaşatmaktadır. İnceleme sonucunda, sorunların logger içindeki temel tasarım varsayımlarından kaynaklandığı görüldü ve bunları değiştirmek üzerinde çalışıyoruz. Ancak kısa vadede, logger’ın ne yaptığını ve nasıl çalıştığını tartışmanın, yaşanan sıkıntıların bir kısmını azaltacağını düşünüyoruz.

Kullanıcı açısından, açma işlemi üç aşamada ilerler. Birincisinde, kullanıcı TIP’in logger’ını "alma"yı beklerken kuyruğa alınır. İkincisinde, kullanıcı TIP’in logger’ını almıştır ve login dizisini başlatmaktadır. Üçüncüsünde, kullanıcı login dizisini tamamlamış ve Host’un gerçek veri bağlantılarını açmasını beklemektedir. Sorunların çoğu, aynı anda yalnızca bir kullanıcının 2. aşamadan geçebilmesinden kaynaklanmaktadır. Dolayısıyla 1. aşama kuyruğuna ihtiyaç vardır. Herhangi bir tek kullanıcı, 2. aşamayı en fazla yaklaşık 1 dakika boyunca meşgul edebilir. Bu, logger’daki kanonik "timeout" süresidir. Bunun, birinci veya üçüncü aşamalardaki süreleri içermediğine dikkat edin. Dolayısıyla @L yazdıktan sonra bir "timeout" alana kadar geçen gerçek gecikme, aynı anda kaç kişinin giriş yapmakta zorlandığına bağlı olarak 1 dakika, 2 dakika, 3 dakika... olabilir.

Abort Login (@A L), kullanıcının login sürecinin hangi aşamasında olduğuna bağlı olarak üç farklı şey yapar. 2. aşamada zamanlayıcıyı taşmaya yakın bir değere sıfırlar, böylece komut verildikten kısa süre sonra bir "timeout" ile yanıtlanır. 3. aşamada hiçbir şey yapmaz ve 1. aşamada ise kullanıcıyı (sessizce) login kuyruğundan çıkarır.

Orta vadede, kuyruktan çıktığınızda ve logger bağlantılarınızı açmaya çalışmaya başladığında TIP’in "YOUR LOGGER" gibi bir şey yazmasını sağlayacağız. Bu, en azından kullanıcının 1. aşamada mı yoksa 2. aşamada mı olduğu konusundaki belirsizliğini azaltacaktır. Uzun vadede ise muhtemelen login sürecini yeniden girişli (reentrant) hâle getireceğiz; böylece kullanıcılar birbirleriyle bu kadar yıkıcı biçimde etkileşmeyecektir. Kısa vadede ise, çalışmıyor gibi görünen bir login’i geri almak için küçük bir "yemek tarifi" aşağıdadır.

Login işleminin gerçekleşmesi için beklemek istediğiniz kadar bekledikten sonra "@A L" yazabilirsiniz. TIP birkaç saniye içinde "TIMEOUT" ile yanıt verir ve T OPEN veya R OPEN yazmamışsa, iptal edilmişsiniz demektir ve yeniden giriş yapmayı deneyebilirsiniz. "TIMEOUT" yazıyor ancak T OPEN veya R OPEN yazmışsa, @C yazmalı ve bunun yanıtlanmasını beklemelisiniz (beklemeniz şarttır). @A L komutuna hiç yanıt almazsanız ve TIP bağlantılardan birinin ya da diğerinin açık olduğunu yazmışsa, yine yukarıdaki gibi @C yazmalı ve beklemelisiniz. Son olarak, TIP hiçbir yanıt vermez ve hiçbir bağlantı açmamışsa, devam etmekte serbestsiniz.

Bundan sonra DEVICE CODE EXECUPORT komutunun adı DEVICE CODE EXTRA-PADDING olacaktır; çünkü bu özelliğe ihtiyaç duyan başka birçok terminal vardır. Listeye en son eklenen terminal DATAPOINT 3300’dür.

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