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

Ağ Tabanlı Kaynak Paylaşımı için Yüksek Düzeyli Bir Çerçeve

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

Ağ Tabanlı Kaynak Paylaşımı için Yüksek Düzeyli Bir Çerçeve

Amaç: Kaynak Paylaşımı

Günümüzde artık uluslararası bir nitelik kazanmış olan ARPA Ağı (ARPANET) dâhil tüm kaynak paylaşımı bilgisayar ağlarının temel amacı, coğrafi olarak dağılmış donanım, yazılım ve insan kaynaklarını yararlı bir biçimde birbirine bağlamaktır [1]. Bu amaca ulaşmak, her bir bileşen bilgisayar içinde çeşitli düzeylerde destek yazılımlarının tasarlanmasını ve uygulanmasını, ayrıca bunların etkileşimini yöneten ağ genelinde geçerli “protokollerin” (yani ağ iletilerinin biçimi ve göreli zamanlamasına ilişkin uzlaşımların) tanımlanmasını gerektirir. Bu makale, 1970 yılında bu alandaki çalışmalar başladığından beri ARPANET sistem geliştiricilerinin izlemekte olduğu yaklaşıma bir alternatif ortaya koymakta ve herhangi bir büyük bilgisayar ağı içinde dağıtık sistemlerin modellenmesine yönelik bir strateji önermektedir.

Bu makalenin birinci bölümü, ortak temel olarak ağ genelinde bir süreçler arası iletişim olanağına sahip, uygulamaya bağımlı protokoller ailesinin tanımlanmasını içeren baskın ARPANET protokol stratejisini açıklamaktadır. İkinci bölümde, bu protokol ailesini karakterize eden uygulamadan bağımsız komut/yanıt disiplini tanımlanmakta ve bunun ayrı bir protokol olarak yalıtılması önerilmektedir. Böyle bir yalıtım, protokolü uygulayan yazılımın her bir uygulama programının içinden ayrıştırılarak, tek bir kurulum tarafından bakımı yapılan modül olarak sağlanmasına olanak tanıyacağından, uygulama programcısının iş yükünü azaltacaktır. Makalenin son bölümü ise, bu tür ağ etkileşimi için genişletilebilir bir model önermekte olup, bu modelin kendi başına ağ kaynaklarının kullanımını daha da teşvik edeceği ileri sürülmektedir.

Kaynak Paylaşımına Yönelik Güncel Yazılım Yaklaşımı

İşlev Odaklı Protokoller

Kaynak paylaşımını kolaylaştırmaya yönelik mevcut ARPANET yazılım yaklaşımı, literatürde başka yerlerde ayrıntılı olarak ele alınmıştır [2, 3, 4]. Kısaca, bu yaklaşım; çeşitli “ana bilgisayarların” işletim sistemlerinin ağ genelinde bir süreçler arası iletişim (IPC) olanağını desteklemek üzere iş birliği yaptığı bir Ana Bilgisayar–Ana Bilgisayar Protokolünün tanımlanmasını ve ardından IPC üzerinden belirli hizmetleri sunan ve alan süreçler tarafından kullanılan çeşitli işlev odaklı protokollerin geliştirilmesini içerir. Her bir işlev odaklı protokol, hizmeti sağlayan yerleşik bir “sunucu süreci” ile, bir kullanıcı adına hizmet talep eden bir “kullanıcı süreci” arasındaki diyaloğu düzenler (bu makale boyunca, insan kullanıcı ile onun adına hareket eden bilgisayar sürecini ayırt etmek için “kullanıcı” ve “kullanıcı süreci” terimleri tutarlı biçimde kullanılacaktır).

Mevcut Ana Bilgisayar–Ana Bilgisayar Protokolü 1970 yılından beri hizmet vermektedir. İlk tasarımı ve uygulanmasından bu yana çeşitli eksiklikler belirlenmiş ve birkaç alternatif protokol önerilmiştir [5, 6]. Bu düzeyde yapılacak iyileştirmelerin ağ kaynak paylaşımı üzerinde kuşkusuz olumlu bir etkisi olacaktır; ancak bu makale, yalnızca bir tür IPC’nin varlığını varsaymakta ve dikkatini daha üst düzey protokol tasarımı konularına yoğunlaştırmaktadır.

Bu makalede sözü edilen işlev odaklı protokollerin her biri, ilgili uygulama alanı için resmi ARPANET protokolünü oluşturmaktadır ve bu nedenle bugün Ağı meydana getiren yaklaşık 75 ana bilgisayar kurulumunun neredeyse tamamında uygulanmaktadır. Bu makalenin odak noktası esas olarak, yaygın biçimde uygulanmış bu protokol ailesi (ve temsil ettiği felsefe) üzerinedir. Söylemeye gerek yok ki, ARPANET içinde başka önemli kaynak paylaşımı araçları da geliştirilmiştir. Bolt, Beranek and Newman, Inc. tarafından tasarlanan ve uygulanan Resource Sharing Executive (RSEXEC) [7], bu tür çalışmalara mükemmel bir örnek sunmaktadır.

Etkileşimli Kaynak Paylaşımıyla İlgili Deneyimler ve Sınırlamalar

En eski ve hâlâ açık ara en yoğun kullanılan işlev odaklı protokol, Telekomünikasyon Ağı protokolü (TELNET) [8] olup, bir bilgisayardaki bir terminali başka bir bilgisayardaki etkileşimli bir zaman paylaşımlı sisteme fiilen bağlar ve kullanıcının, uzak sistemle sanki onun yerel kullanıcılarından biriymiş gibi terminal üzerinden etkileşime girmesine olanak tanır.

Şekil 1’de gösterildiği üzere TELNET, kullanıcının terminalini izleyen bir kullanıcı sürecinin, IPC iletişim kanalı aracılığıyla, hedef zaman paylaşımlı sisteme erişimi olan bir sunucu süreciyle nasıl birbirine bağlanacağını tanımlar. TELNET ayrıca, kullanıcının komutları ile sistemin yanıtlarının makineler arasında iletim sırasında temsil edileceği standart bir karakter kümesini de belirler. Ancak bu alışverişlerin sözdizimi ve anlambilimi sistemden sisteme değişir ve protokol tarafından düzenlenmez; kullanıcı ve sunucu süreçleri yalnızca karakterleri insan kullanıcı ile hedef sistem arasında ileri geri taşır.

TELNET’in mümkün kıldığı uzak kaynakların etkileşimli kullanımı, doğal ve son derece görünür bir kaynak paylaşımı biçimi olsa da, birkaç sınırlama uzun vadeli yararlılığını ciddi biçimde azaltmaktadır:

  1. Kullanıcıya, kaynağın kendi sistemine ait tüm yükleri dayatır.

    Uzak bir kaynaktan yararlanabilmek için kullanıcı, yerel sisteminin sağladığı tanıdık çalışma ortamını terk etmek ve kendine özgü bir sistem yapısına (giriş, çıkış ve alt sistemlere giriş-çıkış yordamları) ve komut dili disiplinine (komut tanıma ve tamamlama uzlaşımları, düzenleme karakterleri vb.) sahip yabancı bir ortama girmek zorundadır. Bu nedenle etkileşimli kaynak paylaşımı, kullanıcının etkili biçimde çalışabilmesi için gereksinim duyduğu düzenli ve tutarlı atölye ortamını sağlamada yetersiz kalır [9].

  2. Mevcut kaynaklardan yeni bileşik kaynakların kademeli olarak oluşturulması için bir temel sunmaz.

    Her bir kaynak tarafından dayatılan ağ erişim disiplini, makine odaklı bir iletişim protokolü yerine insan tarafından tasarlanmış bir komut dili olduğundan, bir kaynağın diğerlerinin hizmetlerinden programlı olarak yararlanması neredeyse olanaksızdır. Bunun yapılabilmesi, programın karmaşık yankılama ve geri bildirim özellikleriyle; yapılandırılmamış, hatta istenmeyen sistem yanıtlarıyla vb. başarıyla başa çıkmasını gerektirir. Dolayısıyla etkileşimli kaynak paylaşımı, mevcut kaynakların yapı taşları olarak kullanılıp yeni ve daha güçlü kaynakların meydana getirilmesini sağlayacak bir ortam sunmaz.

Etkileşimli kaynak paylaşımının bu içsel sınırlamaları, kullanıcı ve sunucu süreçleri arasındaki diyaloğu basitleştiren ve standartlaştıran bir protokolle ortadan kaldırılabilir. Böyle bir protokol verildiğinde, kullanıcının yararlanmak isteyebileceği çeşitli uzak kaynaklar, onunla bu kaynaklar arasına, komutlarını uygun protokol ifadelerine dönüştüren bir komut dili yorumlayıcısı yerleştirilerek tek, tutarlı bir atölye gibi gösterilebilir [10, 11]. Bileşik kaynakların oluşturulması da mümkün hâle gelir; çünkü her bir kaynağa makine odaklı bir protokol aracılığıyla erişilir ve böylece ağ içindeki diğer süreçler tarafından kolaylıkla kullanılabilir.

Belirli Uygulama Alanlarında Makineler Arası Diyaloğun Standartlaştırılması

TELNET protokolü ARPANET içinde tasarlanıp yaygın biçimde uygulandıktan sonra, insan kullanıcılar yerine programlar tarafından kullanılmak üzere tasarlanmış bir işlev odaklı protokoller ailesi üzerinde çalışmalara başlanmıştır. Bu protokollerin her biri, belirli bir uygulama alanında makineler arası diyaloğu standartlaştırır. TELNET yalnızca kullanıcı ve sunucu süreçlerinin IPC olanağı üzerinden nasıl bağlanacağını ve bağlandıktan sonra iki sürecin hangi karakter kümesiyle iletişim kuracağını belirlerken, bu ailenin her bir üyesi buna ek olarak, diyaloğu oluşturan komut ve yanıtların sözdizimini ve anlambilimini de tanımlar.

Bu aile içindeki protokoller, her biri kendi uygulamaya özgü komut kümesini tanımladığından, içerik bakımından zorunlu olarak farklılık gösterir. Örneğin Dosya Aktarım Protokolü (FTP) [12], dosyaların işlenmesine yönelik komutlar tanımlarken, Uzaktan İş Girişi Protokolü (RJE) [13] yığın işlerin işlenmesine yönelik komutlar tanımlar. Ancak aile genelindeki protokoller biçimsel olarak benzerdir; ailenin her yeni üyesi, öncekilerin fiziksel özelliklerini basitçe devralmıştır. Bu nedenle FTP ve RJE, komut ve yanıtların biçimlendirilmesi için aynı uzlaşımları uygular.

Bu ortak komut/yanıt disiplini, komut ve yanıtların sırasıyla aşağıdaki biçimlere sahip olmasını gerektirir:

command-name    <SP> parameter <CRLF>
response-number <SP> text      <CRLF>

Kullanıcı süreci tarafından çağrılan her komut NAME ile tanımlanır ve tek bir PARAMETER almasına izin verilir. Sunucu süreci tarafından üretilen her yanıt, kullanıcı süreci tarafından yorumlanacak üç basamaklı ondalık bir yanıt NUMBER’ı ve (gerekirse kullanıcıya sunulmak üzere) açıklayıcı bir TEXT içerir. Yanıt numaraları, örneğin olumlu ve olumsuz onayların kullanıcı süreci tarafından kolayca ayırt edilebilmesini sağlayacak biçimde atanır.

FTP, diğerlerinin yanı sıra, sunucu sürecinin dosya sistemi içinde dosyaları sırasıyla alma, dosyaya ekleme, dosyanın yerine yazma ve silme işlemleri için aşağıdaki komutları (her biri olası yanıtlarından biriyle birlikte) içerir:

Komut Yanıt
RETR filename 250 Beginning transfer.
APPE filename 400 Not implemented.
STOR filename 453 Directory overflow.
DELE filename 450 File not found.

İlk üç komut yalnızca bir dosyanın bir makineden diğerine aktarımını başlatmaya hizmet eder. Aktarımın kendisi ayrı bir IPC kanalı üzerinde gerçekleşir ve esasen ayrı bir protokole karşılık gelen kurallarla yönetilir.

Genel komut biçimi yalnızca tek bir parametreye izin verdiğinden, çok parametreli işlemler komut dizileri olarak uygulanmak zorundadır. Bu nedenle bir dosyayı yeniden adlandırmak için iki komut gerekir:

Komut Yanıt
RNFR oldname 200 Next parameter.
RNTO newname 253 File renamed.

Alternatif Bir Yaklaşımın Temeli Olarak Bir Komut/Yanıt Protokolü

Komut/Yanıt Disiplininin Ayrıştırılmasının Önemi

FTP, RJE ve bu aile içindeki diğer protokollerin ortak bir komut/yanıt disiplinini paylaşması, protokol literatüründe resmen tanınmış bir olgu değildir ve her yeni protokol belgesi, sanki ilk kez anlatılıyormuş gibi bunu ayrıntılı biçimde açıklar. Bu uzlaşımlar, kullanıldıkları çeşitli bağlamlardan yalıtılmış biçimde hiçbir yerde kodlanmamış olup, her bir işlev odaklı protokolün gerekli ama görece önemsiz bir yönü olarak görülmüştür. Böylece bu ortak komut/yanıt disiplini, sahip olduğu önemli ve uygulamadan bağımsız bir protokol olma niteliğiyle tanınmamıştır.

Bu gözden kaçırmanın, ARPANET içinde kaynak paylaşımının büyümesi üzerinde iki önemli olumsuz etkisi olmuştur:

  1. Komut/yanıt disiplininin ilkel kalmasına izin vermiştir.

    Daha önce belirtildiği gibi, birden fazla parametre gerektiren işlemler tutarlı biçimde iki ya da daha fazla ayrı komut olarak uygulanmaktadır; bu komutların her biri bir yanıt gerektirir ve dolayısıyla tam bir gidiş-dönüş ağ gecikmesinin ek yükünü getirir. Ayrıca, karakter dizileri dışındaki parametre türlerinin kodlanmasına yönelik standartlar yoktur ve bir komut yanıtı içinde sonuçların döndürülmesine ilişkin bir olanak da bulunmamaktadır.

  2. Uygulama programcısına, uzak süreçlere istenen işlevsel düzeyde erişmesini sağlayan ağ çalışma zamanı ortamını (RTE) uygulama yükünü yüklemiştir.

    Aşağıdakine benzer terimlerle uzak süreçlere seslenebilmeden önce:

    execute function DELE with argument TEXTFILE
    on machine X

    uygulama programcısı, her yazdığı programda istisnasız olarak yaptığı gibi, istenen program arayüzünü sağlarken aynı zamanda üzerinde uzlaşılmış komut/yanıt disiplinini uygulayan bir modül inşa etmek zorundadır. Bu çalışma zamanı ortamı, giden komutları doğru biçimde biçimlendirmek, IPC olanağıyla arabirim kurmak ve gelen yanıtları ayrıştırmak için gereken kodu içerir. Sistem yalnızca IPC olanağını temel olarak sunduğundan, uygulama programcısı önce edinilmesi gereken uzmanlık bilgisi ve yazılım miktarı nedeniyle uzak kaynakları kullanmaktan caydırılmaktadır.

Buna karşılık, komut/yanıt disiplini ayrı bir protokol olarak resmileştirilmiş olsaydı, bunun sonraki işlev odaklı protokollerde kullanımı sistem programcısı tarafından haklı olarak öngörülebilir ve bir kurulum genelinde kullanılmak üzere tek bir çalışma zamanı ortamı geliştirilebilirdi (en kötü durumda, makine başına ve programlama dili başına bir uygulama gerekebilirdi). Bu modül daha sonra bir kütüphaneye yerleştirilebilir ve Şekil 2’de gösterildiği gibi, her yeni uygulama programı ile birlikte bağlanarak yüklenebilir (ya da başka bir yolla erişilebilir hâle getirilebilir); böylece uzak kaynakların kullanımı büyük ölçüde basitleştirilirdi.

Ayrıca, yapılacak iyileştirmeler bu hizmetleri kullanan her uygulama programına kazanç sağlayacağından, çalışma zamanı ortamı zamanla programcıya ek yeni hizmetler sunacak şekilde kademeli olarak zenginleştirilebilirdi.

Bu Makalenin Tezi

Bu makalenin tezi, ağ kaynak paylaşımını kolaylaştırmanın anahtarlarından birinin şunlar olduğu yönündedir:

  1. Geniş bir uygulama protokolleri sınıfı için ortak olan komut/yanıt disiplininin ayrı bir protokol olarak yalıtılması;
  2. Bu yeni, uygulamadan bağımsız protokolün esnek ve verimli hâle getirilmesi; ve
  3. Her bir kurulumda, bunu kullanarak uygulama programcısına uzak kaynaklara kolay ve yüksek düzeyli erişim sağlayan bir çalışma zamanı ortamının (RTE) geliştirilmesi.

Komut/Yanıt Protokolü için Teknik Özellikler

Geniş bir uygulama protokolleri sınıfı için temel olarak bir komut/yanıt protokolünün (bundan sonra Protokol olarak anılacaktır) değerini ortaya koyduktan sonra, geriye Protokolün alabileceği biçime ilişkin önerilerde bulunma görevi kalmaktadır. Sekiz gereksinim vardır. İlk olarak, yerini aldığı disiplinin yeteneklerini yeniden sağlamalıdır:

  1. Uzak süreç tarafından uygulanmış, adlandırılmış keyfi komutların (ya da işlevlerin) çağrılmasına izin vermek.
  2. Komut sonuçlarının, hem komutu çağıran programa hem de onun denetimi altında çalışıyor olabilecek kullanıcıya yardımcı olacak biçimde raporlanmasına olanak tanımak.

İkinci olarak, Protokol, selefinin bilinen eksikliklerini gidermelidir; yani:

  1. Tek bir komuta argüman olarak keyfi sayıda parametrenin sağlanmasına izin vermek.
  2. Karakter dizileriyle sınırlı olmamak üzere, çeşitli parametre türleri için gösterimler sağlamak.
  3. Komutların, argüman olarak parametre almalarının yanı sıra, sonuç olarak parametre döndürmelerine izin vermek.

Ve son olarak, Protokol, teşvik etmeyi amaçladığı daha karmaşık dağıtık sistemler tarafından gereksinim duyulan ek yetenekleri sağlamalıdır. Daha sonra başkaları da tanımlanabilir olmakla birlikte, aşağıdaki üç yetenek şu anda önemli olarak kabul edilmektedir:

  1. Sunucu sürecinin kullanıcı sürecindeki komutları çağırmasına izin verin; yani çoğu zaman uygunsuz olan kullanıcı/sunucu ayrımını bütünüyle ortadan kaldırın ve her sürecin diğerinde komut çağırabilmesini sağlayın.

    Daha önce değinilen atölye ortamında, örneğin, kullanıcı süreci komut dili yorumlayıcısıdır ve sunucu süreci kullanıcının erişimine açık yazılım araçlarından herhangi biridir. Çoğu komut yorumlayıcı tarafından verilerek araca yönlendirilirken, zaman zaman aracın yorumlayıcıda ya da başka bir araçta komut çağırması gerekir. Örneğin grafiksel bir metin düzenleyici, bir düzenleme işleminden sonra kullanıcının ekran görüntüsünü güncellemek için yorumlayıcı içinde komutlar çağırmak zorundadır.

  2. Bir sürecin eşzamanlı yürütme için iki ya da daha fazla komutu kabul etmesine izin verin.

    Metin düzenleyici, kullanıcının tek bir komutla uzun süren bir biçimlendirme işlemi başlatmasına ve buna karşılık ilk komuta bir yanıt gelmeden önce ek, daha kısa komutlar vermeye devam etmesine izin vermek isteyebilir.

  3. Bir komutu gönderen sürecin, komutun normalde üreteceği yanıtı bastırabilmesine izin verin.

    Bu özellik, komutu çağıran sürecin bir yanıtı gereksiz gördüğü durumlarda ağ trafiğinin azaltılmasına olanak tanır. Her zaman başarılı olan ancak hiçbir zaman sonuç döndürmeyen komutlar, bu tür bir işlem için açık adaylardır.

Bu Özellikleri Karşılayan Bir Protokolün Formülasyonu

Yukarıda listelenen sekiz gereksinim, aşağıdaki iki mesajın tanımlandığı bir protokol ile karşılanır:

Burada ve sonraki protokol açıklamalarında, köşeli parantez içine alınmış öğeler isteğe bağlıdır.

İlk mesaj, adı belirtilen komutu verilen argümanları kullanarak çağırır. İkincisi, birincisine nihai olarak yanıt olarak gönderilir ve tamamlanan komutun sonucunu ve çıktıları geri döndürür. Sonuç (outcome) bir komutun başarısız olduğunu gösterdiğinde, komutun sonuçlarının bir hata numarası ve tanılama iletisi olması zorunludur; ilki çağıran programın bundan sonra ne yapacağını belirlemesine yardımcı olmak için, ikincisi ise gerekirse kullanıcıya sunulmak içindir. Böylece protokol, hataların raporlanması için bir çerçeve sağlar; hata numaralarının atanması ve hata iletilerinin metninin oluşturulması görevlerini ise uygulama programına bırakır.

Mevcut komut/yanıt disiplininde bulunmayan, Protokolün birkaç öğesi vardır:

  1. Gereksinim 5’in karşılanması olarak sonuçlar.

  2. Gereksinim 6’dan kaynaklanan, komutları yanıtlerden ayıran bir mesaj türü.

    Mevcut disiplinde bu ayrım örtüktür; çünkü kullanıcı ve sunucu süreçleri sırasıyla yalnızca yanıtları ve komutları alır.

  3. Gereksinimler 7 ve 8’den kaynaklanan, bir komut ile onun yanıtını ilişkilendiren isteğe bağlı bir işlem tanımlayıcısı (TID).

    Bir komutta işlem tanımlayıcısının bulunması, tanımlayıcıyı yineleyen bir yanıtın gerekliliğini ima eder; ayrıca eşzamanlı olarak beklemede olan hiçbir iki komut aynı tanımlayıcıyı taşıyamaz.

Gereksinimler 3 ve 4 — her komut ya da yanıtla birlikte çeşitli türlerde keyfi sayıda parametre iletme yeteneği — en ekonomik ve etkili biçimde, somut parametrelerin modellenebileceği küçük bir ilkel veri türleri kümesi (örneğin boole’ler, tamsayılar, karakter dizgeleri) tanımlanarak ve bu tür parametrelerin kodlanabileceği bir iletim biçimi belirlenerek karşılanır. Ek A, geniş bir uygulama sınıfı için uygun bir veri türleri kümesi önermektedir; Ek B ise bazı olası iletim biçimlerini tanımlar.

Yukarıda verilen protokol açıklaması elbette bütünüyle simgeseldir. Ek C, Protokolün olası bir kodlamasını ayrıntılı olarak inceler.

Şimdiye Kadar İleri Sürülen Argümanların Özeti

Yazar, şimdiye kadar sunulanların çok azının okuyucu tarafından tartışmalı bulunacağını ummaktadır. Aşağıdaki temel argümanlar ileri sürülmüştür:

  1. Kaynak paylaşımının daha etkili biçimleri, uzak kaynakların yalnızca insan kullanıcılar için değil, diğer programlar için de işlevsel olarak erişilebilir olmasına bağlıdır.
  2. Mevcut yaklaşımı kullanarak bu tür erişimi sağlayan uygulamaya bağımlı protokoller, uzak kaynakları işlevsel düzeyde erişilebilir kılmak için gereken (sistemin sağladığı IPC olanağının üzerindeki) ek yazılım katmanını oluşturma görevini uygulama programcısına bırakır ve böylece bunların kullanımını caydırır.
  3. Keyfi uzak kaynaklara işlevsel düzeyde esnek ve verimli erişim sağlayan, tek ve kaynaktan bağımsız bir protokol tasarlanabilir.
  4. Bu protokol, her kurulumda, uzak kaynakları işlevsel düzeyde erişilebilir kılan ve böylece uygulama programcısı tarafından kullanılmalarını teşvik eden, uygulamadan bağımsız bir ağ çalışma-zamanı ortamının kurulmasını mümkün kılar.

Burada önerilen kadar basit bir protokol, bir bilgisayar ağı içinde kaynak paylaşımını teşvik etme konusunda büyük bir potansiyele sahiptir. İlk olarak, özel dağıtım protokollerinin tasarlanması, belgelenmesi ve uygulanması gereksinimini ortadan kaldırarak mevcut kaynakların ağ kullanımına uyarlanma maliyetini azaltır. İkinci olarak, uygulamaya özgü arayüz yazılımı gereksinimini ortadan kaldırarak uzak kaynakların kullanımını teşvik eder. Son olarak ise, ağ yazılımı pazarında kolayca sunulup kullanılabilmeleri nedeniyle, özellikle uzak erişim için geliştirilmiş yeni kaynakların üretilmesini teşvik eder.

Ağ Ortamının Yüksek Düzeyli Bir Modeli

Protokolün Dayattığı Modelin Önemi

Yukarıda önerilen Protokol, uygulama programcısına ağ ortamının belirli bir modelini dayatır. Heterojen bir bilgisayar ağında, genel uygulama için tasarlanmış neredeyse her protokol bu etkiye sahiptir; çünkü her sistemde somut ama biraz farklı karşılıkları olan bir işlem sınıfını idealleştirir. Örneğin daha önce değinilen ARPANET TELNET Protokolü, Ağ genelinde kullanılan çok sayıdaki gerçek terminale en iyi uyumu sağlamaya çalışan bir Ağ Sanal Terminali tanımlar.

Şu anki biçimiyle Protokol, uzak bir kaynağı basit ve katı biçimde tanımlanmış bir komut diline sahip etkileşimli bir program olarak modeller. Bu model, Protokolün türetildiği işlev yönelimli protokollerin, kullanıcı yönelimli komut dillerinin karmaşıklığı ve çeşitliliği nedeniyle gerekli olmasından doğal olarak doğar. Bu nedenle Protokol, kullanıcılara halihazırda sunulan gelişmiş komut dillerine bir ek olarak, programlar tarafından kolayca kullanılabilecek basit komut dilleri ailesi sağlamak için bir araç olarak meşru biçimde görülebilir.

Komut/yanıt modeli doğal bir model olmakla birlikte, başka modeller de mümkündür. Uzak bir kaynak, diğer bilgisayar süreçlerinden aldığı istekleri işleyen ve yanıtlayan bir süreç olarak da modellenebilir. Bu istek/yanıt modeli, Protokolün süreçler arası iletişim için bir araç olduğu ve hiçbir insan kullanıcının doğrudan dahil olmadığı gerçeğini vurgular.

Komut/yanıt modeli yerine istek/yanıt modelinin kullanılması, Protokolde yalnızca biçimsel değişiklikler gerektirir:

Yukarıdaki formülasyonda, "REQUEST", "REPLY" ve "op-code" terimleri sırasıyla "COMMAND", "RESPONSE" ve "command-name" yerine geçirilmiştir.

Model seçimi, Protokolün içeriğini ya da yönettiği süreçlerin davranışını etkilemek zorunda değildir. Örneğin komut/yanıt modelinde "komut" sözcüğünün kullanımı, uzak sürecin zorla eyleme geçirilebileceğini ima etmez. Hangi model benimsenirse benimsensin, bir süreç yerine getiremeyeceği ya da yerine getirmek istemediği gelen bir uzak isteği reddetme konusunda tam bir özgürlüğe sahiptir.

Bununla birlikte, Protokol üzerinde özlü bir etkisi olmasa da, bir modelin — komut/yanıt, istek/yanıt vb. — seçilmesi önemli bir görevdir; çünkü hem uygulama hem de sistem programcılarının ağ ortamını nasıl algıladığını belirler. Ağ ortamı uygulama programcısına yabancı görünecek biçimde sunulursa, uygulama programcısı onu kullanmaktan cayabilir. Model seçimi ayrıca sistem programcısının aklına gelmesi muhtemel protokol uzantılarının türünü ve kapsamını da sınırlar; bir model zengin ve yararlı uzantılar kümesini çağrıştırabilirken, bir diğeri hiçbir yere götürmeyebilir (ya da daha kötüsü, yanlış yöne götürebilir).

Makalenin bu son bölümünde yazar, uygulama programcısının uzak kaynakları kullanmasını teşvik edeceğine ve sistem programcısına çok çeşitli yararlı Protokol uzantıları önereceğine inandığı bir ağ modeli (bundan sonra Model olarak adlandırılacaktır) önermektedir. Ancak Protokolün içeriğinden farklı olarak, Model ARPANET topluluğu içinde şimdiden oldukça tartışmalı olduğunu kanıtlamıştır.

Kaynakların Yordam Kümeleri Olarak Modellenmesi

İdeal olarak, hem Protokolün hem de ona eşlik eden RTE’nin amacı, uzak kaynakları yerel olanlar kadar kolay kullanılabilir hale getirmektir. Yerel kaynaklar genellikle yerleşik ve/veya kütüphane alt yordamları biçimini aldığından, uzak komutların "yordamlar" olarak modellenmesi olasılığı hemen kendini gösterir. Model, yerel yordamlar ile Protokolün erişim sağladığı uzak komutlar arasında var olan benzerlik tarafından da doğrulanır. Her ikisi de istekte bulunan program (çağıran) adına keyfi derecede karmaşık, adlandırılmış işlemler gerçekleştirir; çağıran tarafından sağlanan argümanlarla yönetilir; ve işlemin sonucunu yansıtan çıktıları ona geri döndürür. Yordam çağrısı modeli, ağ ortamında programların zaman zaman kendi makineleri dışındaki makinelerde bulunan alt yordamları çağırmak zorunda olduklarını kabul eder.

Daha önce açıklanan istek/yanıt modeli gibi, yordam çağrısı modeli de Protokolde yalnızca biçimsel değişiklikler gerektirir:

message-type=CALL    [tid] procedure-name arguments
message-type=RETURN   tid  outcome        results

Bu üçüncü formülasyonda, "CALL", "RETURN" ve "procedure-name" terimleri sırasıyla "COMMAND", "RESPONSE" ve "command-name" yerine geçirilmiştir. Ve bu biçimde Protokol, yerinde bir adlandırmayla yordam çağrısı protokolü (PCP) olarak anılabilir.

"Yordam çağrısı modeli, uygulama protokollerini oluşturma görevini yordamların ve onların çağrı dizilerinin tanımlanması düzeyine yükseltecektir. Ayrıca, RTE aracılığıyla yerel programlama ortamını zarif bir biçimde genişleterek diğer makinelerdeki modülleri de kapsayan, uygulama programcısının çalışmasını teşvik eden ve kolaylaştıran gerçek bir dağıtık programlama sistemi (DPS) için bir temel sağlayacaktır."

Yerel ve ağ programlama ortamlarının bu bütünleşmesi, uzak yordamları adreslemek için normal yordam çağırma yapılarının küçük varyantlarını sağlayacak şekilde derleyicilerin değiştirilmesine kadar bile götürülebilir (bu durumda uygun RTE ilkel çağrıları otomatik olarak eklenir).

Son olarak Model, dağıtık programlama ortamını daha da geliştirmek için (örneğin eş-yordam bağlantıları ve sinyaller gibi) çeşitli yollarla doğal olarak genişletilebilen bir modeldir.

Yordam Çağrısı Modelinin Netleştirilmesi

Birçok bakımdan bu makalenin ele aldığı ağ etkileşimleri sınıfını doğru biçimde betimlese de, yukarıda önerilen Model başka açılardan uygulama programcısını yanıltma eğiliminde olabilir. Bu nedenle Modelin netleştirilmesi gerekir:

(1) Yerel yordam çağrıları ucuzdur; uzak yordam çağrıları değildir.

Yerel yordam çağrıları çoğu zaman tek bir makine komutu aracılığıyla gerçekleştirilir ve bu nedenle görece ucuzdur. Buna karşılık uzak yordam çağrıları, yerel RTE tarafından sağlanan bir ilkel aracılığıyla gerçekleştirilir ve IPC üzerinden mesaj alışverişi gerektirir.

Bu maliyet farkı nedeniyle, uygulama programcısı, RTE tarafından kullanım mekanikleri büyük ölçüde basitleştirilmiş olsa bile, uzak kaynakları kullanırken takdir yetkisini kullanmak zorundadır. Sanal bellek gibi, yordam çağrısı modeli de makul bir kötüye kullanım farkındalığı karşılığında büyük bir kolaylık ve dolayısıyla güç sunar.

(2) Geleneksel programlar genellikle tek bir denetim odağına sahiptir; dağıtık programların böyle bir zorunluluğu yoktur.

Geleneksel programlar genellikle tam olarak tek bir denetim odağına sahip tek bir süreç olarak gerçekleştirilir. Dolayısıyla bir yordam çağrısı, geleneksel olarak, denetimin çağırandan çağrılana aktarılmasını ima eder. Buna karşılık dağıtık sistemler, her biri bağımsız yürütme yeteneğine sahip iki ya da daha fazla süreç olarak gerçekleştirilir. Bu yeni ortamda, uzak bir yordam çağrısı, çağıranı askıya almak zorunda değildir; çağıran, çağrılan yordam ile paralel olarak yürütmeye devam edebilir.

Bu nedenle RTE’nin, kolaylık sağlamak amacıyla, uzak yordam çağrısı için iki kip sunması beklenebilir:

Çoğu geleneksel işletim sistemi, G/Ç işlemleri için zaten böyle bir kip seçimi sağlar. Engelleyici olmayan çağrılar için RTE, elbette, çağrı tamamlandığında programı eşzamansız olarak bilgilendirmeyi düzenlemeli ya da uygulama programının bu durumu periyodik olarak sınayabileceği ek bir ilkel sağlamalıdır.

Son olarak, uygulama programcısı, ağ iletişiminin yararlı tüm biçimlerinin yordam çağrıları olarak etkili bir şekilde modellenemeyeceğini kabul etmelidir. Bu nedenle, yordam çağrısı modelinin uygun olmadığı ve RTE tarafından sağlanan ilkellerin yeterli olmayacağı uygulamalarda, doğrudan erişilebilir durumda kalan daha alt düzey IPC olanağı kullanılmalıdır.

Bazı Beklentiler

Hem Yordam Çağrısı Protokolü hem de onunla ilişkili Çalışma-Zamanı Ortamı, ağ programcısının çalışmasını kolaylaştırma konusunda büyük bir potansiyele sahiptir; bu potansiyelin yalnızca küçük bir yüzdesi bu makalede tartışılmıştır. PCP tarafından sağlanan temel üzerine, dağıtık programlama ortamını daha da geliştiren ve daha güçlü yetenekler sunan, daha yüksek düzeyli ve uygulamadan bağımsız protokol katmanları inşa edilebilir (bkz. Ek D).

RTE’nin önemi tam olarak ortaya çıktıkça, muhtemelen aşağıdakiler de dahil olmak üzere ek görevler yavaş yavaş ona verilecektir:

  1. Parametreleri, uygulama programı tarafından dahili olarak kullanılan biçim ile Protokolün dayattığı biçim arasında dönüştürmek.
  2. İki makinenin sözcük uzunluklarına dayanarak en uygun süreçler arası iletim biçimini otomatik olarak seçmek.
  3. Her iki süreç de aynı makinede bulunduğunda, ağ IPC’si yerine daha verimli bir iletişim biçimini otomatik olarak ikame etmek.

RTE, sonunda programcıya çok çeşitli uygulamadan bağımsız ağ programlama kolaylıkları sunacak ve böylece Protokol aracılığıyla giderek daha güçlü bir dağıtık sistem oluşturma aracı haline gelecektir.

Teşekkürler

Bu makalede tanımlanan Protokol ve Modelin geliştirilmesine hem SRI'nın Augmentation Research Center (ARC) bünyesindeki hem de daha geniş ARPANET topluluğundaki birçok kişi zamanlarını ve fikirlerini katkı olarak sunmuştur. Aşağıdaki kişilerin katkıları özellikle belirtilerek teşekkür edilmektedir: ARC'den Dick Watson, Jon Postel, Charles Irby, Ken Victor, Dave Maynard ve Larry Garlick; ayrıca Bolt, Beranek and Newman, Inc.'den Bob Thomas ve Rick Schantz.

ARC, birkaç yıldır ağ tabanlı dağıtık sistemler için üst düzey bir çerçeve üzerinde çalışmaktadır [14]. Burada açıklanan özel Protokol ve Model, ARC tarafından Temmuz 1974'te başlatılan araştırmaların bir sonucudur. Bu araştırma; Modelin geliştirilmesini; onu desteklemek için gereken Protokolün tasarlanmasını ve belgelenmesini [15]; ve belirli bir makine için bir prototip çalışma zamanı ortamının tasarlanmasını, belgelenmesini ve uygulanmasını [16, 17] kapsamaktadır. Söz konusu makine, Bolt, Beranek and Newman, Inc. tarafından geliştirilen Tenex işletim sistemini çalıştıran bir PDP-10'dur [18]. On iki aylık bir dönem boyunca üç tasarım yinelemesi gerçekleştirilmiş ve ortaya çıkan tanım Tenex için uygulanmıştır. Tenex RTE, bu makalenin ana metninde ve Ekler A ile C'de sunulan yeteneklerin yanı sıra Ek D'de ima edilen yetenekleri de içeren bir üst küme sağlar.

Burada raporlanan çalışma, Savunma Bakanlığı'na bağlı Advanced Research Projects Agency ve Hava Kuvvetleri'nin Rome Air Development Center birimi tarafından desteklenmiştir.

Ek A: Önerilen Veri Türleri

Protokol, her parametrenin veya "veri nesnesinin" Model tarafından tanımlanan birkaç ilkel veri türünden biriyle temsil edilmesini gerektirir. Aşağıdaki veri türleri kümesi, geniş bir veri nesnesi sınıfını uygun biçimde modellemek için yeterlidir; ancak ek veri türlerine (örneğin, kayan noktalı sayılar) duyulan gereksinim kaçınılmaz olarak ortaya çıkacağından, kümenin açık uçlu kalması gerekir. Aşağıdaki açıklamalar boyunca N, [0, 2**15 − 1] aralığıyla sınırlıdır:

Ek B: Önerilen İletim Biçimleri

Parametreler, Protokol aracılığıyla bir süreçten diğerine gönderilmeden önce standart bir iletim biçiminde kodlanmalıdır. Etkili bir strateji, birkaç biçim tanımlamak ve çalışma zamanında en uygun olanı seçmek, ayrıca Protokole biçim uzlaşması için bir mekanizma eklemektir. Biçim uzlaşması RTE'nin bir başka sorumluluğu olur ve böylece uygulama programları için tamamen görünmez kılınabilir.

Aşağıda iki iletim biçimi önerilmektedir. İlki, 36 bitlik makineler arasında kullanım için 36 bitlik ikili bir biçimdir; ikincisi ise farklı makineler arasında kullanım için 8 bitlik ikili, "evrensel" bir biçimdir. Veri nesneleri, RTE'nin gelen parametreleri otomatik olarak çözümleyip içselleştirmesini sağlamak amacıyla, bu hizmetin uygulama programlarına sunulması istenirse, her biçimde tam olarak türlendirilmiştir.

PCPB36, 36 Bitlik Makineler Arasında Kullanım İçin

PCPB8, Farklı Makineler Arasında Kullanım İçin

Veri Türü Kodlaması

Bayt 0 — Veri türü

Baytlar 1–n — Değer

Ek C: Prosedür Çağrı Protokolünün Ayrıntılı Bir Kodlaması

Önceki eklerde ayrıntıları verilen veri türleri ve iletim biçimleri, öncelikle uzak prosedürlerin argümanlarını ve sonuçlarını temsil etmeye hizmet etse de, bu parametrelerin iletildiği komutları ve yanıtları temsil etmek için de aynı derecede kolay ve etkili bir biçimde kullanılabilirler.

Bu yaklaşımı benimseyerek, iki Protokol mesajının her biri bir PCP veri nesnesi olarak modellenebilir; özellikle, ilk elemanı bir INDEX mesaj türü olan bir LIST şeklinde. Böylece Protokolün aşağıdaki özlü ifadesi ortaya çıkar:

LIST (CALL,   tid,        procedure, arguments)
      INDEX=1 INDEX/EMPTY CHARSTR    LIST

LIST (RETURN, tid,        outcome,   results)
      INDEX=2 INDEX       BOOLEAN    LIST

Başarısız bir prosedürün RESULTS değeri aşağıdaki şekilde temsil edilir:

LIST (error, diagnostic)
      INDEX  CHARSTR

Ek D: Model için Olası Bazı Genişletmelere Bir Bakış

Bu makalenin ana bölümünde ve önceki eklerde önerilen dağıtık sistem kurma stratejisinin sonucu, Şekil D-1'de gösterilmiştir. Her sürecin çekirdeğinde, işletim sistemi tarafından sağlanan ve uzak süreçler arasında keyfi ikili verilerin iletimini gerçekleştiren süreçler arası iletişim olanağı yer alır. Bu çekirdeğin etrafında, önce birkaç ilkel veri nesnesi türünün IPC için ikili olarak hangi biçimde kodlandığına ilişkin kurallar, ardından uzak bir prosedürün önceki çağrısını ya başlatan ya da onaylayan birkaç bileşik veri nesnesinin (yani mesajların) biçimleri bulunur. Bunun hemen üzerinde, dağıtık programlama ortamına keyfi sayıda geliştirme uygulanabilen açık uçlu bir protokol katmanı yer alır. Bu çeşitli protokol katmanlarını saran yapı ise, makineye ve muhtemelen programlama diline bağlı kurallara göre uygulama programlarına DPS hizmetlerini sunan, kurulum tarafından sağlanan çalışma zamanı ortamıdır.

Bu makalede önerilen Protokol, uzak prosedür çağrısının yalnızca en temel yönlerini tanır. Çağıranın çağrılacak prosedürü tanımlamasına, gerekli argümanları sağlamasına, prosedürün sonucunu belirlemesine ve sonuçlarını geri almasına izin verir. İkinci bir makalede [19], yazar bu basit prosedür çağrı modeline bazı genişletmeler önermekte ve standartlaştırılmasının dağıtık programlama ortamını geliştireceği diğer yaygın süreçler arası etkileşim biçimlerini tanımlamaya çalışmaktadır. Ele alınan konular arasında şunlar yer almaktadır:

  1. Çağıran ile çağrılan arasında coroutine bağları ve diğer iletişim biçimleri.
  2. İç içe prosedür çağrılarından kaynaklanan denetim akışı boyunca bildirimlerin ve isteklerin yukarı doğru yayılması.
  3. Başka bir program içindeki sistem genelinde geçerli veri nesnelerinin uzaktan okunması veya yazılması için standart mekanizmalar.
  4. İlişkili prosedür koleksiyonları için erişim denetimleri.
  5. Süreçlerin oluşturulması ve başlatılması için standart bir araç; yani uzak bir makineyle bağlantı kurulması, oturum açılması, çalıştırılacak programın tanımlanması vb. Bu olanak, keyfi derecede karmaşık süreç hiyerarşilerinin oluşturulmasına izin verir.
  6. Süreçlerin birbirleriyle tanıştırılması için bir mekanizma; yani süreç hiyerarşisi üzerine daha genel iletişim yollarının bindirilmesi.

Bu ve diğer tüm genişletmeler, Şekil D-1'deki açık uçlu protokol katmanında kendilerine yer bulabilir. [19]'da incelenen belirli genişletmeler, bir dogma olarak değil, olanakları işaret etmek ve daha ileri araştırmaları teşvik etmek amacıyla sunulmaktadır.

Kaynaklar

  1. Kahn, R. E., "Resource-Sharing Computer Communications Networks," Proceedings of the IEEE, Cilt 60, No. 11, ss. 1397–1407, Kasım 1972.
  2. Crocker, S. D., Heafner, J. F., Metcalfe, R. M., Postel, J. B., "Function-oriented Protocols for the ARPA Computer Network," AFIPS Proceedings, Spring Joint Computer Conference, Cilt 40, ss. 271–279, 1972.
  3. Carr, C. S., Crocker, S. D., Cerf, V. G., "Host-Host Communication Protocol in the ARPA Network," AFIPS Proceedings, Spring Joint Computer Conference, Cilt 36, ss. 589–597, 1970.
  4. McKenzie, A. A., Host/Host Protocol for the ARPA Network, Bolt Beranek and Newman Inc., Cambridge, Massachusetts, Ocak 1972 (SRI-ARC Katalog Öğesi 8246).
  5. Walden, D. C., "A System for Interprocess Communication in a Resource Sharing Computer Network," Communications of the ACM, Cilt 15, No. 4, ss. 221–230, Nisan 1972.
  6. Cerf, V. G., Kahn, R. E., "A Protocol for Packet Network Intercommunication," IEEE Transactions on Communications, Cilt COM-22, No. 5, ss. 637–648, Mayıs 1974.
  7. Thomas, R. H., "A Resource-Sharing Executive for the ARPANET," AFIPS Proceedings, National Computer Conference, Cilt 42, ss. 155–163, 1973.
  8. TELNET Protocol Specification, Stanford Research Institute, Menlo Park, California, Ağustos 1973 (SRI-ARC Katalog Öğesi 18639).
  9. Engelbart, D. C., Watson, R. W., Norton, J. C., "The Augmented Knowledge Workshop," AFIPS Proceedings, National Computer Conference, Cilt 42, ss. 9–21, 1973.
  10. Engelbart, D. C., English, W. K., "A Research Center for Augmenting Human Intellect," AFIPS Proceedings, Fall Joint Computer Conference, Cilt 33, ss. 395–410, 1968.
  11. Irby, C. H., Dornbush, C. F., Victor, K. E., Wallace, D. C., "A Command Meta Language for NLS," Final Report, Contract RADC-TR-75-304, SRI Project 1868, Stanford Research Institute, Menlo Park, California, Aralık 1975.
  12. Neigus, N. J., File Transfer Protocol, ARPA Network Working Group Request for Comments 542, Bolt Beranek and Newman Inc., Cambridge, Massachusetts, Temmuz 1973 (SRI-ARC Katalog Öğesi 17759).
  13. Bressler, R. D., Guida, R., McKenzie, A. A., Remote Job Entry Protocol, ARPA Network Working Group Request for Comments 360, Dynamic Modeling Group, Massachusetts Institute of Technology, Cambridge, Massachusetts (tarihsiz) (SRI-ARC Katalog Öğesi 12112).
  14. Watson, R. W., Some Thoughts on System Design to Facilitate Resource Sharing, ARPA Network Working Group Request for Comments 592, Augmentation Research Center, Stanford Research Institute, Menlo Park, California, 20 Kasım 1973 (SRI-ARC Katalog Öğesi 20391).
  15. White, J. E., DPS-10 Version 2.5 Implementer's Guide, Augmentation Research Center, Stanford Research Institute, Menlo Park, California, 15 Ağustos 1975 (SRI-ARC Katalog Öğesi 26282).
  16. White, J. E., DPS-10 Version 2.5 Programmer's Guide, Augmentation Research Center, Stanford Research Institute, Menlo Park, California, 13 Ağustos 1975 (SRI-ARC Katalog Öğesi 26271).
  17. White, J. E., DPS-10 Version 2.5 Source Code, Augmentation Research Center, Stanford Research Institute, Menlo Park, California, 13 Ağustos 1975 (SRI-ARC Katalog Öğesi 26267).
  18. Bobrow, D. G., Burchfiel, J. D., Murphy, D. L., Tomlinson, R. S., "TENEX, a Paged Time Sharing System for the PDP-10," Communications of the ACM, Cilt 15, No. 3, ss. 135–143, Mart 1972.
  19. White, J. E., "Elements of a Distributed Programming System," Journal of Computer Languages dergisine yayımlanmak üzere sunulmuştur, 1976.

Şekil Listesi

Ağ Tabanlı Kaynak Paylaşımı için Üst Düzey Bir Çerçeve

James E. White
Augmentation Research Center
Stanford Research Institute
Menlo Park, California 94025
(415) 326-6200 x2960

23-ARA-75

Bu makale, kaynak paylaşımı yapan bir bilgisayar ağı içindeki diğer bilgisayarlarda bulunan modülleri kapsayacak şekilde yerel programlama ortamını genişletecek, uygulamadan bağımsız, üst düzey bir protokol ve yazılım çerçevesi önermekte; böylece dağıtık sistemlerin kurulmasını kolaylaştırmayı ve kaynakların paylaşılmasını teşvik etmeyi amaçlamaktadır.

Burada raporlanan çalışma, Savunma Bakanlığı'na bağlı Advanced Research Projects Agency ve Hava Kuvvetleri'nin Rome Air Development Center birimi tarafından desteklenmiştir.

Bu makale, 1976 National Computer Conference Bildirileri'nde yayımlanmak üzere sunulmuştur.