← rfc/
╔══════════════════════════════════════════════════════════════════════════╗
RFC 725 · protokol

Bir Kaynak Paylaşım Ağı için Bir RJE Protokolü

Yazar
Kurum
Tarih
Durum
Network Working Group Yorum Talebi
Kanal
protokol/

Bir Kaynak Paylaşım Ağı için Bir RJE Protokolü

CAC Teknik Muhtıra No. 86

CCTC-WAD No. 7508

ARPANET RFC No. 725

NIC No. 38316

Bir Kaynak Paylaşım Ağı için Bir RJE Protokolü

yazarlar

John Day
Gary R. Grossman

için hazırlanmıştır

Command and Control Technical Center
WWMCCS ADP Directorate

Defense Communications Agency
Washington, D.C. 20305

sözleşme kapsamında

DCA100-76-C-0088

Center for Advanced Computation

University of Illinois at Urbana-Champaign
Urbana, Illinois 61801

1 Mart 1977

Yayın için Onaylandı – Peter A. Alsberg, Baş Araştırmacı

ARPANET kullanıcılarının birçoğu için, bir RJE protokolü, yararlılık açısından muhtemelen bir TELNET (VTP) protokolü kadar önemlidir. Aslında, TELNET ve RJE protokollerinin sağladığı olanaklar, bilgisayar ağlarının çoğu kullanıcısı için en fazla ilgi uyandıranlardır. Bu kullanıcılar için ağ, zaman paylaşımlı kullanıcıya TELNET’in bir telefon muadili sağlaması gibi, hızlı ve ucuz bir RJE muadili sağlar. Bu hizmetleri sağlayan protokoller bütünü (ve katmanları), çok çeşitli uygulamaları ve kullanıcı gereksinimlerini verimli biçimde destekleyecek şekilde düzenlenmelidir. Kullanıcı üzerinde aşırı bir yazılım yükü oluşturmamalıdırlar.

ARPANET için “resmî” NETRJE protokolü, hem kullanıcı hem de sunucu topluluğundan beklenenden zayıf bir tepki almıştır. Bunun iki temel nedeni olduğuna inanıyorum. Birincisi, NETRJE’yi uygulamak için büyük miktarda kaynak tahsisi gereklidir. İkincisi ise protokolün ciddi güvenlik sorunları oluşturmasıdır.

ARPA RJE protokolünü desteklemek için, bir kullanıcının User Telnet, Server FTP ve User RJE’yi; bir sunucunun ise Server Telnet, User FTP ve Server RJE’yi uygulaması gerekir. Ayrıca, bir RJE oturumu devam ederken, bu üç protokol uygulamasının tamamı oturumun yaşam süresinin büyük bölümünde çalışıyor olacaktır. Bu durum bazı sistemler için kayda değer bir yük anlamına gelebilir. Bir hizmetin bu tür yükleri üstlenmesinin istenmesi makul olabilir; ancak oldukça temel bir hizmetten yararlanabilmek için bu yüklerin kullanıcıya yüklenmesi makul değildir. Çoğu kullanıcı kurulumu, ağ yazılımının büyük bölümlerini uygulamaya değil, kendi kullanıcılarının gereksinimlerini karşılamaya yöneliktir. (Nitekim, önceki ARPANET protokol tasarımlarının daha iyi yönlerinden biri, kullanıcı için yapılacak işi en aza indirmeye çalışmalarıydı. Bununla birlikte, bu yaklaşımın nedeninin kullanıcıya duyulan şefkat olmadığını da kabul etmek gerekir.)

Bir “hot line printer”ı (yani bir iş tamamlandığında otomatik olarak yazdırılması) desteklemek için, kullanıcının çıktı ana makinesi için kullanıcı kodunu ve parolasını sunucu ana makinede saklaması gerekir. Bu durum elbette oldukça ciddi bir güvenlik sorunu ortaya çıkarır. ARPANET, kapsamlı bir yeniden düzenleme olmadan tamamen güvenli hâle getirilemez; ancak kullanıcıların, ağa erişimi olan her birinci sınıf Bilgisayar Bilimleri öğrencisi tarafından mağdur edilmesini önlemek için alınabilecek bazı temel önlemler vardır.

Burada önerilen RJE protokolü, uygulama ve güvenlik sorunlarını hafifletmeyi amaçlamaktadır. Protokol, üç hizmet düzeyi sağlayacak şekilde tasarlanmıştır. Bir kullanıcı ya da sunucu, kaynaklarının izin verdiği herhangi bir düzeyde protokolü uygulama ayrıcalığına sahiptir. Daha sonra, fırsat doğduğunda veya oluştuğunda, hizmet daha temiz ya da daha gelişmiş yaklaşımlara yükseltilebilir.

Bu protokol ARPANET bağlamında tanımlanmıştır. Tasarımın bazı yönleri (örneğin yanıt yapısı) mevcut ARPANET gelenekleriyle örtüşecek şekilde belirlenmiştir. Bu, anlaşılmayı kolaylaştırmak ve tartışmayı protokolün kendisiyle sınırlamak amacıyla yapılmıştır. Protokol ARPANET terimleriyle açıklanmış olsa da, diğer ağ ortamlarına da uygulanabilir niteliktedir.

Bu makale her ayrıntıyı kapsayan tamamlanmış bir belge olarak değerlendirilmemelidir. Öncelikle ağ topluluğundan görüş almak ve topluluğun böyle bir yöntemi benimseme isteğini ölçmek amacıyla yazılmıştır. Okuyucunun, uygulama için gerekli ayrıntılara boğulmadan, işleyişin nasıl olacağına dair bir fikir edinebilmesi için protokolün yeterli bölümünü tanımlamaya çalıştık. Aşağıda, şu anki taslağa göre nihai protokol belgesinin bir taslağı yer almaktadır. Yıldız işaretiyle belirtilen bölümler daha sonra sağlanacaktır.

Giriş

Bölüm I

NETRJE Modelleri

  1. Telnet (VTP) Modeli
  2. Veri Aktarımı ile Telnet Modeli
  3. FTP ile Telnet Modeli

Modeller için Senaryolar

Çeşitli Uygulamalar için Önerilen Uygulama Şemaları

Bölüm II

Sunucu RJE Komutları

Genel Kurallar

Komutlar

Yanıtlar

Veri Aktarımının Ayrıntıları
Kullanıcı RJE için Asgari Gereksinimler
Sunucu RJE için Asgari Gereksinimler
Terimler Sözlüğü

Bölüm I: NETRJE Modelleri

Bu bölüm, önerilen NETRJE protokolünü anlatı biçiminde tanımlar. Resmî bir tanım, incelemeden sonra Bölüm II’de yer alacaktır. Bu anlatım, gereksiz ayrıntılara girilmeden, genel okuyucuya protokolün havasını aktarmayı amaçlamaktadır. Önerilen NETRJE protokolü, iş gönderimi ve çıktının alınması için üç farklı model sunar. Bu üç model şu şekilde karakterize edilebilir:

  1. Yalnızca Telnet kullanarak RJE
  2. Telnet ve Veri Aktarımı kullanarak RJE
  3. FTP kullanarak RJE

Bu yaklaşım, hem uygulayıcılar hem de kullanıcılar için esneklik sağlar. Personel ya da makine kaynakları kısıtlı olan kullanıcı ve sunucu siteleri yalnızca daha basit modelleri uygulayabilir. Kullanıcı, gereksinimlerine ve kolaylığına en uygun olacak şekilde, farklı modelleri ayrı ayrı ya da tutarlı herhangi bir birleşim hâlinde kullanabilir. Sunucular, daha gelişmiş bir modelin asgari uygulamasının, daha az gelişmiş tüm modellerin asgari uygulamalarını içerdiğini varsaymalıdır. (Bununla birlikte, desteklenmesi gereken bazı özel asgari gereksinimler vardır.) Bu bölüm, bu modellerin her birini sırayla ele alacak ve her birinin kullanışlı bir ağ RJE işlevi sağlayabildiğini gösterecektir.

Bu protokol, mevcut protokolde bulunan güvenlik güçlüklerini içermez. Bu durum, “hot line printer” ya da “hot card reader” uygulamasının yükünün kullanıcı sistemine verilmesiyle sağlanmıştır. Böylece, bu tür bir olanak isteyen sistemler yine de bunu destekleyebilir. Kullanıcı uygulaması biraz daha karmaşık olacaktır; karşılığında ise protokolün güvenliği artmaktadır.

Uçtan uca protokollerin mevcut olduğu ve RJE protokolüne sıralı, hatasız bir bit akışı sağladığı varsayılmaktadır. Ayrıca, kontrol bağlantısının biçimlendirilmesi için Telnet gibi uygun bir sanal terminal protokolünün kullanıldığı kabul edilmektedir.

Yalnızca Telnet (VTP) Kullanarak RJE

Bu modelin amacı, açıkça söylemek gerekirse, protokolün resmî bir “hızlı ve kaba” biçimini sağlamaktır. Hem kullanıcı hem de sunucu tarafındaki birçok kuruluş, bir hizmeti hızlı bir şekilde ya da çok sıkı bütçe kısıtları altında sağlama sorunuyla sık sık karşı karşıya kalır. Bu model, bu tür durumlar için tasarlanmıştır. Bu modelle, kullanıcının yalnızca RJE iletişim soketi üzerinden bir Telnet bağlantısı kurabilmesi yeterlidir. Komutlar, yanıtlar ve verilerin tamamı Telnet bağlantısı üzerinden gönderilir. Kart girdisi ya da yazıcı çıktısı, kullanıcının terminalinden geliyormuş ya da ona gidiyormuş gibi görünür. Kullanıcının sistemi, çıktının terminalden satır yazıcısı gibi başka bir aygıta yönlendirilmesine izin verebilir.

Terminal çıktısının yönlendirilmesi tekniği, MARK I ANTS sistemlerinde büyük başarıyla kullanılmıştır; bu sistemlerde çeşitli aygıtlar, bir TIP’te olduğu gibi soket numaralarına atanmazdı. Bu teknik, ağa program erişimine yalnızca kullanıcının Telnet bağlantısı üzerinden izin veren ana makineler için de yararlıdır. Bu durum, bir sunucunun ağa erişilebilirliğinin erken aşamalarında mevcut olabilir. Bu kipte veri aktarıldığında, alıcı ana makinenin yönlendirmeyi ne zaman durduracağını belirleyebilmesine yardımcı olmak için bir veri-sonu işareti gönderilecektir.

Bu model, temelde kontrol için tasarlanmış bir bağlantı üzerinden veri taşınmasının sorunlarını ele almak zorunda kalacaktır. Bu veri aktarım mekanizmasının kullanımı, sınırlı kaynaklar nedeniyle gerekli olan geçici bir önlem olarak düşünülmüştür. Şimdilik, tasarımcıların veri akışı içine komut ya da yanıt yerleştirmenin doğasında bulunan sorunların farkında olduklarını belirtmekle yetiniyoruz. Sorunun kesin çözümünü resmî tanıma bırakacağız.

Bu önerilen NETRJE protokolü, iş gönderimi için SCHED adlı bir zamanlama fiili kullanır. Bu model için SCHED’in ilgili iki biçimi vardır. Birincisi, SCHED <server pathname> biçimidir. Bu komut, sunucuya, sunucu sitesinde bir işi tanımlamak için gerekli tüm iş denetim bilgilerini ve verileri içeren bir dosya bulunduğunu bildirir. Sunucu daha sonra işi iş kuyruğuna yerleştirmeye çalışır ve kullanıcıya başarı ya da başarısızlığı, muhtemelen bir iş kimliğiyle birlikte bildirir. Bu iş kimliği, işin durumunu sorgularken ya da işin çıktısını alırken kullanılacaktır.

İş tamamlandığında sunucu iki eylemden birini gerçekleştirir:

Bu modelle ilgili olan SCHED’in diğer biçimi şu sözdizimine sahiptir:

SCHED INPUT <CRLF><data><CRLF>.<CRLF>

Bu, kullanıcının bir terminal başına geçip kendi iş denetimini ya da muhtemelen bir programı yazmasına olanak tanır. Ayrıca, yerel sistemleri User Telnet ile dosya iletme olanağı sağlayan kullanıcıların, kullanıcı girdisi iş dosyalarını bu yolla iletmesine imkân verir. RJE Sunucusu işi yerel iş akışına ekler ve uygun başarı ya da başarısızlık göstergesini, işin tanımlanmasıyla birlikte geri döndürür.

SCHED komutunun iş gönderimi için birden fazla yol sağlaması gibi, OUTPUT komutu da çıktının alınması için çeşitli seçenekler sunar. Aşağıdaki biçim:

OUTPUT <job-id> <server pathname> DISCARD

sunucuya gönderilerek, daha önceki OUTDEF komutlarıyla tanımlanmış çıktı özelliklerine göre çıktının kullanıcı sitesine gönderilmesini başlatır (aşağıya bakınız). OUTPUT komutundaki isteğe bağlı DISCARD bağımsız değişkeni, mevcutsa, dosyanın iletim başarıyla tamamlandıktan sonra yok edilmesini belirtir.

Bir iş için OUTDEF komutu, iş zamanlandıktan sonra ve OUTPUT komutuyla alınmadan önce herhangi bir zamanda gönderilebilir. Bu komut, çıktının kullanıcıya aktarılmasını sağlamak ya da çıktının nasıl ele alınacağını tanımlamak için gerekli parametreleri belirtir. OUTDEF <job-id> <server pathname> komutunun (çıktının, yol adıyla tanımlanan bir dosyaya yerleştirileceğini belirtir) bazı sistemler için uygulanmasının zor olabileceğinin farkındayız. Bu tür sistemler, işlevi yerine getiremeyeceklerini belirten olumsuz bir yanıt döndürecektir.

Modeli açıklamak için şimdi bir senaryo uygun olacaktır. Kullanıcı Multics’e giriş yapmıştır ve aşağıdaki şekilde bir RJE işi göndermeye hazırdır (XXX, henüz tanımlanmamış yanıt kodunu gösterecektir):

SCHED MY-JOB>TREK

Sistem, işin başarıyla gönderildiğini belirten bir yanıt verir ve örneğin XA1423 gibi bir iş kimliği döndürür.

XXX JOB XA1423 was successfully submitted.

Bir süre sonra şu mesaj görünür:

XXX JOB XA1423 has completed.

Kullanıcı ya da kullanıcı süreci şimdi OUTDEF XA1423 TELNET komutunu gönderir; bu, işin Telnet bağlantısı üzerinden gönderilmesi gerektiğini belirtir. Bir yanıt döner:

XXX last command successful.

Kullanıcı şimdi şunu gönderir:

OUTPUT XA1423

ve sunucu şu yanıtı verir:

XXX Output ready. Type an empty line when ready.

Kullanıcı, çıktıyı almaya hazır olduğunda boş bir satır gönderir.

Bu alışveriş, kullanıcının sunucunun hazır olduğunu doğruladıktan sonra, gerekirse yerel sitesinde çıktı yönlendirmesini gerçekleştirmesine olanak tanır.

Kullanıcı çıktıyı beklemek istememiş ve başarılı gönderimden sonra oturumu kapatmış olsaydı, bir sonraki girişinde işin ya da kendi kullanıcı kodu altındaki tüm işlerin durumunu sorgulayabilir ve ardından bunların herhangi birinin ya da hepsinin çıktısını alabilirdi.

Telnet ve Veri Aktarımı ile RJE

Önceki model, NETRJE için asgari bir uygulama sağlamaktaydı. Bu model, FTP uygulaması gerektirmeden daha iyi veri aktarım olanakları sunar. Bu model yeni komutlar gerektirmez; ancak bağlantıları farklı biçimde düzenler; böylece verilerin komut bağlantısı üzerinden akması gerekmez (bkz. Şekil 2). Veri, CCN NETRJS protokolünde olduğu gibi, ayrı varsayılan bağlantılar üzerinden gönderilir (aksi belirtilmedikçe). Bununla birlikte, bu protokolde kullanılan varsayılanlar, FTP’deki kontrol bağlantısına göre aynı ofsetler olacaktır.

Bu modelin kullanımı, Sunucuya ya INDEF komutu ile ya da bağımsız değişkensiz bir SCHED komutu ile bildirilir. INDEF komutu, kullanıcının girdinin kaynağı olarak varsayılan soket dışında bir soket belirtmesine olanak tanır. Bu tekniğin kullanılacağını belirten bir SCHED ya da INDEF alındığında, Sunucu uygun sokete bağlanmaya çalışacaktır. Eğer bir SCHED komutu gönderilmişse, veri bağlantısı kurulur kurulmaz kullanıcı protokol yorumlayıcısı kartları göndermeye başlayabilir. (Kullanıcı arayüzünün, kartların nereden geleceğini RJE protokol yorumlayıcısına bildirdiği varsayılmaktadır.) Komut INDEF ise, Sunucu SCHED alınana kadar okumaya başlamayacaktır. Benzer şekilde, çıktı hazır olduğunda, yazdırmayı ayarlamak ve başlatmak için bir OUTDEF ya da OUTPUT komutu gönderilir. Bu kipte kullanılan INDEF ve OUTDEF komutları, verinin bir TIP’e ya da yazıcıya taşınmasına da olanak tanıyacaktır.

Bu model, okuyucu ve yazıcı satırları için gerçek veri aktarım biçimlerinin tanımlanmasını gerektirir. Mevcut FTP’nin biçimlerinin ve bağlantı şemalarının benimsenmesini öneriyoruz. Bu çözüm, FTP uygulaması olan kullanıcılar için ek kodlama çabası gerektirmemesi avantajını sağlar ve FTP ile NETRJE uygulamalarını ortak algoritmalardan yararlanacak şekilde düzenlemelerine olanak tanıyabilir. Bu çözüm, Veri Aktarım Protokolü’nün yeniden canlandırılmasıyla kolayca karıştırılabilir. Gelecekte, FTP ve RJE’nin ortak kullanımı için daha katı biçimde tanımlanmış bir Veri Aktarım Protokolü üzerine düşünmek faydalı olabilir.

Bir Kaynak Paylaşım Ağı için Bir RJE Protokolü

Bir senaryo ele alalım.

Kullanıcı, bir kart destesini Sunucuya göndermek istemektedir. Ardından şunu yazar:

SCHED<CRLF>

Sunucu, kontrol bağlantısı üzerinden kullanıcıya bir yanıt gönderirken, kullanıcının varsayılan kart okuyucu soketine bir bağlantı açar.

XXX attempting connection to card reader.

Bağlantı açıldığında başka bir yanıt:

XXX transfer started

ve tamamlandığında:

XXX JOB XA 1423 was successfully submitted.

İş tamamlandığında ve tamamlanma iletisi kullanıcıya gönderildiğinde, kullanıcı çıktıyı Y soketindeki TIP yazıcısına göndermek isteyebilir. Bu durumda şunu yazacaktır:

OUTDEF XA1423 255, Y (255 kendi ana makine adresi olmak üzere).

Sunucu daha sonra sokete bağlanmaya çalışacak ve şu yanıtı verecektir:

XXX printer connection successful.

Kullanıcı her şeyin hazır olduğundan emin olduktan sonra şunu yazacaktır:

OUTPUT XA1423

ve Sunucu göndermeye başlayacak ve kullanıcıya şu yanıtı verecektir:

XXX yazdırma başlatıldı.

Aktarım tamamlandığında Sunucu veri bağlantısını kapatacak ve uygun bir yanıt gönderecektir.

FTP Kullanarak NETRJE

Bu model (Şekil 3’te gösterilmiştir) dosyaların aktarımını gerçekleştirmek için FTP kullanır. Daha gelişmiş RJE sistemleri için bazı sistemlerin bu tür bir modeli kullanması daha kolay olabilir. Bu durum özellikle kullanıcılar girdiyi gerçek bir kart okuyucudan almak ya da çıktıyı gerçek bir satır yazıcısına göndermek yerine yerel dosya sisteminden almak veya yerel dosya sistemine göndermek istediklerinde geçerlidir. Yerel dosya sisteminin kullanılması Veri Aktarım modeli tarafından yasaklanmamış olsa da, FTP üzerinden yaklaşmak daha kolay olabilir. NETRJE ile birlikte FTP kullanılması, ayrıca FTP’nin sunucu–sunucu aktarım mekanizmasının kullanılarak üçüncü bir ana makineden girdi üretilmesine ya da çıktının üçüncü bir ana makineye yönlendirilmesine olanak tanır.

Bu modelin gerektirdiği tek yeni olanak INPATH ve OUTPATH komutlarıdır. FTP kullanılarak Sunucuya girdi aktarılırken, kullanıcının işin iş akışına girebilmesi için nereye gönderileceğini bilmesi gerekir. INPATH komutu yanıt olarak böyle yasal bir yol adını döndürür. Dolayısıyla iş gönderimi için senaryo şu şekildedir: Kullanıcı bir INPATH komutu gönderir; Sunucu kullanıcıya yasal bir Sunucu yol adı ile yanıt verir. Kullanıcı süreci, FTP kullanarak girdiyi bu dosyaya göndermeye başlar. Aktarım tamamlandığında, kullanıcı SCHED <sunucu yol adı> komutunu gönderir. İş tamamlandığında, kullanıcı için oluşturulan yol adı girdi dosyasını yok edebilir ya da etmeyebilir. OUTPATH komutu benzer şekilde, çıktının FTP ile alınabilmesi için yol adını belirlemek amacıyla kullanılır. Bazı sistemler dosya adlarını, kullanıcının bunları işinin parametrelerinden türetebileceği şekilde tanımlayabilir.

Yanıtlar Hakkında Not

Yukarıdaki örneklerin tümünde, gerçek yanıt kodlarını tanımlamaktan kaçındık. Amaç, RFC 640’ta tanımlandığı şekilde, "Gözden Geçirilmiş FTP Yanıt Kodları" ile aynı yanıt yapısını ve uygun olduğu yerlerde aynı numaraları kullanmaktır.

Protokol Ölçümü

Her iyi protokol tanımının ayrılmaz bir parçası, hem protokolün hem de uygulamasının değerlendirilmesine olanak tanıyan bir ölçüm kümesidir. Bu iki işlev sağlar:

  1. Protokol tasarımcısının protokolü değerlendirmesine ve iyileştirmeler yapmasına olanak tanır.
  2. Protokol kullanıcısının bunun ne kadar maliyetli olduğunu bilmesini ve iyileştirmeler talep etmesini sağlar.

Önerilen NETRJE protokolü iki ölçüm kümesi sağlar — biri belirli bir oturum için, diğeri ise genel performans için. Bu ölçümler, üç değer alan bir argüman alacak olan MEASURE komutu ile elde edilebilir: JOB (iş istatistikleri ve maliyet ölçümleri), SESSION (bu oturum için alınan ölçümler) ve GLOBAL (protokolün ve uygulamasının genel performans ölçümleri). Komut, ölçümleri sabit biçimli bir yanıt içinde döndürecektir.

İş Ölçümleri

Bir iş için raporlanan ölçümler şunlardır:

  1. CPU süresi,
  2. G/Ç işlemleri,
  3. depolama alanı–zaman çarpımı,
  4. dolar cinsinden iş maliyeti,
  5. işin yürütülmeden önce beklediği geçen süre ve
  6. işin yürütülmesi için geçen süre.

Oturum Ölçümleri

Bir oturumdan alınan ölçümler şunlardır:

  1. aktarılan bit sayısı,
  2. girdi veya çıktı aktarımlarının iletim hızı,
  3. oturum için CPU süresi, depolama alanı–zaman çarpımı ve G/Ç işlemleri miktarı,
  4. dolar ve sent cinsinden maliyet.

Genel Ölçümler

Genel olarak alınacak ölçümler şunlardır:

  1. komutların ve olası komut biçimlerinin sıklığı,
  2. model sıklığı (hangi gönderim/alım modelinin kullanıldığı),
  3. iletim modu sıklığı,
  4. toplam oturum sayısı,
  5. iletim hızı: ortalama, standart sapma, üst ve alt sınırlar (ayrıca iletim moduna göre),
  6. hem protokol hem de gönderilen işler için CPU süresi, depolama alanı–zaman çarpımı ve G/Ç işlemleri: ortalama, standart sapma ve üst ve alt sınırlar (genel olarak ve ayrıca modele, aktarım moduna ve dosya boyutuna göre).

(Burada iş istatistiklerinin dahil edilmesinin nedeni, yönetim ve sistem personelinin tesisin nasıl kullanıldığına dair bir göstergeye sahip olmasını sağlamaktır.)

NETRJE FTP kullanırken bazı ölçümlerin (örneğin iletim hızı) elde edilmesinin zor olabileceği açıktır. Bu kaçınılmazdır çünkü FTP ölçümlendirilmez. En doğrudan çözüm, FTP’yi de ölçümlendirmektir (ipucu). Nihai tanım için, zorunlu olması gereken alt küme yakından incelenecektir. Yorumlar memnuniyetle karşılanır. Bununla birlikte, bu tür bir tesisin nasıl kullanıldığını ve ne kadar iyi performans gösterdiğini bilmenin çok önemli olduğuna güçlü biçimde inanıyoruz.

Bölüm II. NETRJE Komutlarının Ön Tanımı

Tartışma amacıyla bu bölüm, NETRJE komutlarının ve yanıtlarının çok ön bir tanımını verir. Amaç, her komutun ve başlıca yanıtlarının kısa fakat kapsamlı olmayan bir tanımını vererek protokolün havasını yansıtmaktır. Bunu, eleştirmenlerin ayrıntılara takılmasını caydırmak için değil — çünkü zaman zaman bariz olanı gözden kaçırabiliriz — yalnızca bu makalenin yazımını hızlandırmak için yapıyoruz.

Yanıt şeması, RFC 640’ta tanımlanan gözden geçirilmiş FTP yanıt kodları modelini izleyecektir.

Erişim Denetimi

USER <kullanıcı kodu>
PASS <parola>
ACCT <hesap>

Bunlar, kullanıcıyı sisteme oturum açtırmak için normal işlevleri yerine getirir. Bunlara verilen yanıtlar FTP’deki standart yanıtlar olacaktır. Eski NETRJE’de neden "hesap" bilgisinin dahil edilmediği hiçbir zaman açık olmamıştır. Muhtemelen, bir FTP ya da Telnet kullanıcısı için gerekliyse, bir RJE kullanıcısı için de gerekli olacaktır.

REINIT

Bu komut, NETRJE sunucu sürecinin durumunu yeniden başlatarak yeni bir kullanıcı için hazır hale getirir. Önceki kullanıcı için veri aktarımı sürüyorsa, bunun tamamlanmasına izin verilecektir.

ABORT

Bu komut, veri aktarımını durdurmak için kullanılır. Bu komut Sunucu için yalnızca veri Telnet bağlantısı ya da varsayılan veri soketleri üzerinden aktarılıyorsa anlamlıdır. FTP kullanılıyorsa, bu komutun yürütülmesi USER NETRJE sürecinin sorumluluğundadır.

BYE

Bu komut, Sunucunun kullanıcıyı oturumdan çıkarmasına ve Telnet bağlantısını kapatmasına neden olur. Veri aktarımı sürüyorsa, komutun etkisi aktarım tamamlanana kadar ertelenecektir.

SCHED <girdi bölümü><çıktı bölümü>

<girdi bölümü> ::= <boş> | <sunucu yol adı> [DISCARD]

   INPUT <CRLF> <metin> <CRLF>.<CRLF>

<çıktı bölümü> ::= <boş> | <sunucu yol adı> [DISCARD]

<sunucu yol adı> ::= {yerel olarak tanınabilir karakter dizisi
                      bir ASCII NULL ile sonlandırılmış}

Bu komut, <girdi bölümü> ile tanımlanan girdinin RJE iş akışına sokulmasına ve üretilen çıktının <çıktı bölümü>ne göre elden çıkarılmasına neden olur. Her iki argüman için de boş durum, bilginin daha önce belirtilmiş olduğunu ya da varsayılan olduğunu ima eder.

<girdi bölümü> için <boş>, iki eylemi ima edebilir. Daha önce bir INDEF komutu bir <sunucu yol adı> belirtmişse, iş akışına girdi, dosya adıyla belirtilen dosyadan alınır. INDEF komutu girdinin CCN benzeri bir veri aktarım soketinden gelmesini belirtmişse, SCHED <boş> komutu Sunucunun veri okumaya başlaması için işarettir.

DISCARD değiştiricisi varsa, dosyanın iletildikten sonra ya da alınıp yürütüldükten sonra atılması gerektiğini belirtir. Girdi akışı Telnet bağlantısı üzerinden gönderilecekse, kaynak yerel bir aygıt ya da bir insan kullanıcı olabilir. Bu olanak, diğer tekniklerden birini kullanamayan mini-hostlar ve iş denetimini doğrudan terminalinden girmek isteyen kullanıcılar için sağlanmıştır.

Çıktı için boş değer, işin birincil çıktı dosyasını (varsayılan) ya da daha önce belirtilmiş bir sunucu yol adını (OUTDEF komutu) belirtir.

Bu komuta verilen başarılı yanıtlar, yerel RJE sistemi tarafından atanan herhangi bir iş kimliğini ve diğer durum bilgilerini belirtmelidir. Başarısızlık, dosyaların mevcut olmaması, erişimin reddedilmesi vb. nedenlerden kaynaklanır.

OUTPUT <çıktı belirtimi>

<çıktı belirtimi> ::= <iş kimliği><xmsn bölümü> | <iş kimliği><sunucu yol adı>

<xmsn bölümü> ::= <boş> | /<G/Ç parametreleri>

<G/Ç parametreleri> ::= <xmsn parametreleri>, <hedef>

Bu komut, Sunucuya hangi çıktının kullanıcıya gönderileceğini, nasıl gönderileceğini ve kime gönderileceğini bildirir. <G/Ç parametreleri> bölümü, çıktının bir TIP yazıcısına gönderilebilmesi için bir ana makine ve soketin belirtilmesine ya da alternatif olarak Telnet bağlantısı üzerinden veya varsayılan veri soketlerine gönderilmesine olanak tanır. Bu argüman ayrıca verinin biçimini ve gösterimini de belirtir.

Sunucu bu komutu aldığında, çıktıyı belirtilen şekilde ana makineye iletmeye başlayacaktır. Bu komutun yanıt yapısı, çıktının nasıl taşındığına bağlı olacaktır ve daha sonra ayrıntılı olarak ele alınacaktır.

INPATH

Bu komut, kullanıcıya Sunucu üzerinde yasal bir yol adı döndürür. Kullanıcı daha sonra girdisini, RJE tesisine gönderilmek üzere bu yol adına aktarabilir.

OUTPATH

Bu komut, INPATH’e benzer bir işlev görür.

DISCARD <iş-dosya-kimliği> | <sunucu yol adı>

Bu komut, kullanıcının bir işle ilişkili girdi ya da çıktı dosyalarını yok etmesine olanak tanır.

INDEF <iş kimliği><G/Ç parametreleri>

OUTDEF <iş kimliği><G/Ç parametreleri>

Bu komutlar, kullanıcının girdi göndermek ya da çıktı almak için gerekli parametreleri belirtmesine olanak tanır. Bu komut, verinin nasıl aktarılacağını ve biçimini vb. belirtir.

CANCEL <iş kimliği>

Bu komut, bir işin RJE iş akışından iptal edilmesine olanak tanır.

STATUS <durum argümanı>

<durum argümanı> ::= <boş> | <kullanıcı kimliği> | <iş kimliği> | <iş kimliği> <iş-dosya-kimliği>

Bu komut, kullanıcının RJE oturumunun durumunu, kendi kullanıcı kodu altındaki tüm işleri, belirli bir işi ya da belirli bir işin çıktısını belirlemesine olanak tanır.

ALTER <iş kimliği><site’a özgü seçenek>

SITE <site’a özgü seçenek>

Bu komutlar, site’a özgü komutların Sunucu RJE sistemine iletilmesine olanak tanır. ALTER komutu belirli işleri etkilemeyi amaçlarken, SITE komutu daha genel etkiye sahip komutlar için kullanılır. Tek bir komutta birleştirilebilirler.

OP <operatör mesajı>

Bu komut, Sunucu sitesindeki operatöre mesaj gönderilmesine olanak tanır.

Önerilen NETRJE için Yanıt Kodları

Bu protokol için yanıt kodları, RFC 640’ta yeni FTP belirtimi için önerilen modeli izleyecektir. Bir hatırlatma olarak, bu RFC’den ilgili bilgileri buraya ekliyoruz:

Yanıt kodunun ilk hanesi için beş değer vardır:

1yz  Olumlu Ön Yanıt

İstenen eylem başlatılmaktadır; yeni bir komutla devam etmeden önce başka bir yanıt bekleyin. (Tamamlama yanıtı gelmeden önce kullanıcı sürecinin başka bir komut göndermesi protokol ihlali olacaktır; ancak sunucu-FTP süreçleri, önceki bir komut sürerken gelen tüm komutları kuyruğa almalıdır.) Eşzamanlı izlemenin zor olduğu uygulamalarda, bu tür bir yanıt komutun kabul edildiğini ve kullanıcı sürecinin artık veri bağlantılarına dikkat edebileceğini belirtmek için kullanılabilir.

2yz — Olumlu Tamamlama Yanıtı

İstenen eylem başarıyla tamamlanmıştır. Yeni bir istek başlatılabilir.

3yz — Olumlu Ara Yanıt

Komut kabul edilmiştir, ancak istenen eylem, ek bilgi alınana kadar beklemeye alınmıştır. Kullanıcı bu bilgiyi belirten başka bir komut göndermelidir. Bu yanıt, komut sırası gruplarında kullanılır.

4yz — Geçici Olumsuz Tamamlama Yanıtı

Komut kabul edilmemiştir ve istenen eylem gerçekleşmemiştir, ancak hata durumu geçicidir ve eylem yeniden istenebilir. Kullanıcı, varsa, komut dizisinin başına dönmelidir. “Geçici” kavramına bir anlam atamak zordur; özellikle iki ayrı sitenin (Sunucu ve Kullanıcı süreçleri) yorumu üzerinde anlaşması gerektiğinde. 4yz kategorisindeki her yanıtın biraz farklı bir zaman değeri olabilir, ancak amaç kullanıcı sürecinin yeniden denemeye teşvik edilmesidir. Bir yanıtın 4yz mi yoksa 5yz (Kalıcı Olumsuz) kategorisine mi girdiğini belirlemede kullanılan genel bir kural şudur: Komut biçiminde ya da Kullanıcı veya Sunucu özelliklerinde hiçbir değişiklik yapılmadan komutlar yinelenebiliyorsa (örneğin komut aynı argümanlarla aynı şekilde yazılıyorsa, kullanıcı dosya erişimini ya da kullanıcı adını değiştirmiyorsa, sunucu yeni bir uygulama koymuyorsa) yanıt 4yz’dir.

5yz — Kalıcı Olumsuz Tamamlama Yanıtı

Komut kabul edilmemiştir ve istenen eylem gerçekleşmemiştir. Kullanıcı süreci, aynı isteği (aynı sıra içinde) yinelemekten caydırılır. Bazı “kalıcı” hata durumları bile düzeltilebilir; bu nedenle insan kullanıcı, yazım değiştirildikten sonra ya da kullanıcı dizin durumunu değiştirdikten sonra, gelecekte bir noktada kullanıcı sürecini komut dizisini yeniden başlatmaya yönlendirmek isteyebilir.

İkinci Hanede Kodlanan İşlev Gruplamaları

Üçüncü hane, ikinci hane tarafından belirtilen işlev kategorilerinin her birinde daha ince bir anlam derecelendirmesi verir. Aşağıdaki yanıt listesi bunu gösterecektir. Her yanıtla ilişkilendirilen metnin zorunlu değil, yol gösterici olduğu ve hatta ilişkilendirildiği komuta göre değişebileceği unutulmamalıdır. Yanıt kodları ise, buna karşılık, kesinlikle belirtimleri izlemelidir. Sunucu uygulamaları, burada tanımlananlardan yalnızca biraz farklı durumlar için yeni kodlar türetmemeli; bunun yerine zaten tanımlanmış kodları uyarlamalıdır.

Aşağıda yanıt koduna göre sıralanmış bir yanıt listesi verilmiştir. RJE için bazı yeni yanıtlar eklenmiştir; bunlar okuyucuya yardımcı olmak için yıldız işaretiyle belirtilmiştir.

Yanıt Kodları

110 Yeniden Başlatma İşaretleyici Yanıtı

Bu durumda metin kesindir ve belirli bir uygulamaya bırakılmamıştır; şu şekilde olmalıdır:

MARK yyyy = mmmm

burada yyyy kullanıcı süreci veri akışı işaretleyicisidir ve mmmm Sunucunun eşdeğer işaretleyicisidir. (İşaretleyiciler ile “=” arasında boşluklara dikkat ediniz.)

120–150

200–227

230–264

331–360

421–452

500–564

RJE Komutları için Yanıt Kodları

USER

PASS

ACCT

BYE

REINIT

ABORT

STATUS

HELP

SOCK

BYTE, MODE, TYPE, STRU

SCHED

OUTPUT

OUTDEF

INDEF

INPATH / OUTPATH

DISCARD

CANCEL

STATUS (RJE)

ALTER

SITE

OP

Kaynaklar

Şekiller

Şekil 1. Yalnızca Telnet Kullanan RJE

+-----------+
!  user     !
!  RJE      !
! interface !
+-----------+     +--------+    Telnet Connection     +--------+
      !           !        !                          !        !
      !           ! user   !------------------------->! server !
      ------------! RJE    !                          ! RJE    !
                  ! module !<-------------------------! module !
                  !        !                          !        !
                  +--------+                          +--------+

   tüm RJE komutları, yanıtları ve veriler Telnet bağlantısı üzerindedir

Şekil 2. Ayrı Bir Veri Bağlantısı Kullanan RJE

+-----------+     +--------+     Telnet Connection      +--------+
!  user     !     ! user   !--------------------------->! server !
!  RJE      !     ! RJE    !  RJE Komutları ve Yanıtları ! RJE    !
! interface !     ! module !<---------------------------! module !
+-----------+     +--------+                            +--------+
     !                   !                                     !
+--------+           +--------+                            +--------+
! data   !  RJE Data ! data   !----------------------------! data   !
!transfer!           !transfer!                            !transfer!
+--------+           +--------+                            +--------+
     !                                                          !
Kullanıcının Yerel Dosya Sistemi                    Sunucunun RJE Sistemi
Kart Okuyucular veya Satır Yazıcılar

Şekil 3. FTP Kullanan RJE

+-----------+     +--------+     Telnet Connection      +--------+
!  user     !     ! user   !--------------------------->! server !
!  RJE      !     ! RJE    !  RJE Komutları ve Yanıtları ! RJE    !
! interface !     ! module !<---------------------------! module !
+-----------+     +--------+                            +--------+

                +--------+     Telnet Connection      +--------+
                ! user   !--------------------------->! server !
                ! FTP    !  FTP Komutları ve Yanıtları ! FTP    !
                ! module !<---------------------------! module !
                +--------+                            +--------+

                    +--------+      RJE Verisi       +--------+
                    ! data   !----------------------! data   !
                    !transfer!                      !transfer!
                    +--------+                      +--------+

Kullanıcının Yerel Dosya Sistemi                    Sunucunun Dosya Sistemi
Kart Okuyucular veya Satır Yazıcılar