FTP Sunucu-Sunucu Etkileşimi

Network Working Group B. Thomas
Request for Comments: 438 B. Clements
NIC: 13770 BBN-TENEX
References: 354, 385, 414, 418 15 January 1973

RFC 354 ile tanımlanan ve RFC 385, 414 ve 418 ile güncellenen mevcut ARPANET Dosya Aktarım Protokolü, "üçüncü ana bilgisayar" katılımına izin verir; ancak üçüncü sitedeki sürecin o sitedeki FTP sunucusu olabilmesi için bir mekanizma belirtmez. Bu RFC, bir sitedeki bir FTP kullanıcı sürecinin, diğer sitelerdeki FTP sunucu süreçlerinin kendi adına işbirliği içinde çalışmasını düzenleyebilmesine olanak tanıyacak FTP için basit bir genişletme önermektedir.

Böyle bir sunucu-sunucu işbirliği sınırlı bir yarara sahipmiş gibi görünebilir. Ancak, FTP üzerine bir Kaynak Paylaşımı Yöneticisi (RSEXEC) programı tarafından getirilen gereksinimleri göz önünde bulundurun—bu program, bir kullanıcının komutlarının kapsamını kullanıcının yerel sisteminin sınırlarının ötesine genişleten bir komut dili yorumlayıcısıdır. Bu tür bir RSEXEC, hizmetleri arasında, kullanıcılarına ağ genelinde bir dosya sistemi sağlayabilir; belki de belirli bağlamlarda, site belirtimini atlayan kısmen nitelendirilmiş yol adlarının kullanımına izin verebilir. Örneğin, kullanıcının şu komutuna RSEXEC’in verdiği yanıtı düşünün:

APPEND (FILE) PROG1.PL1 (TO FILE) PROG2.PL1

iki dosyanın farklı sitelerde olduğu (PROG1.PL1 SITE1’de, PROG2.PL1 SITE2’de) ve bunların hiçbirinin kullanıcının sitesi olmadığı durumda. RSEXEC’in APPEND’i "yerine getirmesi" için doğrudan bir yol, SITE1 ve SITE2’deki FTP sunucularına FTP kontrol bağlantıları kurmak, SITE1’deki sunucuya

RETR PROG1.PL1

komutunu veri bağlantısı C kullanarak vermek ve SITE2’deki sunucuya

APPE PROG2.PL1

komutunu yine aynı veri bağlantısı C’yi kullanarak vermek olacaktır.

Ne yazık ki, şu anda FTP içinde böyle bir sunucu-sunucu işbirliğini düzenlemenin bir yolu yoktur. Bunun başlıca nedeni, FTP’nin bağlantı kurulumu sırasında veri bağlantılarının uçlarını ele alma biçimindeki simetri eksikliğidir. Bir ucu "sunucu" ucu, diğerini "kullanıcı" ucu olarak belirtir ve iki uçtan bağlantıların kurulması için farklı yöntemler tanımlar.

FTP, sunucu-sunucu etkileşimini desteklemek üzere şu şekillerde değiştirilebilir:

veri bağlantılarının kurulmasını simetrik hale getirmek veya;
bir sunucuya, veri bağlantısının kendi ucunu sanki bir kullanıcıymış gibi kurmasını söyleyen bir mekanizma sağlamak.

İkinci alternatif, mevcut protokolde muhtemelen daha az değişiklik gerektirir.

FTP için aşağıda önerilen genişletme ikinci yöntemi kullanır. Tek bir yeni komutun (LSTN) eklenmesini ve birkaç mevcut komutta (SOCK, APPE, RETR, STOR) küçük değişiklikleri içerir:

a. LSTN Komutu

LSTN (Listen) komutu, FTP sunucusundan bir veri bağlantısı olarak kullanılmak üzere bir soket ayırmasını ister. Karşılık gelen veri bağlantısını kurmak için, uygun bir aktarım komutu verildiğinde sunucu ayrılan soket üzerinde "dinleme" yapacaktır.

Sözdizimi:

LSTN <direction> CRLF

burada <direction>, gönderme için S veya alma için R olabilir.

Sunucu, LSTN’ye şu şekillerde yanıt verir:

böyle bir soket ayırmayı reddederek veya;
kullanıcıya ayrılan soketin numarasını göndererek (bu amaçla 255 FTP sunucu veri soketi yanıtı kullanılabilir).

b. Aktarım Komutlarıyla Kullanım

Başarılı bir LSTN komutunu izleyen uygun bir STOR, RETR veya APPE komutunun alınması, sunucunun ayrılan soket için bir RFC beklemesine neden olur. Sunucu soket için bir RFC aldıktan ve buna eşleşen bir RFC ile yanıt verdikten sonra veri aktarımı devam edebilir. Kurulduktan sonra, başarılı bir LSTN komutuna karşılık gelen bir veri bağlantısı, olağan şekilde kurulan bir bağlantıyla aynı süreye sahiptir.

c. SOCK Kullanılarak Güvenlik

Kullanıcı, SOCK komutunu kullanarak sunucuya, dinleme soketi için bir RFC’yi yalnızca belirtilen bir ana bilgisayar ve soketten gelmesi durumunda kabul etmesini söyleyerek veri aktarımının güvenliğini sağlayabilir.

d. SOCK Komutundaki Değişiklikler

SOCK komutu iki şekilde değiştirilmiştir:

Başarı durumunda yanıt 255 FTP sunucu veri soketi yanıtı olmalıdır; yani 255 yanıtı bir veri aktarım komutunun alınmasına kadar ertelenemez. (Bu, kullanıcının sunucunun yanıtını üçüncü sitedeki programa iletebilmesi içindir; aşağıdaki örneğe bakınız.)
Bir LSTN komutundan sonra, SOCK komutu sunucu tarafından, ayrılan soketi kullanan sonraki veri aktarım komutları için kabul edilebilir RFC’nin belirtimi olarak yorumlanacaktır.

FTP için bu genişletme ile, RSEXEC programı yukarıdaki örnekteki APPEND işlemini şu şekilde gerçekleştirebilir:

       to SITE1:                       to SITE2:

          .                                .
          .                                .
          .                                .

1.                                   LSTN R CRLF
                                     (let X = socket
                                      allocated)

2.   SOCK SITE2,X CRLF
     (let Y = socket in 255
      reply from SITE1)

3.                                   SOCK SITE1,Y CRLF

4.  RETR PROG1.PL1                   APPE PROG2.PL1 CRLF

          .                                .
          .                                .
          .                                .

Son olarak, yukarıda önerilen türde deneysel bir RSEXEC programının yaklaşık 8 aydır TENEX’lerde çalışır durumda olduğunu belirtmek uygundur. Şu anda dosya aktarım işlemlerini içeren özel bir kaynak paylaşım protokolü (RSP) kullanmaktadır. RSP sunucu-sunucu işbirliğini destekler; RSP’de veri bağlantıları simetrik bir şekilde kurulur (yukarıdaki alternatif 1).

Bu RFC, çevrimiçi RFC arşivlerine girilmek üzere makine tarafından okunabilir biçime Mirsad Todorovac tarafından 5/98 tarihinde dönüştürülmüştür.