← rfc/
╔══════════════════════════════════════════════════════════════════════════╗
RFC 441 · general

Varlıklar Arası İletişim — Bir Deney

Yazar
Kurum
Tarih
19 Ocak 1973
Durum
Network Working Group Yorum Talebi
Kanal
general/

Ağ Çalışma Grubu

Yorum Talebi: 441
NIC: 13773
Yazarlar: Bob Bressler, Bob Thomas
Tarih: 19 Ocak 1973

Varlıklar Arası İletişim — Bir Deney

Bu not, kullanıcıların kendi konsollarında birbirleriyle konuşma ve belki de hata ayıklama yardımı alma isteğine dayanan bir deneyle ilgili bir durum raporu olma girişimidir. Kullanıcı şu soruları sorabilir: "kiminle konuşabilirim"; "yaptıklarımı ona gösterebilir miyim" ve "programımı çalıştırmasına izin verebilir miyim?" Birçok zaman paylaşımlı sistem, kendi sistemlerinin sınırları içinde bu tür yetenekler sağlar. Hemen hemen tüm sistemlerde bir "WHO" veya "SYSTAT" bulunur, birçoğunda "LINK" veya "TALK" gibi komutlar vardır ve bazıları başka bir kullanıcının programını denetlemek gibi daha alışılmadık yetenekleri destekler. Ağ Çalışma Grubu’nun Ekim 1971’de MIT’de yapılan son resmi toplantısında, bir grup bu özellikleri Varlıklar Arası İletişim (IEC) için ve bunların Ana Bilgisayar sınırlarının ötesine nasıl genişletilebileceğini tartışmak üzere bir araya geldi.

Sonraki geliştirme, plansız bir biçimde ilerlemiştir. Genel tasarım felsefesi, hem sunucu hem de kullanıcı programlarına sahip olma açısından TELNET’inkiyle paralellik göstermiştir. Sunucu programı, "FOO kullanıcısına bağlan", "BAR kullanıcısı nerede" veya "sisteminizde kimler var?" gibi komutları ele alacaktı. Sunucu ve kullanıcıdan oluşan ilk bir gerçekleştirim, tamamen keyfi bir protokol kullanılarak MIT-DMCG’de devreye alındı. Kısa bir süre sonra, yararlılığını artırmak amacıyla protokol, BBN-TENEX’te geliştirilmekte olan Resource Sharing Executive tarafından kullanılan protokolle uyumlu olacak şekilde değiştirildi.

MIT kullanıcı programı, bir nesneye giren ve çıkan karakter akışlarını tanımlamaya yardımcı olmak için "portlar" kavramını kullandı. Aşağıda, bir kullanıcı teletypesini, onun işini ve konuşmakta olduğu iki danışmanı gösteren bir görsel diyagram (Şekil 1) yer almaktadır.

              +------+
              | USER |
              | TTY  |
              +------+
                |   |
   -------------|---|--------------+
                |   |              |               +-------+
        +------------------+       |               | HOST  |
        |     COMMAND      |       |               |   A   |
        |   INTERPRETER    |       |               +-------+
        +---+-+-------+-+--+       |                   |
        TTY |_|       |_| TTY      |                   |
    OUT-PORT ^         | IN-PORT   |                   |
             |         |           |                   |
             |         V           | +--------------+  |
                                 +-|-+              |  |
                            <----| |IN-PORT         |--+
                                 +-|-+              |
                                   | |  CONSULTANT  |
                                   | |     #1       |
                                 +-|-+              |
               I.E.C.         ---->| |OUT-PORT      |
                                 +-|-+              |
                                   | +--------------+
                                   |
                                   | +--------------+
                                 +-|-+              |
                            <----| |IN-PORT         |--+
                                 +-|-+              |  |
                                   | |  CONSULTANT  |  |
                                   | |     #2       |  |
                                 +-|-+              |  |
           ^          |     ---->| |OUT-PORT        |  |
           |          |          +-|-+              |  |
   JOB     |          V  JOB       | +--------------+  |
   IN-PORT+--+       +--+OUT-PORT  |                   |
     -----|--|-------|--|----------+                   |
     +----+  +-------+  +---------+                    |
     |                            |                 +------+
     |      USER     JOB          |                 | HOST |
                                                    |  B   |
                                                    +------+

Kullanıcı artık istediği portu açma veya kapatma seçeneğine sahiptir. Konuşma modundayken, JOB’a giden portları kapatabilir. Danışman 1’in işi denetlemesini isterse, kendi TTY’sinden ve danışman 2’den gelen giriş portlarını kapatabilir.

Bu hedef doğrultusunda, kullanıcı arayüzü aşağıdaki komut kümesini sağlar:

Yukarıdaki açıklama MIT-DMCG’deki programa uygulanmaktadır. Benzerleri yakında diğer ITS sistemlerinde de kullanılabilir olacaktır.

TENEX’te, kullanıcı arayüzü RSEXEC alt sistemi aracılığıyladır. Kullanıcıya göre RSEXEC, standart TENEX EXEC’e çok benzer, ancak yalnızca yerel sistemle sınırlı değildir. PORT kavramı dışında, komut yapısı daha önce açıklanana benzerdir:

@ WHERE   (is user) THOMAS

          Thomas kullanıcısının her bir "şu anda etkin" işini listeler.
          Her iş, ağ sitesi, iş kimliği ve bağlı
          terminaller ile tanımlanır.

@ SITES   (of user) BRESSLER

          Bressler kullanıcısının hesabının bulunduğu
          tüm (şu anda erişilebilir) ağ sitelerini listeler.

@ LINK    (to TTY0 103 (AT SITE) UTAH-10

          Kullanıcının terminalini UTAH PDP-10’daki
          106 numaralı terminale bağlar.

@ WHO     Her bir (erişilebilir) ağ sitesinde şu anda
          oturum açmış kullanıcıları listeler.
          (WHO, seçili siteleri belirtmek için seçeneklere sahiptir.)

Yukarıdaki hizmetleri tamamlayıcı olarak, TENEX RSEXEC programı bir dizi dosya sistemi aracı sağlar. Bu hizmetlerin FTP türü protokollerle bütünleştirilmesi ve TENEX olmayan diğer sistemlerde de kullanılabilir hale getirilmesi planlanmaktadır.

Bu deney için 245 numaralı soket (ondalık) atanmıştır. Yukarıda belirtildiği gibi, bu hizmetler şu anda (ya da çok yakında) birçok ITS ve TENEX sisteminde kullanılabilir durumdadır. Buna ek olarak, bu hizmetlerden en az biri oturum açma gerektirmeyen bir temelde sunulacaktır. Bu, TIP kullanıcılarının bu iletişim olanaklarından yararlanabilmesini sağlayacaktır.

Bu deneye daha fazla katılım elbette davet edilmektedir. Bu tür bir hizmetin ağ gelişiminde önemli bir rol oynayabileceği umulmaktadır. Siteler, bu deneyin "konferans" olanaklarını denemeye davet edilmektedir. Karşılaşılan sakıncaların neler olduğunu bilmek isteriz. Protokol tasarımı esnek kalacaktır ve kullanım sırasında ortaya çıkacak eksiklikleri karşılamak üzere genişletilebilir. Deney alanları arasında posta protokolüyle bütünleştirme, konferans zamanlama ve grafik kullanıcılarının ekranları paylaşabilmesi için resim odaklı bir grafik protokolünün dahil edilmesi yer almaktadır.

Ekli olarak, şu anda kullanılan protokolün bir kopyası bulunmaktadır. İlk bakışta PDP-10 olmayan sistemlere karşı olumsuz görünebilir, ancak bu kasıtlı değildir. Yeni ve daha genel bir protokol geliştirilmektedir; ancak bu protokol çalışır durumda olduğundan, onu kullanmayı denemenin yararlı olduğu düşünülmektedir.

Geçici Protokol

RSEXEC protokolü iki bölümden oluşur:

  1. Bir kullanıcı programının sunucu programına nasıl bağlandığını belirten bir ilk bağlantı protokolü.
  2. Kullanıcı sürecinin hizmet almak için sunucu süreciyle nasıl konuştuğunu belirten bir komut protokolü.

İlk Bağlantı Protokolü

Sunucuya bağlanmak için kullanıcı süreci 365 (sekizlik) numaralı sokete bağlanır, bağlantı bayt boyutu = 32. Sunucu programı daha sonra iki bayt iletir ve bağlantıyı keser:

Sunucu ve kullanıcı programları, iki adet 36 bitlik "çalışma" bağlantısı açarak ICP’yi tamamlar:

burada U = kullanıcı programının ICP’yi başlatmak için kullandığı sokettir.

İki çalışma bağlantısı kurulduktan sonra sunucu komutları kabul etmeye hazırdır.

RSEXEC ICP’nin, tek farkın işlem numarasının iletilmesi olması dışında, resmi ARPANET ICP ile neredeyse aynı olduğuna dikkat ediniz.

Komut Protokolü

Terminoloji notu:

USINF

Sunucunun sitesindeki bir kullanıcı hakkında bilgi almak için:

  1. Kullanıcı gönderir:

    • Bayt 1: ASCII /USINF/
    • Bayt 2→k: ASCIZ /USERNAME/
  2. Sunucu yanıtlar:

    • Olumsuz onay: 1 bayt = XWD 0, hata # ; böyle bir kullanıcı yok
    • Olumlu onay:
      • Bayt 1: -1
      • Bayt 2→n: XWD iş #, tty #
        burada tty # = iş ayrılmışsa -1
      • Bayt n+1: -1

SSTAT

Sunucunun sitesindeki etkin kullanıcıları almak için:

  1. Kullanıcı gönderir:

    • Bayt 1: ASCII /SSTAT/
  2. Sunucu yanıtlar:

    • Olumsuz onay: 1 bayt = 0
    • Olumlu onay: 1 bayt = -1, ardından aşağıdaki biçimde veri blokları gelir:
      • a. 1 bayt = -1 ; iletimin sonu anlamına gelir
      • veya
      • b.
        • Bayt 1: XWD iş #, tty #
        • Bayt 2: SIXBIT /altsistem adı/
        • Bayt 3→n: ASCIZ /USERNAME/

Sunucu sitesindeki bir kullanıcı terminaline bağlanmak için:

  1. Kullanıcı gönderir:

    • Bayt 1: ASCII /LINK/
    • Bayt 2: terminal #
  2. Sunucu yanıtlar:

    • Olumsuz onay: 1 bayt = 0
    • Olumlu onay: 1 bayt = sayı N ; sunucunun bağlantıyı deneyeceği anlamına gelir
  3. Olumlu onaydan sonra, sunucu ve kullanıcı iki adet 8 bitlik bağlantı kurmaya çalışır:

    • N + 1 --> U
    • N --> U + 1

    burada U, kullanıcının ICP’yi başlatmak için kullandığı sokettir.

    Bu bağlantılar, sunucu sitesindeki bağlı tty’ye giden ve oradan gelen metni taşımak için kullanılacaktır.

  4. Sunucu (ikinci kez) yanıtlar:

    • Olumsuz onay: 1 bayt = 0 ; bağlantıların kurulamadığı veya bağlantının yapılamadığı anlamına gelir
    • Olumlu onay: 1 bayt = -1 ; tty’ye bağlantının kurulduğu ve bağlantılar üzerinden iletilen her şeyin bağlı tty’ye gideceği anlamına gelir

BREAK

Sunucu sitesindeki bir terminale daha önce kurulmuş bir bağlantıyı kesmek için:

  1. Kullanıcı gönderir:

    • Bayt 1: ASCII /BREAK/
  2. Sunucu yanıtlar:

    • Olumsuz onay: 1 bayt = XWD 0, hata #
    • Olumlu onay: 1 bayt = -1 ; bağlantı başarıyla kesildi

TERMINATE

Sunucuyla olan bağlantıyı sonlandırmak için kullanıcı ya tek bir bayt = 0 gönderebilir ya da sadece bağlantıları kapatabilir. İlki tercih edilir. Sunucu, bağlantıları keserek yanıt verir.

Bu RFC, çevrimiçi RFC arşivlerine giriş için makine tarafından okunabilir biçime Hélène Morin, Viagénie tarafından 12/99 tarihinde dönüştürülmüştür.