← rfc/
╔══════════════════════════════════════════════════════════════════════════╗
RFC 327 · meet

Veri ve Dosya Aktarımı Çalıştayı Notları

Yazar
A. Bhushan
Kurum
MIT-MAC
Tarih
27 Nisan 1972
Durum
Network Working Group Yorum Talebi
Kanal
meet/

Ağ Çalışma Grubu

Yorum İsteği (Request for Comments): 327
NIC: 9261
Yazar: A. Bhushan
Kurum: MIT-MAC
Tarih: 27 Nisan 1972

Veri ve Dosya Aktarımı Çalıştayı Notları

14 ve 15 Nisan 1972 tarihlerinde, Massachusetts, Cambridge’de M.I.T.’de bir Veri ve Dosya Aktarımı Çalıştayı düzenlendi. Toplantının 14 ve 15 Nisan günlerine ait katılımcı listesi notların ekinde yer almaktadır. Bu not, çalıştay toplantısında ele alınan konuların çoğunu ve varılan tüm kararları özetlemeyi amaçlamaktadır.

Aşağıda, 14 Nisan 1972 tarihinde yapılan konuşma ve tartışmaların bir özeti sunulmaktadır.

14 Nisan 1972 — Konuşmalar ve Tartışmalar

Steve Crocker, Ağ protokolleri için genel bir kuramı ele aldı. Protokol dönüşümlerinin benzersiz bir tersine sahip olması ve geçişli olması gerektiğini belirtti. Standart bir biçime dönüşüm, standart olmayan durumda gereken n(n−1) dönüşüme kıyasla yalnızca 2n dönüşüm gerektirir (n = farklı ana bilgisayar türlerinin sayısı). n ≥ 3 için standart bir yaklaşım tercih edilir.

Dosya aktarımı için bir Ağ Sanal Dosya İmajı tanımlanabileceği ifade edildi. Dosya yapısı dönüşümleri için yukarıdaki kuralların karşılanıp karşılanamayacağı konusunda bazı tartışmalar yapıldı. Herhangi bir uzlaşmaya varılamadı ve sorun şimdilik bir kenara bırakıldı.

İlerleyen tartışmalar, Çalıştay hedeflerinin aşağıdaki biçimde formüle edilmesine yol açtı:

Maxi-HOST’lar, Mini-HOST’lar, TIP’ler, Datacomputer, RJE ve Mailbox kullanıcıları dâhil olmak üzere ARPANET kullanıcılarının gereksinimlerini karşılayan bir veri ve dosya aktarım protokolü/stratejisi geliştirmek.

Protokoller/Strateji için Hedefler

  1. Verinin bütünlüğünü korumalıdır.
  2. Karakter gösterimi ve yorumunun bütünlüğünü korumalıdır.
  3. Yapısal bilginin bütünlüğünü, pratik olarak mümkün olduğu ölçüde, korumalıdır.
  4. Bir Ağ Sanal Dosya Sistemi’nin geliştirilmesine yol açmalıdır.

Richard Winter, Datacomputer uygulamasını ele aldı. Datacomputer, terminallerden doğrudan kullanılabilir olmakla birlikte, doğrudan terminal kullanıcıları için değil, programlar tarafından kullanılmak üzere mühendisliği yapılacaktır. Datalanguage içinde bir kullanıcı veri ve dosya yapısını ve ayrıca dosya/verinin nasıl aktarılacağını tanımlayabilir. Veri dili kullanılarak tüm dosyalar ya da dosyaların yalnızca ilgili bölümleri aktarılabilir. Aşağıda, Datacomputer’da şu anda öngörülen biçimiyle bir dosya aktarımı örneği verilmiştir.

LOGIN   <user> <password>
CREATE  <file name> <description>
CREATE  <port name> <description>
PORT    <port name> <external name>
<file name> = <port name>   (Datacomputer’a aktarım için)
<port name> = <file name>   (Datacomputer’dan aktarım için)
LOGOUT

(CREATE ifadeleri yalnızca gerekli tanım(lar) Datacomputer’da zaten kayıtlı değilse gereklidir. Bir port tanımı standart bir "external name" belirtebilir; bu da PORT ifadesini isteğe bağlı hâle getirir. "External name", bir HOST-soket belirtimi olacaktır. Veri aktarımı, ağ veri aktarım standartlarına uygun olacaktır. Dosya ve Port tanımları Datalanguage içinde yer alacaktır.)

Alex McKenzie, TIP kullanıcı gereksinimlerini ele alarak TIP’lerin ve TIP terminallerinin mevcut yeteneklerini ve sınırlamalarını tanımladı. TELNET biçimi TIP kullanıcılarının birinci tercihidir; bunu belirsiz bit akışı kipini kullanan DTP izlemektedir. Manyetik teyp sistemlerine sahip iki TIP bulunmaktadır ve bunlar, mevcut DTP’yi (RFC 264) tanımlayıcı sayım kipinde (sıra numarası seçeneğini kullanarak) veri aktarmak için kullanabilmektedir.

Bob Braden, RJS protokolünü ele aldı ve RJS kullanımına ilişkin bazı veriler sundu. NETRJS, CCN iş yükünün %1’ini oluşturmaktadır; bu da son 5 ayda 2.000 işi, 10.000 oturumu ve 1.000 saatlik bağlantı süresini temsil etmektedir. Ortalama iş girdisi yaklaşık 100.000 bit (400 kart), ortalama iş çıktısı ise 700.000 bit (1.000 satır) düzeyindedir. Büyük dosyalar yaklaşık 10 milyon bit içerir ve bu da yaklaşık 8–10 dakikalık iletim süresine karşılık gelir. RJS protokolü, ileride yayımlanacak bir belgede tanımlanacaktır.

Ray Tomlinson, BBN’in TENEX sistemleri arasında dosya aktarmak için kullandığı CPYNET sistemini anlattı. CPYNET komutları, sabit bir sözdizimine sahip ASCII dizgileridir. Bir komut kabul edildikten sonra özgün bağlantı kapatılır ve veri, önceki soket numarası kullanılarak ancak olası farklı bir bayt boyutuyla yeni bir bağlantı üzerinden aktarılır. CPYNET’te elde edilen veri aktarım hızı yaklaşık 10 Kb/s olmuştur.

Abhay Bhushan, ağ protokollerinin değerlendirilmesini ele aldı ve bazı ön ölçüm sonuçlarını sundu. Protokoller için değerlendirme ölçütleri; hız (gerçek zaman gecikmesi ve iletim hızı), verimlilik (CPU zamanı veya maliyet), güvenilirlik (hata oranı ve arıza oranı), kullanışlılık (kullanım ve uygulama kolaylığı) ve kullanım (çeşitli uygulama ve kullanıcı sınıflarına uygunluk) unsurlarını içermelidir.

Belirli sistem koşulları (sabit yük vb.) altında hız ve verimliliği etkileyen parametreler şunlardır:

  1. NCP bağlantısı için kullanılan bayt boyutu.
  2. İletimde kullanılan ortalama mesaj boyutu.
  3. Veri biçimi dönüşümü (örneğin, Network ASCII’ye, DTP Bloklarına vb.).
  4. Kullanılan tampon boyutu ve G/Ç kipi (birim ya da blok kipi vb.).
  5. Diğer protokol kısıtları (onaylama, hata denetimi, bağlantı prosedürü vb.).

Veri ve dosya aktarım protokollerinin, en uygun bayt boyutunu kullanarak ve büyük ek yüke neden olan bazı kısıtları en aza indirerek aktarımı daha hızlı ve daha verimli hâle getirmek üzere nasıl değiştirilebileceği konusunda bazı tartışmalar yapıldı.

DTP ve FTP üzerine yapılan devam tartışmaları, ertesi gün için bir tartışma ve karar maddeleri listesine yol açtı.

15 Nisan 1972 — Alınan Kararlar

  1. Veri ve denetim bilgileri için ayrı bağlantılar kullanılacaktır.

  2. Denetim bağlantısı, ICP aracılığıyla kurulan bir TELNET tam çift yönlü bağlantısı (NVT-ASCII) olacaktır. Veri bağlantıları ise doğrudan kurulan tek yönlü bağlantılar olacaktır.

  3. Dosya Aktarımı ve Dosya Sistemi komutları ile bunların bağımsız değişkenleri, sayısal kodlar yerine yazdırılabilir ASCII dizgileri olacaktır; böylece bir terminaldeki kullanıcı tarafından doğrudan kullanılabilir olacaktır. Ancak etkileşim, programlar tarafından kullanım (dolaylı kullanım) için iyileştirilecektir.

  4. Dosya aktarımında kullanılacak veri bağlantısı için bayt boyutu ve kullanıcı soketi, veri gösterimi ve aktarım kipi; olumlu ya da olumsuz onay gerektiren bir veya daha fazla komut aracılığıyla kullanıcı tarafından seçilebilecektir.

  5. Aşağıdaki veri gösterimleri tüm sunucular tarafından kabul edilecektir:

    1. Network ASCII (8 bitlik alanda 7 bit ASCII, 8. bit sıfır).
    2. Yerel Bayt (veriyi verimli bir biçimde saklamak için bir sunucu seçeneği; saklama şeması iyi biçimde duyurulmalıdır).
    3. İmaj (aktarımı için seçilen bayt boyutundan bağımsız olarak bitlerin bitişik biçimde saklanması gereken bir bit dizisi).
    4. ASCII Yazdırma dosyası (ASCII dosyasını yazdırmaya uygun bir biçime dönüştürür).
    5. EBCDIC Yazdırma dosyası (EBCDIC dosyasını yazdırmaya uygun bir biçime dönüştürür).
  6. Kayıt yapıları serbesttir ancak zorunlu değildir. Dosyasında kayıt yapısı olmayan bir kullanıcı, dosyasını herhangi bir ana bilgisayarda saklayabilmeli veya geri alabilmelidir. Hizmet veren bir ana bilgisayar kayıt yapısını kabul edemiyorsa, bu durumu kullanıcıya bildirmelidir. Veri akışındaki herhangi bir kayıt yapısı bilgisi daha sonra atılabilir.

  7. Aşağıdaki veri aktarım kipleri tanımlanmıştır:

    1. Bayt-Akışı (Byte-Stream) — Dosya sonu, bağlantının kapatılmasıyla belirtilir. Kayıt yapısı yoktur.
    2. Blok — Dosya, önünde bir sayım alanı bulunan bir dizi bloktan oluşur. Dosya sonu, kayıt sonu ve yeniden başlatma işaretlerini belirtmek için uygun araçlar sağlanır.
    3. ASCII — Dosya Network ASCII’dir; kayıt sonu ve dosya sonu, 8. biti bire ayarlanmış özel bir TELNET denetim karakteriyle belirtilir.
    4. CR LF ile ASCII — Dosya Network ASCII’dir; kayıt sonu CR LF ile, dosya sonu ise bağlantının kapatılmasıyla tanımlanır.
    5. HASPl — Kayıt sonu ve dosya sonu bilgileri içeren Hasp sıkıştırılmış dosya.
  8. Kullanıcıyı sistem arızalarına (ana bilgisayarın ya da sürecin sonlanması) karşı korumak için bir yeniden başlatma prosedürü sağlanacaktır. Kayıp ya da karışmış bitler konusu en iyi NCP düzeyinde ele alınır. FTP düzeyinde, depolama ve G/Ç kanalı hataları için standart hata kodları ve yanıtlar sağlanacaktır.

    Yeniden başlatma prosedürü, veri gönderenin veri akışına özel bir işaretleyici eklemesini gerektirir (bu işaretleyici yalnızca gönderici için anlam taşır; bit sayımı, kayıt sayımı veya sayfa sayımı vb. olabilir). Veri alıcısı, kendi sisteminde bu işaretleyicinin karşılık geldiği konumu işaretler ve bu bilgiyi kullanıcıya geri iletir. Bir sistem arızası durumunda, kullanıcı bu bilgiyi bir yeniden başlatma komutuyla sağlayarak aktarımı yeniden başlatabilir.

  9. DTP artık ayrı bir protokol değildir; kullanımı dosya aktarım protokolü tarafından tanımlanan bir aktarım kipleri ya da biçim prosedürleri kümesidir.

  10. Abhay Bhushan, çalıştay notlarını ve yeni dosya aktarım protokolü için taslak teknik özellikleri yazacaktır.

Katılımcı Listesi — Veri ve Dosya Aktarımı Çalıştayı

Ad Kurum Tarihler
Abhay Bhushan MIT-MAC 14, 15 Nisan
Bob Braden UCLA-CCN 14, 15 Nisan
Arvola Chan MIT-MAC 14, 15 Nisan
Steve Crocker ARPA 14 Nisan
Eric Harslem RAND 14 Nisan
John Heafner RAND 14 Nisan
Chuck Holland UCSD 14, 15 Nisan
Alex McKenzie BBN (NET) 14 Nisan
Bob Metcalfe MIT-MAC 14 Nisan
Hal Murray CCA 14 Nisan
Bill Plummer BBN 14 Nisan
Jon Postel UCLA 14 Nisan
Neal Ryan MIT-MAC 14, 15 Nisan
Marc Seriff MIT-MAC 14, 15 Nisan
Bob Thomas BBN 14 Nisan
Ray Tomlinson BBN 14 Nisan
Dick Watson SRI-ARC 14, 15 Nisan
Doug Wells MIT-MAC 14 Nisan
Jim White SRI-ARC 14, 15 Nisan
Richard Winter CCA 14, 15 Nisan

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