| Yazar | A. McKenzie | | Kurum | Request for Comment: 281 — BBN | | Tarih | 8 Aralık 1971 | | Durum | Network Working Group Yorum Talebi | | RFC Numarası | 281 |
16 Kasım'da UCLA'da, ağ için standart bir Remote Job Service (RJS) protokolünün olanaklarını tartışmak amacıyla gayriresmî bir toplantı düzenlendi. Toplantıya UCLA-CCN ve UCSB temsilcileri (ağın şu anda RJS kullanan tek siteleri), ayrıca UCLA-NMC ve BBN ağ projesi katıldı. Bu tartışmaya ilişkin bir rapor kısa süre içinde bir RFC olarak yayımlanacak ve burada ele alınmayacaktır. Ancak önerilen File Transfer Protocol (FTP) (RFC #265)'ün RJS için kullanımı üzerine düşünürken, FTP'ye bir "restart" yordamının son derece yararlı bir ek olabileceği sonucuna vardık.
Şimdiye kadar protokol tasarımına dahil olan kişilerin çoğu, belki de büyük çoğunluğu, ağ üzerinden kısa veri iletimlerinin kullanımına yönelmiştir. "Tipik" kabul edilen iletim uzunlukları birkaç karakter, bir yazıcı satırı veya belki bir sayfa metin kadardır. Ancak mevcut RJS sitelerinin deneyimi, tekil dosyaların çoğunlukla çok daha uzun olduğunu göstermektedir; örneğin 400 sayfalık bir satır yazıcısı çıktı dosyası bu siteler için olağandışı görünmez. Ayrıca ağ üzerinden Remote Job Services kullanımının büyük işlere doğru önceden seçilme eğilimi göstereceğini makul biçimde öngörebiliriz (her ne kadar büyük işler her zaman büyük G/Ç dosyaları anlamına gelmese de) ve diğer batch servis sitelerinin (ILLIAC, UCSD) eklenmesi uzun dosya aktarımlarının sayısını artıracaktır. Bu tür deneyim ve öngörüler ışığında, iletim yolundaki bir unsur büyük miktarda veri aktarıldıktan sonra başarısız olursa uzun bir dosya aktarımını "yeniden başlatma" yönteminin FTP içinde bulunması gerektiği (belki etkileşimli kullanıcı odaklı sistemlerin göz ardı edebileceği bir seçenek olarak) uygun görünmektedir.
Bir "restart" yordamındaki kritik unsur, iletim yolunun her iki ucunun yeniden iletimin tam olarak nereden başlayacağı konusunda anlaşabilmesini sağlamaktır. FTP'nin temelini oluşturan önerilen Data Transfer Protocol (RFC #264) içinde olası yeniden başlatma konumlarını işaretlemek için hâlihazırda iki aday bulunmaktadır; bunlar şunlardır:
- a) Hem "transparent block" aktarımlarında hem de "descriptor and counts" aktarımlarında kullanılabilen "information separators" (işlem türü B4), ve
- b) "descriptor and counts" aktarım modu ile kullanılabilen "sequence numbers".
Bir miktar tartışmadan sonra, "information separators"ın ("transparent block" aktarım modunda, yani "sequence numbers" olmadan kullanıldığında) belirsiz olmayan yeniden başlatma konumu işaretleyicileri olarak hizmet etmesinin olası görünmediği konusunda fikir birliğine vardık ve bu nedenle işaretleyici olarak "sequence numbers" kullanılmasını öneriyoruz. Bu seçimin, sıra numaralandırması kullanmayan TIP'leri ve diğer Host'ları tartışılan kurtarma türünün dışında bırakabileceğinin farkındaydık; ancak önerimizin bu sorunun en azından bir kısmını ortadan kaldırdığına inanıyoruz.
user site ya da user olarak adlandıracağımız bir sitenin, kendi dosya aktarım sürecinden başka bir sitedeki dosya aktarım sürecine bir bağlantı başlattığını düşünelim; bu siteyi de server site ya da server olarak adlandıralım. Gerekli bilgi alışverişlerinden sonra bu iki site arasındaki yol üzerinden bir dosya aktarımı (File Transfer Protocol kullanılarak) başlar. Bir miktar bilgi aktarıldıktan sonra kullanıcı ile sunucu arasındaki yol kesilir. Daha sonraki bir zamanda kullanıcı, kullanıcı ve sunucu sitelerindeki dosya aktarım süreçleri arasında yeni bir bağlantı başlatır, gerekli erişim yetkilerini kurar ve yol kesildiğinde sürmekte olan iletimi devam ettirmek ister. Öncelikle File Transfer Protocol için dört yeni op-code tanımlıyoruz:
Yeni FTP Op-Code'ları
| Hex | İşlem |
|---|---|
| 10 | Sequence number'da ekle |
Bu komut, op-code'dan hemen sonra (pathname'den önce) 16 bitlik bir sequence number gelmesi dışında "Store" veya "Append" komutlarından herhangi biriyle özdeştir.
| Hex | İşlem |
|---|---|
| 11 | Sequence number'da getir |
Bu komut, op-code'dan hemen sonra (pathname'den önce) 16 bitlik bir sequence number gelmesi dışında "Retrieve" komutuyla aynıdır.
| Hex | İşlem |
|---|---|
| 12 | Retrieve işlemini sürdür |
Kullanıcı, sequence number'ın sunucu tarafından seçilmesini istediğinde kullanılır; diğer yönleriyle "Retrieve" komutuyla aynıdır.
| Hex | İşlem |
|---|---|
| 13 | Bu sequence number'ı kullan |
Bu komut yalnızca op-code ve 16 bitlik bir sequence number içerir. "Append at sequence number" veya "Retrieve at sequence number" komutunda verilen sequence number'ı bulma olanağının reddedildiğini belirtmek ve aynı zamanda bulunabilen başka bir numarayı önermek amacıyla kullanılır.
Aşağıda gösterilen birkaç olası durum vardır. Kullanıcı sitesinin her zaman sayfanın sol tarafındaki site olduğu varsayılır.
A. Yol Kesildiği Anda Kullanıcı Sitesi Gönderiyor
Sequence number'da ekle → Onay → Veri
Sunucu sitesi kullanıcı tarafından seçilen noktadan devam etmeyi kabul eder. İlk veri işlemi seçilen sequence number ile numaralandırılır.
Sequence number'da ekle → Başarısız Sonlandırma
Sunucu sitesi bazı nedenlerle yeniden başlatmaya hiçbir zaman izin vermeyecektir (sequence number'lar başlangıçta yok sayılmış veya kullanılmamış olabilir, sequence number'lar dosya ile birlikte saklanmamış olabilir, yol kesildiğinde dosya kaybolmuş olabilir vb.).
Sequence number'da ekle → Bu sequence number'ı kullan → Veri
Kullanıcı sitesi sunucunun seçtiği numarayı kullanmayı kabul eder ve ilk veri işlemi seçilen numara ile numaralandırılır.
Sequence number'da ekle → Bu sequence number'ı kullan → Başarısız Sonlandırma
Kullanıcı sitesi bazı nedenlerle bu numarada yeniden başlatamaz.
B. Yol Kesildiği Anda Kullanıcı Sitesi Alıyor (Sequence Number Kritik Değil)
Retrieve işlemini sürdür → Veri
Sunucu bir nokta seçer ve iletimi o noktadan başlatır. Eğer orijinal iletim sırasında sequence number'lar kullanılmışsa, bu iletimin ilk işlemi orijinal iletimdeki işlemlerden biriyle tam olarak eşleşmelidir (sequence number dahil).
Retrieve işlemini sürdür → Başarısız Sonlandırma
Sunucu sitesi iletimi yeniden başlatamıyor veya başlatmak istemiyor.
C. Yol Kesildiği Anda Kullanıcı Sitesi Alıyor (Sequence Number Önemli)
Sequence number'da getir → Veri
Sunucu kullanıcı tarafından seçilen noktadan devam etmeyi kabul eder. İlk veri işlemi seçilen sequence number ile numaralandırılır.
Sequence number'da getir → Başarısız Sonlandırma
Sunucu sitesi bazı nedenlerle yeniden başlatmaya hiçbir zaman izin vermeyecektir.
Sequence number'da getir → Bu sequence number'ı kullan → Onay → Veri
Kullanıcı sitesi sunucunun seçtiği numarayı kullanmayı kabul eder. İlk veri işlemi seçilen numara ile numaralandırılır.
Sequence number'da getir → Bu sequence number'ı kullan → Başarısız Sonlandırma
Sunucu kullanıcı tarafından seçilen numarayı kullanamaz ve kullanıcı da sunucu tarafından seçilen numarayı kullanamaz. Bu nedenle yeniden başlatma girişimi terk edilmelidir.
Bazı siteler (örneğin UCLA-CCN), bu komutları uygulamayı ve daha da önemlisi sequence number'ları (aktarılmakta olan dosyalarla birlikte) kalıcı bir depolama ortamında saklamayı prensipte kabul etmiştir; böylece yeniden başlatmalar gerçekleştirilebilir. Bu elbette yalnızca bu öneri veya benzeri bir öneri NWG tarafından File Transfer Protocol'ün bir parçası olarak kabul edilirse yapılacaktır. İlgilenen tarafların yorumlarını veya karşı önerilerini FTP komitesine iletmelerini ve/veya fikirlerini RFC serisinde yayımlamalarını umuyoruz.
AAM/jm
Bu RFC, çevrimiçi RFC arşivlerine eklenmek üzere Kelly Tardif, Viaginie tarafından 10/99 tarihinde makine tarafından okunabilir biçime dönüştürülmüştür.