Network Working Group A. Bhushan
Request for Comments: 310 MIT-MAC
NIC: 9261 3 Nisan 1972

Veri ve Dosya Aktarım Protokollerine Yeniden Bir Bakış

ARPANET üzerinden veri ve dosya aktarımına yönelik ad hoc tekniklerle ilgili deneyimlerimiz, terminal IMP (TIP) yetenekleri ve Datacomputer gereksinimleri hakkında daha iyi bir bilgiyle birlikte, Veri Aktarım Protokolü (DTP) (bkz. ref 1) ve Dosya Aktarım Protokolü’nün (FTP) (bkz. ref 2) gözden geçirilebileceğini göstermiştir. DTP ve FTP’yi uygulama yönündeki çabalarımız, protokollerin yararlılığını düşürmeden basitleştirilebileceği alanları ortaya koymuştur.

Bu makale, DTP ve FTP’de onları daha kullanışlı kılacak ve/veya uygulamayı basitleştirecek bazı özgül değişiklikler önermektedir. Buradaki amaç, yaklaşan Veri ve Dosya Aktarımı Çalıştayı’nda (bkz. ref 3) daha iyi bir protokol geliştirebilmemiz için düşünceyi harekete geçirmektir.

Bugüne Kadarki Deneyim

ARPANET üzerinden veri ve dosya iletimi için bir dizi ad hoc teknik halihazırda mevcuttur. Mevcut bu yöntemler arasında belki de en çok yönlü olanı TENEX “CPYNET” sistemidir. “CPYNET” sistemi, Ray Tomlinson ve BBN’deki diğerleri tarafından TENEX sistemleri arasında dosya iletimi için geliştirilen ad hoc ya da geçici bir dosya aktarım protokolünü kullanır.

[Bill Crowther ile Özel İletişim, BBN.]

CPYNET’te, kullanan süreç İlk Bağlantı Protokolü (ICP) üzerinden sunucu soketi 7’ye gider ve 8 bitlik bayt boyutuna sahip tam çift yönlü bir bağlantı kurar. Kullanıcı adı, parola, komut (okuma, yazma veya ekleme), dosya adı ve veri bağlantısı için bayt boyutu dâhil olmak üzere denetim bilgileri, kullanan süreçten hizmet veren sürece iletilir. Ardından özgün tam çift yönlü bağlantı kapatılır ve özgün soket numaraları kullanılarak, ancak olası olarak farklı bir bayt boyutuyla, yeni bir tam çift yönlü bağlantı kurulur. Dosya artık bu yeni kurulan bağlantı üzerinden iletilir. Dosya sonu, bağlantının kapatılmasıyla belirtilir (dolayısıyla aktarım kipi DTP “belirsiz bit-akışı”na benzer).

CPYNET, TENEX sistem dosyalarının aktarımı için oldukça yaygın biçimde kullanılmıştır. Veri yeniden biçimlendirilmediği ve veri aktarımı için en uygun bağlantı bayt boyutu kullanılabildiği için CPYNET oldukça etkilidir. PDP-10 (ARPANET’te bunlardan oldukça fazla vardır), verinin paketlenmesi ve paket açılmasını en aza indiren ve etkin G/Ç hızını artıran 36 bitlik bayt boyutuyla daha verimli çalışır (bit hızı, G/Ç sözcük aktarım hızının 8 katı yerine 36 katıdır).

Bağlantıların kapatılıp yeniden açılması ek yükü artırır, ancak bu artış TENEX’te, uygun olmayan bir bayt boyutu kullanılarak yapılan veri aktarımının getirdiği verimsizlikle karşılaştırıldığında küçüktür.

Veri ve dosya aktarımı, diğer bazı sitelerde, TELNET protokolünün kısıtları içinde ASCII dosyalarının terminal G/Ç veri akışları olarak aktarılmasını sağlamak üzere kullanıcı TELNET’inin basit bir değişikliğiyle gerçekleştirilmiştir. Bu yaklaşıma bir örnek, MIT-DMCG kullanıcı-TELNET’i içindeki “send.file” ve “script” özelliklerinin kullanılmasıdır. Send.file, PDP-10 (DMCG) kullanıcısının yerel ASCII dosyalarını bir TELNET bağlantısı üzerinden uzak konaktaki bir düzenleyici gibi bir alıcı sürece iletmesini sağlar. Program, iletim için değişken bir arabellek boyutuna izin verir ve bilgi bitlerinin aktarım hızını ölçer. Script ise, esasen yazdırma yoluyla (terminal çıktı akışı yerel bir dosyaya yönlendirilir) bir kullanıcının uzak bir konaktan ASCII dosyası almasını sağlar.

Send.file programının kullanımına ilişkin ilk deneyimlerimiz, ayırmalar, NCP gönderme arabellekleri, IMP mesaj boyutu veya alıcı sürecin hızı tarafından dayatılan sınırlara ulaşılıncaya kadar, arabellek boyutu ile iletim hızı arasında neredeyse doğrusal bir ilişkiyi (işleme maliyetiyle ters orantılı) doğrulamıştır. Deneylerimiz, alıcı sürecin her bir karaktere “baktığı” TELNET süreçlerinin yavaş ve maliyetli olduğunu göstermiştir. Çoğu TELNET alıcı sürecine aktarım hızı saniyede 200 ila 2.000 bit arasındadır. Buna karşılık NCP’den NCP’ye iletim hızı bir büyüklük mertebesi daha yüksektir (saniyede 2.000 ila 20.000 bit).

Yukarıdaki yöntemin, TELNET’in karakter karakter işlenmesini önleyen bir varyasyonu, DTP kullanılarak veya kullanılmadan, yardımcı bağlantılar (TELNET bağlantıları dışındaki) üzerinden dosya iletimidir. Farklı aktarım ve arabellekleme stratejileri kullanılarak yanıt süreleri, bağlantı süreleri ve aktarım hızları hakkında veri topluyoruz.

TIP Yetenekleri ve TIP Kullanıcıları

Görünüşe göre TIP’ler, DTP’yi mevcut biçimiyle desteklemeyecektir. Manyetik teyp birimlerine sahip daha gelişmiş TIP’ler ise DTP blok kipini (tanımlayıcı ve sayımlar) destekleyecektir.

[Bill Crowther ile Özel İletişim, BBN.]

Bir TIP kullanıcısının, DTP’ye dayalı hizmetleri (uzak iş hizmeti, dosya aktarımı, posta ve Datacomputer gibi) kullanması, en azından zahmetlidir. TIP felsefesi, “hesaplama yükünün ve depolamanın konaklarda ya da terminallerde olması, terminal işlemcisinde olmaması gerektiği” yönündedir. (Bkz. ref 4.) Bu felsefeyle tutarlı olmak için protokoller, kullanıcı bakış açısından basit ve kullanımı kolay olmalıdır.

İdeal olarak, TIP kullanıcıları uzak konakta ilan edilen hizmet soketine (logger soketi 1 dâhil) ilk bağlantı protokolünü kullanarak bağlanmak ve komutlarını tekdüze, kullanımı kolay bir biçimde yazmak isterler. DTP içinde ASCII kullanımına izin verilmesi bunu kolaylaştıracaktır. (Alternatif bir yaklaşım, TELNET’i özellikle belirsiz bit-akışı kipini içerecek şekilde DTP kiplerini kapsayacak biçimde genişletmektir.) Bir başka adım, kullanıcı düzeyi protokollerde komutlar ve bağımsız değişkenler için sayısal kodlar yerine yazdırılabilir ASCII dizgilerinin kullanılması olacaktır. Standart dosya sistemi komutlarının (tekdüze yorum ve biçimle) kullanımı, TELNET protokolünde tanımlanan Ağ Sanal Terminali’ne benzer biçimde, bir Ağ Sanal Dosya Sistemi’nin varlığına doğru ilerlemeyi sağlayacaktır.

DTP’deki saydam kip, TIP’ler tarafından rahat kullanım sağlamak üzere özellikle dâhil edilmiştir. TIP’ler saydam kipi desteklemeyeceği için, ondan vazgeçmek mantıklıdır. Bu değişiklik, blok kipinde ve belirsiz bit-akışı kipinde (tüm taraflar, TIP’ler dâhil, için kabul edilebilir olan ve ek yük içermeyen önerilen varsayılan kip) aktarımı mümkün kılan daha basit bir DTP’ye yol açacaktır. Ardından, artık zorunlu olan kipler-mevcut el sıkışmasını isteğe bağlı hâle getirebilir veya tamamen kaldırabiliriz. Kullanan süreç, aktarım için blok kipini de kabul edip etmediğini (ya kipler-mevcut işlemiyle ya da komut dizgesindeki bir bağımsız değişkenle) belirtebilir. Sunucu, DTP kipinde olduğu kadar ASCII girdisini de kabul etmelidir. DTP’deki bu temel değişiklikler, TIP’lerle iletişimi çok daha kolay hâle getirecektir.

Aracı bir kullanıcı-FTP sürecine ve TIP’lerinde bir dosya sistemine sahip olmayan TIP kullanıcıları, muhtemelen dosyaları giriş aygıtlarından veya satır yazıcısı, kart okuyucu ya da delici veya manyetik teyp gibi çıkış aygıtlarına aktarmak isteyeceklerdir. Bu aygıtlar, bir TIP üzerinde belirli “portlar” ya da soketler üzerinden “dinler”. FTP’nin, belirtilen bir kip ve türde, belirtilen bir sokete veri gönderilmesine izin verecek şekilde değiştirilmesi arzu edilir. TIP kullanıcıları böylece dosyalarının listelerini yüksek hızlı bir satır yazıcısından almak, dosyalarını kart okuyucudan girmek ve kartlar ya da manyetik teypler üzerinde yedek tutmak konusunda rahatlık bulacaklardır.

Datacomputer Gereksinimleri

Datacomputer üzerinde veri ve dosya aktarımı için CCA’nın planları ve özgül gereksinimleri konusunda CCA personeliyle (özellikle Dick Winter) süregelen bir diyalog yürütmekteyiz. Dick Winter bu konuda Veri ve Dosya Aktarımı Çalıştayı’nda konuşacaktır. Bu bölüm, tartışmamızın ana noktalarını ve bunların veri ve dosya aktarımı açısından sonuçlarını özetleme girişimidir.

Öncelikle, CCA bu aşamada Datacomputer’ın nasıl kullanılacağı konusunda oldukça esnek görünmektedir. Datalanguage bile (bkz. ref 5) esnektir ve değişikliğe uğrayabilir. Ancak CCA, mevcut dosya aktarım protokolünde ve öngörülen kullanımında bazı değişiklikler istemektedir.

İdeal olarak CCA, tüm denetim bilgilerinin Datalanguage biçiminde aktarıldığı tek bir tam çift yönlü bağlantı görmek istemektedir. Bu bilgiler, bir konsoldaki kullanıcı ya da bir kullanıcı programı olabilen bir süreç tarafından üretilir. Veri ve denetim bilgilerinin iç içe geçirilebilmesi kesin bir avantaj olacaktır. Datacomputer muhtemelen DTP’yi destekleyecek ve TELNET-ASCII kullanımına izin verecektir.

Veri, alternatif olarak, ayrı bir kullanıcı tanımlı porta (bir soket olabilir) gönderilebilir ya da buradan alınabilir. Bir kullanıcının, Datacomputer’a, bir uzak sistemdeki bir dosyaya FTP aracılığıyla veri aktarması ya da bu dosyadan veri alması talimatını verebilmesi avantajlı olacaktır (uzak sistemde bir sunucu-FTP olduğu varsayımıyla). CCA şu anda bu fikre bağlı değildir, ancak değerlendirmektedir.

CCA’nın bakış açısına göre Datacomputer, komut dili olarak Datalanguage’a sahip bir veri yönetim tesisini temsil eder. Datacomputer’ın bir FTP sunucusu olarak bakış açısından, FTP komutları Datalanguage’ın bir alt kümesi olacaktır. Bu nedenle FTP komutlarının sayısal kodlar yerine yazdırılabilir ASCII dizgileri olması arzu edilir.

Uzak İş Hizmeti Gereksinimleri

Başlangıçta Uzak İş Hizmeti (RJS) için iki ayrı protokol önerilmiştir. Bunlardan biri büyük konaklardan uzak iş hizmeti için NETRJS protokolü (bkz. ref 6), diğeri ise TIP’lerden (ve diğer mini-konaklardan) uzak iş hizmeti için NETRJT protokolüdür (bkz. ref 7). Ancak güncel düşünce, “bu iki kullanıcı kitlesiyle başa çıkma yöntemleri arasında mümkün olduğunca fazla örtüşme” olan tek bir RJS’ye doğru ilerlemektir. (Bkz. ref 8.) Belki DTP içinde ASCII’nin dâhil edilmesi bunu mümkün kılacaktır.

DTP ve FTP için mevcut öneriler, RJS gereksinimleri açısından bir ölçüde optimal olmaktan uzak görülmüştür. Veri yapılarının ve veri türlerinin ele alınmasında DTP ve FTP’nin belirli sakıncaları işaret edilmiştir. Bu sorunların çoğu görece kolay çözülebilir görünmektedir. Bu, Ağ ASCII’sini varsayılan veri türü (tüm konaklar için kabul edilebilir) yapmayı ve FTP’de alternatif veri türleri ve veri yapıları önermeye ve reddetmeye yönelik bir yol sağlamayı içerecektir.

FTP’nin (diğer uygulamalarla da ilgili olan) bir başka yetersizliği, hata kurtarma alanındadır. Şu anda, iletim yolundaki bir öğe başarısız olursa iletimi “yeniden başlatmanın” bir yolu yoktur. Önerilen çözümlerden biri sıra numaralarının kullanımıdır (bkz. ref 9). Soruna yönelik başka çözümler de mevcuttur. Bunlar, ileride “FTP Yeniden Değerlendirildi” bölümünde ele alınmaktadır.

DTP Yeniden Değerlendirildi

DTP için hedef, bilgiyi mantıksal yapısına (kayıtlar, dosyalar ve denetim) ayırmak ve temel hata denetimi sağlamak için tekdüze bir mekanizma sunmasıydı. DTP ve kiplerinin değerlendirilmesi hız (gerçek zaman), verimlilik (işleme maliyeti), güvenilirlik (hata denetimi ve kurtarma) ve kullanım kolaylığı temelinde yapılmalıdır.

DTP önemli ölçüde gözden geçirilmedikçe, TIP ve diğer mini-konak kullanıcılarının DTP kullanımına dayalı hizmetleri kullanmakta zorlanacağı artık açıktır. DTP içinde ASCII kullanımına izin vermek ve “kipler mevcut” el sıkışması yerine varsayılanları kullanmak bu sorunu hafifletecektir; ancak DTP’nin hata denetimi işlevinden ödün verilmiş olacaktır. Hata denetiminin DTP düzeyinde mi yoksa daha üst bir düzeyde mi yer alması gerektiği daha fazla tartışma gerektirmektedir.

DTP, mevcut biçimiyle, yeterli hata denetimi ve kurtarma yordamları sağlamamaktadır. DTP’yi daha kullanışlı kılmak için ya (en azından kullanıcı bakış açısından) basitleştirilmeli ya da daha iyi hata denetimi, yerleşik hata kurtarma ve olası veri türleri ile veri yapılarının ele alınmasını içerecek şekilde genişletilmelidir.

Basitleştirilmiş sürümde DTP, verinin ASCII olarak (biçimlendirme olmaksızın), 8 bitlik saydam (belirsiz bit-akışı) kipe kaçışla veya veri blokları hâlinde (tanımlayıcı ve sayım kipi) iletilebildiği bir biçim yordamı olacaktır. Hangi kipin kullanılacağına ilişkin seçim ile tüm hata denetimi, hata kurtarma ve iptaller üst düzey protokol tarafından ele alınacaktır.

Veri aktarımında blok kipinin yararlılığı, dosya sonunu belirtme ve veri ile denetim bilgisini ayırma gibi basit işlevleri sağlamak için büyük bir ek yük getirdiğini öne süren birçok kişi tarafından sorgulanmıştır. Alternatif veri aktarım stratejisi, denetim ve veri bilgileri için ayrı bağlantılar kullanmak ve/veya bağlantıları kapatıp yeniden açmaktır. Bu, farklı türden bir ek yüke neden olur; ancak bağlantı için bayt boyutunun veri aktarımını optimize edecek şekilde seçilebilmesi avantajını sağlar.

Mevcut DTP’nin bir sakıncası, 8 bitlik baytların aktarımına yönelik olmasıdır. Belki de veri aktarımı için iyi bir strateji, verinin üzerinde anlaşılmış bir aktarım kipinde gönderilmesine izin vermektir. Seçilen aktarım kipi, bağlantı için bayt boyutunu, seçilen veri türünü ve herhangi bir veri yapısı bilgisini belirlemelidir. Bu kip, DTP düzeyinde ya da kullanan protokol düzeyinde seçilebilir.

FTP Yeniden Değerlendirildi

FTP için hedef, ARPANET Sanal Dosya Sistemi içinde dosya yönetimini ve dosya aktarımını kolaylaştırmasıydı. FTP’nin başarısı, kullanımının yaygınlığı, kullanımındaki kolaylık ve verimlilik ile Datacomputer, RJS ve Posta gibi diğer uygulamalara uygunluğu üzerinden değerlendirilmelidir.

Bir kullanıcı, aracı bir DTP/FTP-kullanıcı sürecinin yardımı olmadan doğrudan bir FTP sunucusunu kullanabilirse, FTP’nin geniş çapta kullanımı mümkün olacaktır. Bu, komutların sayısal kodlar yerine ASCII dizgileri olmasını ve ASCII karakterlerinin kabul edilebilir bir girdi olmasını gerektirir. FTP’de böyle bir değişiklik, sunucu uygulamasını daha karmaşık hâle getirme pahasına kabulünü büyük ölçüde artıracaktır. Bununla birlikte, birleşik uygulama basitleşecektir; çünkü aracı FTP-kullanıcı süreci (kullanılırsa) sadeleşecektir.

Aktarım verimliliği, FTP’nin kullanışlılığını etkileyen önemli bir etkendir. Uygun olmayan bir aktarım stratejisi kullanılırsa (örneğin uygun olmayan bayt boyutu), dosya aktarımı CPU zamanı açısından çok pahalı ve gerçek zamanlı olarak yavaş olabilir. Veri aktarımını optimize etmek için her türlü çaba gösterilmelidir. İyi bir strateji, dosyaların ayrı bir bağlantı üzerinden aktarılmasına izin vermek ya da bağlantıları kapatıp yeniden açmak (belki farklı bir bayt boyutu kullanarak) olabilir. Bağlantının kapatılmasıyla dosya sonunun belirtilmesindeki bir sorun, bağlantının dosya sonuna ulaşıldığı için mi yoksa bir arıza ya da hata durumu nedeniyle mi kapatıldığının belirsiz olmasıdır. Belki “NCP kesmeleri”, kesin dosya sonu durumunu belirtmek için bir “kapatma”ya ek olarak kullanılabilir.

Mevcut FTP stratejisindeki bir dezavantaj, yeniden başlatma yordamının olmamasıdır. Yeniden başlatma için bir öneri, DTP blok modunda kullanılan sıra numaralarının kullanılmasını içermiştir. Bizim görüşümüz, yeniden başlatmanın belki de FTP içine, kullanıcının yeniden iletime dosyanın hangi noktasından başlanacağını belirtmesine olanak tanıyan bir komutun eklenmesiyle en iyi şekilde sağlanabileceğidir. Olası bir çözüm, UCSB Simple-Minded File System’de uygulanmış olan "SPF" komutunun kullanılmasıdır (bkz. ref 10). Başka bir çözüm ise, alma ve saklama komutları için isteğe bağlı argümanlara sahip olunması ve bunların seçici alma ve değiştirmeye (bitler, karakterler, sözcükler, satırlar, sayfalar veya segmentler ile belirtilen) olanak tanıması olabilir.

FTP’ye yapılabilecek bir diğer yararlı ekleme, kullanıcı ile sunucu arasında dosya aktarımı için veri türü, veri yapısı ve kip üzerinde anlaşmayı sağlayan bir protokol yordamı olacaktır. Bu, kullanıcının ve sunucunun her ikisi için de kabul edilebilir en uygun dosya aktarım stratejisine ulaşmasını mümkün kılacaktır.

Sonuç Niteliğinde Değerlendirmeler

Bu makalede, mevcut DTP ve FTP belirtimlerinde başlıca sorun alanları olarak gördüklerimizi ele aldık. Bu tartışmanın düşünmeyi teşvik edeceğini ve böylece tüm farklı gereksinimleri zarif bir biçimde karşılayan gözden geçirilmiş DTP ve FTP belirtimlerine ulaşabileceğimizi umuyoruz.

Kaynaklar

1. The Data Transfer Protocol, Bhushan, et al., NWG/RFC #264, NIC #7212.
2. The File Transfer Protocol, Bhushan, et al., NWG/RFC #265, NIC #7213.
3. Data and File Transfer Workshop Announcement, A. Bhushan, NWG/RFC #309, NIC #9260.
4. The Terminal IMP for the ARPA Computer Network, Ornstein, et al., SJCC, 1972, NIC #8218.
5. Datalanguage, Computer Operation of America, Datacomputer Project, Working Paper No. 3, 29 Ekim 1971, NIC #8208.
6. Interim NETRJS Specifications, R. T. Braden, NWG/RFC #189, NIC #7133.
7. NETRJT -- TIP’ler için Uzak İş Hizmeti Protokolü, R. T. Braden, NWG/RFC #283, NIC #8165.
8. RJS Protokolü Toplantı Notları, 25 Şubat 1972, A. McKenzie (sınırlı dağıtım).
9. File Transfer Protocol’e Önerilen Bir Ek, A. McKenzie, NWG/RFC #281, NIC #8163.
10. UCSB’nin Simple-Minded File System’i için Ağ Belirtimleri, James E. White, NWG/RFC #122, NIC #5834.

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