Ağ Çalışma Grubu — R. Braden
Yorum Talebi (Request for Comments): 430
NIC: 13299
CCN/UCLA
7 Şubat 1973

Dosya Aktarım Protokolü Üzerine Yorumlar

23 Ocak 1973 tarihinde Jon Postel (NMC), Eric Harslem (RAND), Stephen Wolfe (CCN) ve Robert Braden (CCN), FTP üzerine UCLA’da gayriresmî bir toplantı gerçekleştirmiştir. Bu RFC genel olarak, söz konusu toplantıda aşağıdaki konular üzerinde varılan görüş birliğini rapor etmektedir: sunucu-sunucu aktarımları (Thomas ve Clements tarafından RFC 438’e bakınız); siteye bağımlı bilgiler; ve RFC 354, 385 ve 414 ile ilgili çeşitli sorular/anlaşmazlıklar. Ayrıca yazdırma dosyası karmaşası üzerine bir tartışma da yapılmıştır, ancak bu konu ayrı bir RFC olan No. 448’de ele alınmaktadır.

FTP Üzerine Çeşitli Yorumlar

1. RFC 385, s. 1 (3)

Yazdırma dosyaları meselesi başka bir RFC’de ayrıntılı olarak tartışılacaktır. Ancak, Sayfa 1’in alttan ikinci satırındaki “still” sözcüğünün gereksiz olduğu görüşündeydik.

2. RFC 385, s. 2 (5); RFC 385, s. 3 (8); RFC 414, s. 4 (11.i)

Bu maddeleri anladığımız kadarıyla, bunlar belirli kötü uygulamalara (“hack”lere) yapılmış gereksiz ve muhtemelen istenmeyen tavizler gibi görünmektedir. İkinci maddeye, yani RFC 385’teki No. 8’e atıfla, ARPA Network gibi eşzamansız çok süreçli bir sistemde “hemen sonra” ifadesinin pek az anlamı olduğu not edilmelidir. “Hemen sonra”ya dayanan bir uygulama hatalıdır ve düzeltilmelidir. Elbette, tanımlandığı haliyle protokolün içsel bir yarış durumu varsa, protokol düzeltilmelidir; ancak böyle bir sorunun var olduğuna inanmıyoruz. FTP belgesindeki komut-yanıt dizilerinin tanımlarının oldukça sıkılaştırılması yardımcı olacaktır. Son maddeye gelince, Wayne Hathaway’in “örtük eor”a neden bu kadar şiddetle karşı olduğunu anlamıyoruz.

3. RFC 354, s. 13, Blok Modu için Biçim Tanımları

(a) Başlık uzunluğunun tanımının, muhtemelen “uzunluğu 24 bitten büyük ya da eşit olan en küçük tam sayı bayt sayısı” anlamına gelmesi amaçlanmıştır.

(b) Aynı tanımsal sorun yeniden başlatma işaretçileri için de ortaya çıkmaktadır.

(c) Yeniden başlatma işaretçisinin neden 8 bitten büyük olması gerekiyor?

(d) Tanımlayıcı kodlamasının bit bayraklarına dönüştürülmesinin, örtük eor’u ve RFC 385, s. 2, #6’daki sorunu ortadan kaldıracağını not ediniz.

4. RFC 414, s. 5 (11.iii)

EBCDIC kodlu herhangi bir dosya için metin modunun mümkün olmadığını not ediniz. EBCDIC 8 bitlik bir kod olduğundan, Telnet denetim karakterleri (128–255) ne eor’u ne de eof’u ayırt etmek için kullanılamaz. Ancak akış ve blok modları çalışacaktır. Son sayfadaki diyagramın, FTP parametrelerinin üç boyutlu uzayını takip etmek açısından yararlı olduğunu gördük.

5. RFC 354, s. 17, PASS Komutu

FTP içinde bir parolayı değiştirmek için herhangi bir mekanizma yoktur. Bir kullanıcının yalnızca parolasını değiştirmek için farklı bir protokol kullanması (örneğin, bir zaman paylaşımlı sisteme giriş yapması) gerekmez.

6. RFC 385, s. 3 (9.), BYTE’dan Önce TYPE

Bu uyarı (BYTE’dan önce TYPE gönderilmesi), bir sunucu FTP için bir kısıtlama olarak değil, kullanıcı FTP için önerilen bir prosedür olarak açıkça etiketlenmelidir.

7. RFC 385, s. 2–3 (7), 255 Yanıtının Sırası

Katılımcıların bir kısmı (güçlü bir şekilde), bu maddede ele alınan zamanlama sorununun kötü NCP uygulamalarının sonucu olduğunu ve protokol içinde meşrulaştırılmaması gerektiğini düşündü. Buradaki konu, RFC’lerin kuyruğa alınıp alınmamasıyla ilgili eski, tanıdık ve hassas meseledir. (Benim kendi görüşüm, RFC’leri kuyruğa alamayan NCP’lerin zorladığı protokol asimetrisinin en azından estetik olmadığını ve bazı zarif çözümleri imkânsız kıldığını yönündedir. Örnekler için RFC 414’e ve aşağıdaki sunucu-sunucu etkileşimiyle ilgili yorumlara, ayrıca Yeniden Bağlanma Protokolü üzerine RFC 438’e bakınız.)

8. RFC 354, s. 15, Yeniden Başlatma

Bir RESTart komutunu takiben, APPend ve STORe’un muhtemelen aynı anlamlara sahip olduğu kabul edilmelidir.

B. FTP Parametre Kodlaması

Yazdırma dosyalarını tartışan RFC 448, yazdırma dosyası özniteliğinin, tür boyutundaki karakter kodu özniteliğinden (ASCII’ye karşı EBCDIC) mantıksal olarak bağımsız olduğuna işaret etmektedir; FTP’de izin verilen türler kümesi, bireysel özniteliklerin dış çarpımıdır. Dolayısıyla FTP’nin (en azından) aşağıdaki ikiye iki matrisle özetlenen dört karakter türü vardır:

TYPE komutundaki kodlamanın, türlerin bu karşılıklı bağımlılığını modellemesini öneriyorum. Her tür için ayrı tek bir ASCII karakter kullanmak yerine, birden fazla ASCII karakteri—isterseniz niteleyiciler—kullanmamız gerekir. Örneğin:

• A ASCII kodunu temsil eder
• E EBCDIC kodunu temsil eder
• P yazdırma dosyasını temsil eder
• I image’ı temsil eder
• L yerel baytı temsil eder

Buna göre RFC 385’e göre yasal türler şunlar olacaktır:

• A
• AP
• E
• EP
• I
• L

Burada ele alınan özniteliklerin tür benzeri olduğuna dikkat ediniz; bunlar (mantıksal olarak) yapı ya da iletim modu ile ilgili değildir, yalnızca dosyanın içsel kodlamasıyla ilgilidir.

Şu anda bu, önemsiz bir değişiklik olacaktır. Ancak önümüzdeki birkaç yıl içinde yeni türler eklendikçe dosya aktarım protokolünün önemli ölçüde genişleyeceğini öngörüyorum. Bazı sunucular sunucuya özgü tür varyasyonları eklemek isteyecek, NWG de bazılarını eklemek isteyecektir. Bir APL karakter kümesine ne dersiniz? Ya da önerilmiş olan çoklu bindirmeli 256 karakterlik ASCII’ye? Tür içinde birden fazla niteleyici (ve daha sonra belki daha fazla yapı) gelecekteki büyüme için en temiz kaçış mekanizması gibi görünmektedir.

C. Sunucu-Sunucu Etkileşimi

Thomas ve Clements tarafından RFC 438’de önerilen FTP değişiklikleri, mevcut ana bilgisayar–ana bilgisayar protokolü ve FTP gibi daha üst seviye protokollerde içkin olan genel bir probleme özgül bir çözümdür. Farklı ana bilgisayarlardaki iki (sunucu) sürecin, daha sonra RFC alışverişi yapabilmeleri ve bir bağlantı kurabilmeleri için soket adlarını (yani 40 bitlik sayıları) değiş tokuş edebilecekleri güvenli ve basit bir yola ihtiyaç olduğu görülmektedir.

Mevcut ikinci seviye (ana bilgisayar–ana bilgisayar) protokolü, bir ana bilgisayarın başka bir ana bilgisayardaki bir sürecin soket adını öğrenerek bir bağlantı kurabilmesi için tam olarak bir (güvenli) mekanizma sağlar: ICP. ICP mekanizması tek başına FTP’de sunucu-sunucu bağlantısı için yeterli değildir. Bu nedenle Thomas ve Clements, FTP protokolüne kabaca aşağıdaki gibi bir genişletme önermiştir:

1. Ana Bilgisayar A’daki bir denetleyici (“kullanıcı”) süreç, ICP’yi kullanarak iki farklı ana bilgisayardaki iki otomat (“sunucu”) sürece Telnet denetim bağlantılarını çağırır ve kurar. Bu şekilde çağrılan bir otomat süreç, Telnet denetim bağlantısı üzerinden standart bir komut diliyle gönderilen denetleyici komutlarını yürütür.

2. Denetleyici süreç, her bir otomatı uygun bir veri aktarım soketi ayırmaya ve soket adını denetim bağlantısı üzerinden denetleyiciye geri göndermeye yönlendirir. Bir otomatın, soket ayırma işlemini elde etmek için kendi NCP’siyle ana bilgisayara bağımlı bir şekilde pazarlık yapması varsayılır.

3. Denetleyici artık her iki veri aktarım soket adını da bilmektedir; bunları sonraki komutlarda otomatlara gönderir, böylece her otomat bağlanacağı yabancı soket adını bilir. Daha sonraki komutlar, otomatların RFC’ler göndermesine ve gerektiğinde veri bağlantısını açmasına neden olur.

Bu, Ağ üzerinden süreç-süreç etkileşimi için yararlı bir genel model gibi görünmektedir. Kişisel olarak, bu simetrik modelin tüm FTP’nin temeli olması gerektiğine inanıyorum. Denetleyici ve otomatlardan biri aynı ana bilgisayarda bulunabilir. Böylece kullanıcı/sunucu sorunu (herhangi iki ana bilgisayarın dosya aktarabilmesi için birinin sunucu FTP’ye, diğerinin kullanıcı FTP’ye sahip olması gerekliliği) ortadan kalkar. Ağın herhangi bir yerinde en az bir ana bilgisayarın bir denetleyici sürece sahip olması yeterli olur; diğer tüm ana bilgisayarların yalnızca birer otomat sürece ihtiyacı olur.

Belki gelecekte NWG, soket ayırma ve aktarma mekanizmasının, üçüncü seviye protokollerin birçoğunda yinelenmesi yerine ikinci seviye protokole dâhil edilip edilmemesi gerektiğini değerlendirmelidir. Bu modelin yalnızca, hem kullanıcı hem de sunucu süreçlerinin Telnet denetim bağlantısı koptuğunda soket ayırmalarını “serbest bırakması” durumunda güvenli soketler sağladığını not etmeliyiz. Aynı sorun Thomas’ın Yeniden Bağlanma Protokolü’nde (426) de ortaya çıkıyor gibi görünmektedir.

Her hâlükârda, şimdilik RFC 438’in genel üçüncü seviye modelini destekliyoruz. Ancak biraz farklı ve daha simetrik bir yaklaşım önermekteyiz.

1. FTP’de, FTP kullanıcısının bir veri aktarım komutu vermeden önce veri soketinde dinleme yapması gerekliliği kaldırılmalıdır. Ana bilgisayar–ana bilgisayar protokolünün güzelliği, her iki taraf da “eninde sonunda” eşleşen RFC’ler gönderdiği sürece, ilk RFC’yi hangi ana bilgisayarın gönderdiğinin önemli olmamasıdır. (Zaman aşımı elbette can sıkıcıdır, ancak uygulanabilir ve nihayetinde kaçınılmaz olduklarına inanıyorum; RFC’lerin kuyruğa alınması da gereklidir.)

2. LSTN yerine yeni bir GETSocket komutu öneriyoruz. Denetleyici (yani kullanıcı FTP) süreç, muhtemelen başarılı bir girişten sonra, her bir otomata bir GETSocket gönderecektir. Bir otomat GETSocket aldığında, bir (gönderme, alma) veri aktarım soketi çifti atayacak ve numaraları Telnet bağlantısı üzerinden geri gönderecektir. (Alternatif olarak, FTP sunucuya ilk girildiğinde her zaman bir (gönderme, alma) soket çifti atanmasını ve numaraların istenmeyen 255 yanıtları aracılığıyla kullanıcı sürece geri gönderilmesini de belirtebilir.)

3. Daha sonra kullanıcı süreç, SOCK komutlarını her iki tarafa göndererek soket numaralarını karşı ana bilgisayarlara iletecektir.

4. Bir veri aktarım komutu aldığında, otomat (sunucu) süreç iki soket numarasını içeren bir RFC gönderecektir. Her iki sunucu da çalıştırıldığında, RFC’ler değiş tokuş edilir ve veri aktarımı başlar.

D. Siteye Bağımlı FTP Parametreleri

Bazı ana bilgisayarlar, dosya sistemlerinin belirli durumlarda ek, ana bilgisayara özgü parametrelere ihtiyaç duyması nedeniyle mevcut FTP ile sorun yaşayacaktır. Örnek olarak, IBM işletim sistemleri, bir dosyanın diske mantıksal ve fiziksel eşlenmesi konusunda programcıya bir dizi seçenek sunma eğilimindedir.

Bu durum hem TSS/360 (Wayne Hathaway’in STOR komut uygulamasına ilişkin tartışmasına bakınız, RFC 418, s. 5) hem de OS/360 için geçerlidir. OS/360 dosya sistemi için mevcut olan geniş seçenek ve parametre kümesi, aslında OS İş Denetim Dili (JCL) hakkındaki şikâyetlerin çoğunun (meşru) kaynağıdır.

FTP kullanıcısı yalnızca bu sitelerden birinde veriyi kullanmadan depolamak istiyorsa, bir sorunu yoktur; varsayılan değerler, makul herhangi bir FTP isteğini karşılayacak şekilde seçilebilir. Ancak bir FTP kullanıcısı, orada kullanılmak üzere bir IBM/360’a dosya gönderiyorsa, mevcut FTP komutlarından hiçbirinden türetilemeyen yerel dosya sistemi parametrelerini belirtmesi gerekebilir.

Örneğin CCN için bir FTP sunucu uygulaması tasarlarken, eşleme sorununu, FTP parametrelerinin—tür, mod ve yapı—her bir birleşimi için (muhtemelen farklı) bir varsayılan eşleme seçerek ele almaya çalıştık. Bir kullanıcının belirli bir durum için “makul” ya da “uygun” FTP parametrelerini seçmesi hâlinde (örneğin kaynak programlar için “ASCII, akış, kayıt” ve yük modülleri için “image, blok, kayıt”), doğru OS/360 dosya eşlemesinin ortaya çıkacağını umduk. Ancak aşağıdaki gerekçeler nedeniyle bu yaklaşımdan vazgeçmek zorunda kaldık:

1. Bazı kullanıcı FTP’leri muhtemelen tüm FTP tür/mod/yapı birleşimlerini uygulamayabilir (gerçi uygulamalıdırlar!).

2. Bazı kullanıcı FTP’leri, kullanıcıya tür/mod/yapı üzerinde tam ya da kullanışlı bir denetim sağlamayabilir. Nitekim mod, nihai kullanımdan ziyade verimlilik gerekçeleriyle seçilmelidir.

3. Mantıksal olarak yeterince farklı FTP parametre birleşimi yoktu.

4. Sonuç, CCN’e burada kullanılmak üzere dosya gönderirken hatırlanması zor bir kurallar kümesi olacaktı.

5. Bazı yaygın durumlar, veri üzerinde tersine çevrilemez dönüşümler gerektirir. Örneğin, çoğu IBM dil işlemcisi (yani derleyici) yalnızca her biri (sürpriz!) 80 bayt olan sabit uzunluklu kayıtları, yani birebir kart görüntülerini kabul eder. OS/360’taki bu tür çirkin (ve mantıksal olarak gereksiz) uygulama saçmalıkları hayatın bir gerçeğidir. Şimdi, eğer bir FTP kullanıcısı masumca CCN’e, varsayılan olarak kart görüntülerine eşlenen belirli bir tür/mod birleşimiyle bir veri dosyası gönderseydi, kayıtlarının 80 bayta kesildiğini görecekti. Bu son derece dostça olmayan bir durum olurdu.

Dolayısıyla CCN sunucu FTP’si, yararlı olmak ile dostça olmak arasında bir seçim yapmak zorundaydı. Aşağıdaki stratejiye karar verdik:

1. Varsayılanlar dostça olacaktır; herhangi bir FTP tür/mod/yapıyı kabul edecek ve (yazdırma dosyaları hariç) tersine çevrilebilir biçimde depolayacağız. Ancak yalnızca bu varsayılanları kullanan bir kullanıcı, muhtemelen daha sonra veriyi yeniden biçimlendirmek için TSO altında bir yardımcı program çalıştırmak zorunda kalacaktır.

2.

STOR komutlarıyla ilişkili, uygun disk eşlemesini seçmek için bazı anımsatıcı anahtar sözcükler sağlayacağız. Örneğin, CCN’de derlenmek üzere bir Fortran kaynak dosyasını STORe etmek istiyorsa, kullanıcının makul ve çalışabilir OS/360 dosya sistemi parametreleri elde etmek için yalnızca “SOURCE” ya da “FORT” belirtmesi yeterli olacaktır. Buna ek olarak, gelişmiş kullanıcı için oldukça kapsamlı “DD” parametreleri sağlayacağız. Bu anahtar sözcüklerin ve parametrelerin sözdizimi ve anlambilimi, karşılık gelen TSO komutlarına mümkün olduğunca yakın olacaktır. Tüm ayrıntılar, uygulama çalışır hâle gelir gelmez yayımlanacaktır.

Bu tartışmaların tümü genel bir protokol sorusuna götürmektedir: bu tür ana bilgisayara bağımlı bilgiler FTP içinde nasıl yer almalıdır? Hathaway, ALLO komutunu kullandı (RFC 418, s. 6’ya bakınız). CCN ise bu tür bilgilerin, FTP sözdiziminde zaten ana bilgisayara bağımlı olan tek bölümde yer alması gerektiğini düşünmektedir: dosya yolu adı. Bu nedenle CCN, bir STOR komutunda “genelleştirilmiş” bir dosya yoluna izin vermeyi planlamaktadır; bu, (tam ya da kısmi) bir dosya adını, isteğe bağlı olarak, virgüllerle ayrılmış bir veya daha fazla anahtar sözcük ya da anahtar sözcük parametresinin izlemesi anlamına gelir.

Üçüncü bir olası çözüm, kullanıcının STORe komutundan önce, Hathaway’in önerdiği SRVR komutunu kullanarak sunucuya bağımlı bir veri kümesi oluşturma komutu göndermesidir. Veri kümesi oluşturma komutu, sunucu dosya sistemi için gerekli tüm parametrelere sahip olabilir. Eğer SRVR kabul edilirse ve insanlar genelleştirilmiş dosya yolunu sakıncalı ya da uygulanamaz bulursa, CCN bu yaklaşıma geçebilir.

Ana bilgisayara bağımlı sorunların bir başka ilginç örneği için, Hathaway’in RFC 418’deki DELE komutuna ilişkin tartışmasına bakınız (s. 6–7).

RFC 430 — Dosya Aktarım Protokolü Üzerine Yorumlar
Şubat 1973

TYPE/MODE Uyumluluk Tablosu

Anahtar:
Hariç tutulan durum

Bu RFC, çevrimiçi RFC arşivlerine girmek üzere Helene Morin tarafından, Via Genie aracılığıyla, 12/99 tarihinde makine tarafından okunabilir biçime dönüştürülmüştür.