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

Dağıtık Bir Programlama Sisteminin Öğeleri

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

Network Working Group James E. White
Request for Comments: 708 Augmentation Research Center

Dağıtık Bir Programlama Sisteminin Öğeleri

5 Ocak 1976

James E. White
Augmentation Research Center

Stanford Research Institute
Menlo Park, California 94025

(415) 326-6200 X2960

Bu makale, önceki bir çalışmada (27197) açıklanan basit Prosedür Çağrısı Protokolü’ne bazı genişletmeler önermektedir. Prosedür çağrısı modelinin genişletilmesi ve süreçler arası etkileşimin diğer yaygın biçimlerinin standartlaştırılması yoluyla, bu tür genişletmeler uygulama programcısına daha da güçlü bir dağıtık programlama sistemi sağlayacaktır.

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

Bu makale Journal of Computer Languages dergisinde yayımlanmak üzere sunulacaktır.

Network Working Group James E. White
Request for Comments: 708 Dağıtık Bir Programlama Sisteminin Öğeleri

GİRİŞ

Eşlik eden bir makalede [1], yazar, kaynak paylaşımına dayalı bir bilgisayar ağı içinde dağıtık sistemlerin kurulmasını kolaylaştıracak basit bir protokol ve yazılım çerçevesi önermektedir; bu çerçeve, uzak süreçlerin prosedür çağrısı düzeyinde birbirleriyle iletişim kurmasını mümkün kılar. Mevcut haliyle bile büyük yarar sağlamakla birlikte, bu ilkel dağıtık programlama sistemi (DPS) yalnızca uzak prosedür çağrısının en temel yönlerini desteklemektedir. Özellikle, çağıranın çağrılacak uzak 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. Bu makale, bu basit prosedür çağrısı modelini genişletmekte ve süreç etkileşiminin diğer yaygın biçimlerini standartlaştırarak daha güçlü ve kapsamlı bir dağıtık programlama sistemi sağlamayı amaçlamaktadır. Bu makalede önerilen özel genişletmelerin, DPS kavramının potansiyelini ortaya koyması umulmakta olup, dogma olarak değil, daha ileri araştırmalar için birer uyarıcı olarak sunulmaktadır.

Bu makalenin ilk bölümü, [1]’de türetilen temel dağıtık programlama sistemini özetlemektedir. İkinci bölüm, onu genişletirken izlenecek genel stratejiyi açıklamaktadır. Üçüncü ve en uzun bölüm ise, standartlaştırılmayı gerektirecek kadar yaygın olan bazı süreç etkileşimi yönlerini tanımlamakta ve bunların DPS modeline nasıl dahil edilebileceğine ilişkin yöntemler önermektedir.

TEMEL SİSTEMİN GÖZDEN GEÇİRİLMESİ

[1]’de türetilen dağıtık programlama sistemi, ağ genelinde bir süreçler arası iletişim (IPC) olanağının varlığını varsayar ve bunun üzerine kuruludur. Şekil 1’de gösterildiği gibi, DPS, bilgisayar süreçlerinin üst düzey bir modelinden ve bir IPC iletişim kanalı aracılığıyla birbirine bağlanan iki süreç arasındaki diyaloğu düzenleyerek bu modeli gerçekleştiren, uygulamadan bağımsız basit bir *prosedür çağrısı protokolü (PCP)*nden oluşur. DPS, kurulum tarafından sağlanan bir çalışma zamanı ortamı (RTE) tarafından gerçekleştirilir ve bu ortam her uygulama programı ile bağlama zamanında yüklenir (ya da başka bir yolla kullanılabilir hale getirilir).

Model

Prosedür çağrısı modeli (bundan sonra Model olarak adlandırılacaktır), bir süreci uzaktan çağrılabilen alt yordamlar ya da prosedürler koleksiyonu olarak ele alır. Her prosedür adıyla çağrılır, kendisine bir argüman listesi verilebilir ve çağırana hem başarılı ya da başarısız olduğunu belirten bir boole sonucu hem de bir sonuç listesi döndürür. Model, IPC kanalının her iki ucundaki sürecin de komşusundaki süreçteki prosedürleri çağırmasına izin verir ve ayrıca bir sürecin eşzamanlı yürütme için iki ya da daha fazla prosedür çağrısını kabul etmesini mümkün kılar.

Prosedürlerin argümanları ve sonuçları, aşağıda listelenen küçük bir ilkel veri türleri kümesinden modellenir:

Protokol

Modeli gerçekleştiren prosedür çağrısı protokolü (bundan sonra Protokol olarak adlandırılacaktır), yukarıda listelenen yedi veri türünün her biri için (Ek A’da önerilenler gibi) bir iletim biçimi tanımlar ve parametrelerin süreçler arasında taşındıklarında bu biçimde kodlanmasını zorunlu kılar.

Protokol ayrıca, uzak prosedürlerin çağrıldığı süreçler arası iletileri de belirtir. Bu iletiler simgesel olarak aşağıdaki gibi tanımlanabilir:

Birinci ileti, belirtilen AD’a sahip prosedürü verilen ARGÜMANLAR ile çağırır. İkincisi, birincisine nihai yanıt olarak döndürülür ve tamamlanan prosedürün SONUCUNU ve SONUÇLARINI bildirir. SONUÇ, bir prosedürün başarısız olduğunu gösterdiğinde, prosedürün SONUÇLARININ bir hata numarası ve tanılama iletisi olması zorunludur; ilki çağıran programın bundan sonra ne yapacağını belirlemesine yardımcı olurken, ikincisi olası kullanıcı sunumu içindir. CALL iletisinde isteğe bağlı bir işlem tanımlayıcısı (TID) bulunması, çağıranın tanımlayıcıyı yankılayan bir RETURN iletisiyle onay istemesi anlamına gelir.

Veri türleri ve bunların iletim biçimleri öncelikle uzak prosedürlerin argümanlarını ve sonuçlarını temsil etmek için kullanılsa da, bu parametrelerin iletildiği iletilerin kendilerini temsil etmek için de aynı derecede kolay ve etkili biçimde kullanılabilir. Bu nedenle Protokol, yukarıda açıklanan iki iletinin her birini bir PCP veri nesnesi olarak, yani ilk öğesi bir INDEX ileti türü olan bir LIST olarak temsil eder. Protokolün aşağıdaki özlü ifadesi elde edilir:

Burada ve sonraki protokol açıklamalarında, köşeli parantezler içinde yer alan öğeler isteğe bağlıdır (yani EMPTY olabilir). Başarısız bir prosedürün SONUÇLARI aşağıdaki gibi temsil edilir:

Çalışma Zamanı Ortamı

Çalışma zamanı ortamı (bundan sonra ortam olarak adlandırılacaktır), bir IPC kanalı aracılığıyla uygulama programını uzak bir sürece bağlar. Bunu yaparken, uygulama programının bağlandığı uzak süreci yönetmek için kullanabileceği, alt yordamlar ya da sistem çağrıları olarak gerçekleştirilen bir ilkel işlemler koleksiyonu sağlar. Ortam, bu ilkel işlemleri kanal üzerinden çeşitli protokol iletileri gönderip alarak gerçekleştirir.

Mevcut ilkel biçiminde Protokol, ortamın aşağıdakine benzer tek bir uzak prosedür çağrısı ilkelini uygulama programına sunmasını mümkün kılar:

Bu ilkel, belirtilen uzak PROSEDÜRÜ verilen ARGÜMANLAR ile çağırır ve onun SONUCUNU ve SONUÇLARINI döndürür. Bu ilkel, çağıran uygulama programını uzak prosedür dönene kadar engellerken, çağrıyı yalnızca başlatan ve uygulama programının sonucu ve sonuçları ikinci bir işlemle toplamasına izin veren bir varyant da sağlanabilir.

Ortam ile uygulama programı arasındaki arayüz makineye ve hatta olası olarak dile bağımlı olduğundan, ortam tarafından sağlanan ilkel işlemler bu makalede yalnızca simgesel olarak tanımlanabilir. PCP veri türleri, argümanlarını ve sonuçlarını tanımlamak için uygun bir araç sağladığından, yukarıda ve makalenin tamamında bu amaçla kullanılmıştır; ancak bu tür parametreler normalde ortam ile uygulama programı arasında bazı dahili biçimlerde aktarılacaktır.

YENİ PROTOKOL İŞLEVLERİNİN BAŞLATILMASI

Protokol halihazırda keyfi uzak prosedürleri çağırmak için bir mekanizma sağladığından, bu makalede önerilecek Model genişletmeleri mümkün olan her durumda ek iletiler yerine prosedürler olarak uygulanacaktır. Uygulama prosedürlerinden farklı olarak, bu özel sistem prosedürleri uygulama programları tarafından değil, çalışma zamanı ortamları tarafından çağrılacak ve gerçekleştirilecektir. Normal ortam tarafından sağlanan uzak prosedür çağrısı ilkelini kullanarak uzak uygulama programı tarafından erişilemez olmakla birlikte, sistem prosedürleri ortamın uygulama programına yeni ilkel işlemler uygulayıp sunmasını sağlayacaktır.

Bu yeni ilkel işlemlerin birçoğunun çağrı dizileri, onları gerçekleştiren uzak sistem prosedürlerinin çağrı dizilerine yakından karşılık gelecektir. Diğer ilkel işlemler ise daha karmaşık olacak ve uygulanmaları için, olası olarak farklı süreçlerde, birden fazla sistem prosedürünün çağrılmasını gerektirecektir. Yazar, bu makale boyunca, önerilen çeşitli Model genişletmeleri tarafından gerekli kılınan Protokol eklemelerini açıklamanın yanı sıra, uygulama programının kullanımına sunulan yeni ilkel işlemler için çağrı dizileri de önerecektir.

MODELE OLASI BAZI GENİŞLETMELER

1. Uzak Süreçlerin Oluşturulması

Bir makinedeki bir program başka bir makinedeki kaynakları kullanabilmeden önce, ya uzak makinede yeni bir süreç oluşturmalı ya da mevcut bir sürece erişim sağlamalıdır. Her iki durumda da yerel süreç, uzak sistem içindeki yerleşik bir yönlendirme sürecine bir IPC kanalı kurmalı, başlatılacak ya da bağlantı kurulacak programı belirtmeli ve programa erişiminin sağlanabilmesi ve ücretlendirmenin yapılabilmesi için kendisini tanımlamalıdır. Bu ön adımlar tamamlandıktan sonra, istenen süreç IPC kanalı üzerindeki sorumluluğu üstlenir ve esas iletişim başlar.

Ortamın yukarıdaki senaryoyu nasıl gerçekleştireceği büyük ölçüde, dağıtık sistemin dayandığı IPC olanağı tarafından belirlenir. Eğer IPC olanağının kendisi tüm görevi gerçekleştiren tek bir ilkel sağlıyorsa, ortamın yalnızca bu ilkel işlemi çağırması yeterlidir. Öte yandan, ARPA bilgisayar Ağı (ARPANET) içinde olduğu gibi, yalnızca ortamın uzak yönlendiriciye bir kanal kurmasını sağlayan bir mekanizma sunuyorsa, bu durumda Protokol’ün çalıştırılacak programı adlandırmaya ve gerekli kimlik bilgilerini sunmaya yönelik hükümler içermesi gerekir.

Protokole aşağıdaki sistem prosedürünün eklenmesi, bu ikinci durumda yerel ortamın uzak yönlendiriciye gerekli bilgileri sağlamasını mümkün kılar:

Argümanları, çalıştırılacak uygulama PROGRAMının adını ve kullanım bedeli yansıtılacak yerel kullanıcıya ait USER adı, PASSWORD ve ACCOUNT bilgilerini içerir.

Bu yeni prosedür, Modele etkin biçimde oluşturma kavramını ekler ve ortamın uygulama programına aşağıdaki ilkel işlemleri sunmasını mümkün kılar:

Birinci ilkel, belirtilen COMPUTER içindeki yönlendiriciye önce bir kanal kurarak ve ardından uzak sistem prosedürü INIPROCESS’i belirtilen PROGRAM adı ve KİMLİK BİLGİLERİ argümanlarıyla çağırarak yeni bir süreç oluşturur ya da mevcut bir süreçle bağlantı kurar. İlkel, uygulama programının yerel ortamla sonraki iletişimlerinde yeni oluşturulan sürece başvurabilmesi için bir süreç tutamacı (PH) döndürür. Bu tutamak, kanalın kendisi, ortam içindeki bir tablonun indeksi ya da ortamı uygulayan kişinin uygun bulduğu başka herhangi bir biçimde gerçekleştirilebilir.

İkinci ilkel, belirtilen PH tutamacına sahip önceden oluşturulmuş süreci, uzak sürece olan IPC kanalını silerek ve sürece tahsis edilmiş olabilecek tüm dahili tablo alanlarını geri alarak siler.

2. Süreçlerin Birbirleriyle Tanıştırılması

En basit dağıtık sistemler, yukarıda açıklanan CRTPROCESS ilkelini kullanarak gereksinim duyduğu kaynaklara sahip bir veya daha fazla alt süreci oluşturan tek bir süreçle başlar. Bu alt süreçlerin bir kısmı ya da tamamı, kendi uzak kaynaklarına gereksinim duyabilir ve bu nedenle kendilerine ait alt süreçler oluşturabilir. Bu üretken etkinlik, ilke olarak keyfi bir derinliğe kadar ilerleyebilir. Dağıtık sistem böylece, düğümleri süreçler ve dalları IPC kanalları olan bir ağaç yapısıdır.

Bir dağıtık sistem keyfi derecede çok sayıda süreç içerebilse de, her süreç yalnızca kendisini oluşturan süreci ve kendisinin oluşturduklarını, yani ebeveynini ve çocuklarını bilir. Dolayısıyla bir sürecin ağacın kaynaklarına erişebildiği yarıçap yapay olarak küçüktür. Birçok dağıtık sistemin elverişli biçimde gerçekleştirilmesini engelleyen bu sınırlı paylaşım aralığı, Modele, süreç ağacının üzerine keyfi derecede karmaşık bir iletişim yolları ağı bindirilmesine izin verecek şekilde genişletilerek aşılabilir.

Protokol’ün bu tür iletişim yollarını sağlamasının birçok yolundan biri, bir sürecin bildiği herhangi iki süreci (örneğin iki çocuğunu ya da ebeveyni ile çocuğunu) birbirleriyle tanıştırmasına ve böylece birbirlerinden haberdar etmesine izin vermektir. Tanıştırıldıktan sonra, bu iki süreç, tanıştırmayı yapan sürecin sahip olduğu özgürlükle birbirlerinin prosedürlerini çağırabilirler. Ayrıca birbirlerini başka süreçlerle de tanıştırabilirler ve böylece daha uzun iletişim yolları oluşturabilirler.

Network Working Group — James E. White
Request for Comments: 708 — Dağıtık Bir Programlama Sisteminin Öğeleri
Modele Olası Bazı Genişletmeler
Süreçlerin Birbirleriyle Tanıştırılması

2.1 Homojen Bir Ortam İçinde Tanıştırmalar

Bir homojen ortam içinde kalındığı sürece (yani tek bir IPC tesisinin alanı içinde), iki sürecin tanıtılması, aralarında bir IPC kanalının oluşturulmasından biraz daha fazlasını gerektirir. Protokole, IPC portlarını yöneten aşağıdaki sistem yordamlarının eklenmesi, tanıtmayı gerçekleştiren sürecin çalışma zamanı ortamının böyle bir kanalı müzakere edebilmesini sağlar:

Bu yordamlar için ayrıntılı çağrı dizileri, dağıtık sistemin temelini oluşturan IPC tesisine göre belirlenir. Bu nedenle yukarıdakiler, herhangi bir belirli ağda gerekebileceklerin yalnızca temsili örnekleridir; ancak örneğin ARPANET içinde gerekenden yalnızca biraz daha az karmaşıktırlar.

Kanalı oluşturmak için, tanıtmayı yapan sürecin çalışma zamanı ortamı, ALOPORT aracılığıyla her bir hedef süreçte bir PORT ayırır ve ardından her bir sürece CNNPORT yoluyla, IPC tesisi üzerinden portunu diğerininkiyle bağlaması talimatını verir. ALOPORT tarafından döndürülen süreç tanıtıcısı PH, hem başlangıçta ayrılan port için bir tanıtıcı olarak hem de daha sonra ekli kanalın erişim sağladığı süreç için bir tanıtıcı olarak hizmet eder. İki süreci ayırmak için, tanıtmayı yapan sürecin ortamının yalnızca her bir süreçte DCNPORT yordamını çağırması yeterlidir; böylece kanal çözülür, ilişkili portlar serbest bırakılır ve süreç tanıtıcılarının tahsisi kaldırılır.

Bu üç yeni sistem yordamı ile donatılan ortam, uygulama programlarına aşağıdaki yeni ilkel işlemleri sunabilir:

Network Working Group — James E. White
Request for Comments: 708 — Dağıtık Bir Programlama Sisteminin Öğeleri
Modele Bazı Olası Uzantılar
Süreçlerin Birbirine Tanıtılması

İlk ilkel işlem, tanıtıcıları PH1 ve PH2 olarak belirtilen iki süreci birbirine tanıtır. Her bir tanıtıcı, bir oğul süreci gösterebilir; bu durumda tanıtıcı CRTPROCESS tarafından döndürülen bir tanıtıcıdır; ebeveyn süreci gösterebilir; bu durumda her zaman tanımlı olması gereken özel bir tanıtıcı (örneğin 1) kullanılır; ya da daha önce tanıtılmış bir süreci gösterebilir; bu durumda tanıtıcı, ITDPROCESS’in önceki bir çağrısında elde edilmiş olandır.

ITDPROCESS, iki sürecin birbirini tanıyacağı PH12 ve PH21 tanıtıcılarını ve ayrıca uygulama programının daha sonra SEPPROCESS aracılığıyla iki süreci ayırmak için kullanabileceği bir tanıtma tanıtıcısı IH döndürür. Tanıtmayı başlatan uygulama programı, tanıtılan her bir uygulama programına, diğeri için olan tanıtıcısını iletme sorumluluğunu üstlenir.

2.2 Heterojen Bir Ortam İçinde Tanıtımlar

Bir IPC kanalı aracılığıyla birbirine bağlanmaları iki süreci birbirine tanıtmak için yeterli olsa da, heterojen bir ortamda böyle bir kanalın oluşturulması olanaksızdır. Şekil 2’de gösterildiği gibi, P1 ve P2 süreçlerinin (sırasıyla C1 ve C2 bilgisayarlarında) bir ağ IPC tesisi aracılığıyla dağıtık bir sistem içinde birbirine bağlandığını varsayalım. Ayrıca, P2’nin, C2’ye bağlı olmakla birlikte resmen ağın bir parçası olmayan bir minibilgisayarda M başka bir süreç P3’ü sisteme eklediğini varsayalım. Bu yapılandırmada, P2’nin P1 ve P3 süreçlerini, aralarında basitçe bir IPC kanalı kurarak birbirine tanıtması olanaksızdır; çünkü tek bir IPC tesisinin alanı içinde değildirler.

Bu sorunu aşmanın bir yolu, Modeli, iki ya da daha fazla fiziksel (yani IPC) kanaldan oluşan bileşik ya da mantıksal kanal kavramını kapsayacak şekilde genişletmektir. P1 süreci tarafından mantıksal kanal üzerinden Pn’ye (n = yukarıdaki örnekte 3) gönderilen bir mesaj, ara süreçler P2’den Pn−1’e kadar olanların ortamları tarafından ardışık fiziksel kanallar üzerinden iletilir. Her mesajın en az iki fiziksel kanaldan geçmesi ve yol boyunca tüm ortamlar tarafından ele alınması gerektiğinden fiziksel kanallara göre daha maliyetli olsa da, mantıksal kanallar, aksi halde bunu yapamayacak süreçlerin birbirlerinin kaynaklarına erişebilmesini sağlar. Mesajların iletilmesi ortamın bir sorumluluğu olduğundan, uygulama programının bundan haberdar olması gerekmez.

Network Working Group — James E. White
Request for Comments: 708 — Dağıtık Bir Programlama Sisteminin Öğeleri
Modele Bazı Olası Uzantılar
Süreçlerin Birbirine Tanıtılması

Şekil 3’te gösterildiği gibi, bir mantıksal kanal, P1’den Pn’ye kadar her bir sürecin ortamı tarafından tutulan tablo girdilerinden ve bir yönlendirme kodu ile gelen mesajları yerel tablo girdisine göre iletmek üzere ortamdan oluşur. Her tablo girdisi, bitişik iki süreç için süreç tanıtıcılarını ve ayrıca her biri tarafından tanınan yönlendirme kodunu içerir.

Uzak komşusuna bir mesaj iletmek için, kaynak süreç (örneğin P1), mesajı IPC kanalı üzerinden P2’ye, P2 içindeki uygun tablo girdisini adresleyen bir yönlendirme kodu ile gönderir. Mesajı alan P2, yönlendirme kodu aracılığıyla tablo girdisini bulur, mesajı P3 tarafından tanınan yönlendirme kodu ile günceller ve mesajı P3’e iletir. Sonunda mesaj, nihai varış noktası olan Pn’ye ulaşır.

Protokole aşağıdaki sistem yordamlarının eklenmesi, ortamın yukarıda tanımlanana benzer bir mantıksal kanal kurabilmesini sağlar:

En basit mantıksal kanal (n = 3), P2 tarafından oluşturulur; P2, hem P1 hem de P3 içinde CRTROUTE’u çağırır, her bir durumda mantıksal kanalın kendi bölümüne atadığı yönlendirme kodu MYCODE’u belirtir ve karşılığında iki sürecin atadığı yönlendirme kodlarını ve süreç tanıtıcılarını PH olarak alır. Bu basit durumda OLDCODE gerekmez ve bu nedenle EMPTY’dir.

Daha karmaşık mantıksal kanallar (n > 3), tanıtılacak süreçlerden birinin ya da her ikisinin, tanıtmayı yapan sürece bir mantıksal kanal ile zaten bağlı olduğu durumlarda gereklidir. Bu gibi durumlarda, oluşturulacak yeni kanalın bir bölümü mevcut kanalı çoğaltmalıdır; dolayısıyla, hedef süreç içindeki o kanalı temsil eden tablo girdisine ait yönlendirme kodu OLDCODE, sistem yordamının ek bir argümanı olarak belirtilir. Hedef süreç, model kanalının geri kalanını çoğaltmak için bitişik süreçte CRTROUTE’u özyinelemeli olarak çağırmalıdır.

Network Working Group — James E. White
Request for Comments: 708 — Dağıtık Bir Programlama Sisteminin Öğeleri
Modele Bazı Olası Uzantılar
Süreçlerin Birbirine Tanıtılması

Bir mantıksal kanal oluşturan Pi süreci, onun sonunda sökülmesini güvence altına alma sorumluluğunu üstlenir. Mantıksal kanalı, Pi−1 ve Pi+1 içinde DELROUTE’u çağırarak siler; bu çağrıların her biri, çağrıyı kanalın kendi ucuna doğru yayar.

3. Yerel Kaynaklara Erişimin Denetlenmesi

Yukarıda önerilen süreç tanıtma ilkel işlemi, fiilen bir sürece erişimin bir süreçten diğerine aktarılmasına izin verir. Zaten bir P1 süreci için bir tanıtıcıya sahip olan herhangi bir P2 süreci, üçüncü bir süreç P3 tarafından kullanılmak üzere bir tanıtıcı elde edebilir. P1 ve P3 tanıtıldıktan sonra, P3, P1 içindeki yordamları serbestçe çağırabilir (ve tersi de geçerlidir).

Bir süreç, ALOPORT sistem yordamını iptal ederek başka bir sürece tanıtılmasını önleyebilse ve böylece kendisine erişim kazanan süreçler kümesini sınırlayabilse de, bazen daha ince erişim denetimleri gerekebilir. Örneğin bir süreç, iki ayrı kaynağı barındırabilir; bunlardan biri yalnızca ebeveynine (örneğin) sunulacakken, diğeri ebeveynin tanıttığı herhangi bir sürece açık olabilir. Böyle bir strateji rahatça uygulanabilmeden önce, Modelin, tek bir süreç içindeki bireysel kaynaklara erişim denetimlerinin bağımsız olarak uygulanmasına izin verecek şekilde genişletilmesi gerekir.

Tek bir yordam bir kaynak olarak düşünülebilse de, bir dizi ilişkili yordamdan oluşan daha büyük, bileşik kaynakları tasavvur etmek daha pratik ve elverişlidir. Veri nesneleri oluşturma, silme, değer atama, okuma ve arama için yordamlar içeren basit bir veritabanı yönetim modülü, bu tür bileşik kaynaklara örnektir. Her bir yordam tek başına yararsız olsa da, tüm yordam ailesi anlamlı bir hizmet sağlar. Bu tür mantıksal olarak ilişkili yordam paketleri, tanımlanacak daha ince erişim denetimlerinin en makul nesnesi olabilir.

Erişim denetimleri, bir sürecin, içerdiği yordamların herhangi birini çağırmadan önce uzak bir paketi açmasını ve onun için bir tanıtıcı elde etmesini zorunlu kılarak paketlere uygulanabilir. Süreç paketi açmaya çalıştığında, bunu yapma hakkı doğrulanabilir ve gerekirse girişim iptal edilebilir. Açma girişimini sınamak, elbette, her yordam çağrısını sınamaktan daha az maliyetlidir. Bir paketin açılması, ayrıca pakete bağımlı durum bilgilerinin başlatılması için de uygun bir zaman sağlar.

Network Working Group — James E. White
Request for Comments: 708 — Dağıtık Bir Programlama Sisteminin Öğeleri
Modele Bazı Olası Uzantılar
Yerel Kaynaklara Erişimin Denetlenmesi

Protokole aşağıdaki sistem yordamı çiftinin eklenmesi, ortamın başka bir süreç içindeki paketleri açıp kapatabilmesini sağlar. Verimlilik için, bu yordamlar tek bir işlemde rastgele sayıda paketi yönetir.

İlk yordam, belirtilen PACKAGES için paket tanıtıcıları PKHS’yi açar ve döndürür; ikincisi ise bir ya da daha fazla paketi kapatır ve daha önce onlar için elde edilmiş PKHS tanıtıcılarını serbest bırakır.

Bu iki yeni sistem yordamını içermenin yanı sıra, Protokol ayrıca her CALL mesajında yordam adıyla birlikte bir paket tanıtıcısının bulunmasını zorunlu kılmalıdır (boş bir tanıtıcı belki bir sistem yordamını gösterebilir). Bu gereksinimin yan etkisinin, paketlerin, yordam adlarının benzersiz olması gereken alan haline gelmesi olduğuna dikkat ediniz.

Yukarıda tanımlanan sistem yordamları, ortamın, karşılık gelen sistem yordamlarının çağrı dizilerine benzer, ancak hedef sürecin süreç tanıtıcısını ek bir argüman olarak kabul eden ilkel işlemleri uygulama programlarına sunabilmesini sağlar. Bunların gerçekleştirilmesi, yalnızca ortamın iç tablolarından uzak süreci belirlemesini ve o süreçte OPNPACKAGE ya da CLSPACKAGE’ı çağırmasını gerektirir.

4. Küresel Değişkenlere Erişimin Standartlaştırılması

Geleneksel sistemler, sistem genelindeki modüller tarafından erişilebilen küresel değişkenler tutar. Bu tür değişkenler genellikle aşağıdaki biçimdeki ilkel işlemler kullanılarak yönetilir:

  1. V’nin geçerli değerini döndürmek.
  2. V’nin geçerli içeriğini yeni bir değerle değiştirmek.

Bu ilkel işlemler ya dil yapıları olarak sağlanır ya da özel yordamlar tarafından gerçekleştirilir. İlk yaklaşım, sistem içindeki tüm değişkenlerin tekdüze biçimde ele alınmasını teşvik eder.

Uzak erişilebilir değişkenler tutan dağıtık sistemler de, gerekli erişim ilkel işlemlerini uygulamak için bir strateji seçmek zorundadır. Bu tür ilkel işlemler elbette özel uygulama yordamları olarak gerçekleştirilebilse de, Protokole aşağıdaki yeni sistem yordamlarının eklenmesi, tekdüze bir çalışma zamanı erişim mekanizmasını güvence altına alır:

Bu yordamlar, değişkenleri PCP veri türlerinden modellenmiş adlandırılmış veri nesneleri olarak etkili biçimde tanımlar ve bunların ilişkili yordamlarla birlikte paketler halinde kümelenmesini önerir. Sistem yordamları, belirtilen ad ve paket tanıtıcısı PKH olan değişkenin değerini sırasıyla döndürür ve belirtir.

Bu yeni yordamlar, ortamın, karşılık gelen sistem yordamlarının çağrı dizilerine benzer, ancak hedef sürecin süreç tanıtıcısını ek bir argüman olarak kabul eden ilkel işlemleri uygulama programlarına sunmasını sağlar. Bu ilkel işlemler, uygun biçimde değiştirilmiş bir derleyicinin, geleneksel programlama ortamlarında değişkenlerin yönetimini karakterize eden derleme zamanı tekdüzeliğini yeniden tesis edebilmesi için bir temel sağlar. Bunların gerçekleştirilmesi, yalnızca yerel ortamın iç tablolarından uzak süreci belirlemesini ve o süreçte RDVARIABLE ya da WRVARIABLE’ı çağırmasını gerektirir.

Çoğu değişken, kendilerine atanabilecek veri türleri ve değerler aralığını sınırlandıracaktır; bazıları hatta salt okunur olabilir. Ancak PCP veri türleri kullanılarak modellendikleri için, değerleri ilke olarak keyfi derecede karmaşık olabilir (örneğin, LIST’lerin LIST’i) ve programcı bazen değişkenin yalnızca tek bir öğesini (ya da öğe kendisi bir LIST ise, onun yalnızca bir öğesini; ve bu şekilde keyfi derinliğe kadar) yönetmek isteyebilir.

Çağrı dizilerine aşağıdaki argümanın eklenmesi, yukarıda önerilen sistem yordamlarını, bir değişkenin bileşik değerinin tek bir öğesini isteğe bağlı olarak yönetebilecek şekilde genişletir:

substructure
(INDEX’lerin LISTESİ)

Değerin ağaç yapısının ardışık düzeylerinde, istenen öğenin INDEX’i tanımlanır; ortaya çıkan indeks listesi, değeri döndürülecek ya da değiştirilecek olan ALT YAPIYI tanımlar.

5. Yordamlar Arasında Parametrelerin Yönlendirilmesi

Geleneksel programlama sistemlerinde, yordamların sonuçları, üzerlerinde yapılan çağrıların bağlamına bağlı olarak çeşitli şekillerde kullanılır. Bir sonuç, örneğin:

  1. Çağıran program içinde bir dallanma kararına temel oluşturabilir.
  2. Sonraki bir yordam çağrısına argüman olabilir.
  3. Yok sayılabilir ve böylece fiilen atılabilir.

Çalışma zamanında, bir sonucun amaçlanan kullanımına ilişkin bilgi genellikle yalnızca çağıran programın içinde bulunur; program sonuçları inceler, ikinci bir yordama aktarır ya da dilediği gibi yok sayar.

Dağıtık bir sistemde, bir veya daha fazla süreçler arası mesaj aracılığıyla gerçekleştirilen, çağrılan yordamdan çağırana sonuçların taşınması pahalı bir işlem olabilir; özellikle sonuçlar büyük olduğunda. Veri hareketi, Model’in, her bir yordam sonucunun amaçlanan kullanım biçiminin önceden çağrılan ortamına bildirilmesine izin verecek şekilde genişletilmesiyle, yukarıdaki Durum 2 ve 3’te azaltılabilir. Durum 2’de, her iki çağrılan yordam da aynı süreç içinde yer alıyorsa, sonuç kaynağında tutulabilir ve daha sonra yerel olarak bir sonraki yordam için sağlanabilir. Durum 3’te ise sonuç, gönderilip hedefte atılmak yerine kaynağında atılabilir (hatta belki hiç hesaplanmayabilir).

5.1 Parametrelerin Dolaylı Olarak Belirtilmesi

Değişkenler, yukarıdaki Durum 2’de yer alan verimsizlikleri ortadan kaldırma potansiyeli sunar; çünkü bir yordam tarafından üretilen sonuçların, başka bir yordam tarafından gereksinim duyulana kadar çağrılan sürecin içinde tutulabileceği bir yer sağlarlar. Protokol, herhangi bir yordamın çağıranının, CALL mesajının ek parametreleri olarak aşağıdaki gibi isteğe bağlı bir argüman ve sonuç listesi maskesi eklemesine izin verilerek, değişkenlerin bu şekilde kullanılmasına olanak tanıyacak biçimde genişletilebilir:

parametre listesi maskesi
[LIST değişken, ...)]
[CHARSTR]

Bir parametre listesi maskesi, her bir parametrenin ya doğrudan, parametre listesi aracılığıyla ya da dolaylı olarak çağrılan sürecin içindeki bir VARIABLE üzerinden iletilmesine izin verir. Böylece maskenin her bir öğesi, çağrılan ortamın karşılık gelen parametreyi nasıl elde edeceğini ya da nasıl elden çıkaracağını belirtir. Bir yordamın sonucunu başka bir yordamın argümanı olarak sağlamak için, çağıranın yalnızca birinci ve ikinci çağrılarda sırasıyla sonuç ve argüman listesi maskelerindeki karşılık gelen öğeleri uygun şekilde ayarlaması yeterlidir. Yordam başarısız olursa sonuç listesi maskesi göz ardı edilmelidir ve hata numarası ile tanılayıcı mesaj doğrudan çağırana döndürülmelidir.

5.2 Parametre Yönlendirmesi için Geçici Değişkenlerin Sağlanması

Her bir uygulama programı, yukarıda tanımlandığı şekilde kullanılmak üzere değişkenler sağlayabilse de, daha ekonomik bir yaklaşım, Model’in, uygulama programının yardımı olmaksızın ortam tarafından yönetilen ve çalışma zamanında gerektiğinde oluşturulup silinen özel geçici değişkenlere izin verecek şekilde genişletilmesidir. Protokole aşağıdaki sistem yordamı çiftinin eklenmesi, yerel ortamın uzak bir süreçte bu tür değişkenleri oluşturmasına ve silmesine olanak tanır:

CRTVARIABLE (değişken, değer)
    CHARSTR   any

DELVARIABLE (değişken)
    CHARSTR

Bu yordamlar, belirtilen VARIABLE’ı sırasıyla oluşturur ve siler. CRTVARIABLE ayrıca yeni oluşturulan değişkene bir başlangıç VALUE değeri atar.

Bu yeni yordamlar, ortamın uygulama programına, karşılık gelen sistem yordamlarının çağrı dizilerine benzer, ancak ek bir argüman olarak hedef sürecin işlem tanıtıcısını kabul eden ilkel işlemler sunmasını sağlar. Bunların uygulanması yalnızca ortamın iç tablolarından uzak süreci belirlemesini ve o süreçte CRTVARIABLE ya da DELVARIABLE’ı çağırmasını gerektirir.

5.3 Sonuçların Atılması

Yukarıdaki Durum 3’te ortaya çıkan verimsizlikler, çağıranın sonuç listesi maskesi aracılığıyla (örneğin, sıfır uzunluklu bir CHARSTR ile) bir sonucun yok sayılacağını ve dolayısıyla çağırana geri döndürülmesine gerek olmadığını belirtmesine izin verilerek kolayca ortadan kaldırılır.

6. Daha Zengin Bir Denetim Aktarımı Yelpazesinin Desteklenmesi

Model tarafından şu anda tanımlandığı biçimiyle, bir yordam çağrısı, çağıranın önce gerçekleştirilmesini istediği işlemi tanımladığı ve çağrılanın işlemi gerçekleştirdikten sonra sonucunu bildirdiği basit iki aşamalı bir diyalogdur. Bu basit diyalog biçimi, dağıtık sistemlerin geniş bir sınıfını rahatlıkla gerçekleştirmek için yeterli olsa da, bazen daha karmaşık biçimler gereklidir. Model, aşağıda dördü örnek olarak tanımlanan, daha güçlü çeşitli diyalog biçimlerini kabul edecek şekilde genişletilebilir.

6.1 Çağıran ile Çağrılan Arasında Denetimin Aktarılması

Birçok geleneksel programlama sistemi, çağıran ile çağrılanın, çağrılan geri dönmeden önce denetimi herhangi bir sayıda kez değiş tokuş etmesine izin verir. Bu tür eş yordam bağları, örneğin çağrılanın karşılaştığı bir problem için yardım almasına ya da bir alt işlemin sonuçlarını iletip bir sonrakinin argümanlarını almasına olanak sağlar.

Protokole, çağrılması daha önce başlatılmış başka bir yordamın denetiminden vazgeçilmesini sağlayan aşağıdaki sistem yordamının eklenmesi, ortamın çağıran ile çağrılan arasında bir eş yordam bağlantısı kurmasını mümkün kılar:

TAKEPROCEDURE (tid, yourtid, parametreler)
    INDEX  BOOLEAN  LIST

Argümanları, etkilenen işlemin TID tanımlayıcısını, tanımlayıcının hangi ad alanından atandığını gösteren YOURTID bilgisini (yani denetimden vazgeçen sürecin çağıran mı yoksa çağrılan mı olduğunu) ve denetimi bırakan yordam tarafından sağlanan PARAMETERS’ı içerir. Protokolün mevcut bir olanağından yararlanarak (yani TAKEPROCEDURE çağrılarına yönelik onayı reddederek), çağıran ortam denetim aktarımını tek bir süreçler arası mesajla gerçekleştirebilir.

Bu yeni yordamın Protokole eklenmesi, ortamın uygulama programına aşağıdaki yeni ilkel işlemi sunmasını sağlar:

LINKPROCEDURE (tid, argümanlar → sonuç_durumu, sonuçlar)
    INDEX  LIST  [BOOLEAN]  LIST

Bu ilkel işlem, CALLPROCEDURE ilkel işleminin de, çağrılan geri dönmek yerine bir eş yordam bağlantısı başlatırsa, ilgili işlem tanımlayıcısını döndürecek şekilde değiştirilmiş olduğunu varsayar. LINKPROCEDURE’un çağrılması, ARGUMENTS sağlayarak diyalogu sürdürür ve denetimi uzak yordamına geri verir; ardından bir sonraki denetim aktarımını ve buna eşlik eden RESULTS’ı bekler. Uzak yordam, başka bir eş yordam bağlantısı başlatmak yerine geri dönerse, ilkel işlem OUTCOME’u bildirir ve işlem tanımlayıcısını geçersiz kılar.

Bu ilkel işlem, uzak yordam denetimden vazgeçene kadar uygulama programını engellerken, yalnızca eş yordam bağlantısını başlatan ve uygulama programının sonuç durumunu ve sonuçları ikinci bir işlemle toplamasına izin veren bir varyant da sağlanabilir.

6.2 Çağıranın/Çağrılanın İşaretlenmesi

Bir eş yordam bağlantısı ile başlatılan diyalog yerine çoğu zaman bir monolog daha uygundur. Örneğin çağıran ya da çağrılan, algıladığı bir olayı bildirmek veya tamponlama gereksinimlerini en aza indirmek için büyük parametreleri parça parça göndermek isteyebilir. Bu gibi durumlarda geri dönüş parametreleri gerekmediğinden, başlatan yordam yalnızca ortağını işaretlemesi yeterlidir ve çağrının denetimini elinde tutar.

Protokole aşağıdaki sistem yordamının eklenmesi, Model’i sinyalleri destekleyecek şekilde genişletir ve ortamın, çağrının denetiminden vazgeçmeden, daha önce başlatılmış başka bir yordamdan ya da ona parametre iletmesini sağlar:

SGNLPROCEDURE (tid, yourtid, parametreler)
    INDEX  BOOLEAN  LIST

Daha önce tanımlanan TAKEPROCEDURE yordamı gibi, argümanları etkilenen işlemin TID tanımlayıcısını, tanımlayıcının hangi ad alanından atandığını belirten YOURTID bilgisini ve PARAMETERS’ın kendisini içerir.

Bu yeni yordam, ortamın uygulama programına, sistem yordamına benzer bir çağrı dizisine sahip ancak argüman olarak YOURTID gerektirmeyen bir ilkel işlem sunmasını sağlar. Bunun uygulanması yalnızca ortamın iç tabloları aracılığıyla uzak süreci belirlemesini ve o süreçte SGNLPROCEDURE’u çağırmasını gerektirir.

SGNLPROCEDURE’a yapılan her çağrı için onay istenerek ve gerekirse aynı işlemi etkileyen sonraki çağrılar, onay gelene kadar geciktirilerek, çağıran ortam kaba bir akış denetimi biçimi sağlar ve böylece uzak sürecin tamponlarının taşması önlenir.

6.3 Üstlerden Yardım İstenmesi

Geleneksel programlama sistemlerinde olduğu gibi, dağıtık bir sistemde uzaktan çağrılabilen yordamlar bazen görevlerinin bir kısmını yerine getirmek için başkalarına başvurur. Bu tür iç içe çağrılar sonucunda oluşan denetim iş parçacığı boyunca yer alan her yordam, bir anlamda yalnızca doğrudan çağıranına değil, aynı zamanda denetim iş parçacığı boyunca üzerinde yer alan tüm yordamlara karşı da sorumludur. Sorumluluklarını doğru şekilde yerine getirebilmek için bir yordamın bazen bu üstlerle iletişim kurması gerekir.

Bazen bir yordam, yürütülmesi sırasında, dış yardıma ihtiyaç duymadan ilerleyemeyeceği bir noktaya ulaşır. Örneğin ek kaynaklara ya da adına çalıştığı insan kullanıcıdan ek yönlendirmeye gereksinim duyabilir. Bu çıkmaza ulaşmadan önce, yordam, iptal edilmesi durumunda kaybedilecek önemli miktarda gerçek ve/veya işlem süresi harcamış olabilir.

Protokole aşağıdaki sistem yordamının eklenmesi, ortamın çağrılanın üstlerinden yardım istemesine olanak tanıyarak bu tür verimsizlikleri en aza indirir:

HELPPROCEDURE (tid, numara, bilgi → çözüm)
    INDEX  INDEX  any  any

Argümanları, etkilenen işlemin TID tanımlayıcısını (bu durumda denetim aktarımının yönü örtüktür), karşılaşılan problemi tanımlayan bir NUMBER’ı ve keyfi ek INFORMATION’ı içerir.

Bu yeni yordamın, ortamın uygulama programına sunmasını sağladığı ilkel işlem, aynı çağrı dizisine sahiptir. Bunun uygulanması yalnızca ortamın iç tablolarından uzak süreci belirlemesini ve o süreçte HELPPROCEDURE’u çağırmasını gerektirir.

Yardım arayışı, çağıranın ortamında HELPPROCEDURE’un çağrılmasıyla başlar. Eğer çağıran problemi anlıyorsa (yani numarasını tanıyorsa) ve çözebiliyorsa, HELPPROCEDURE çağıranın sağladığı SOLUTION bilgisini doğrudan döndürür. Aksi takdirde, HELPPROCEDURE bir sonraki üstün yanıt verme fırsatı bulabilmesi için kendisini o süreçte yinelemeli olarak çağırmalıdır. Arama, bir üstün olumlu yanıt vermesiyle ya da denetim iş parçacığının sonuna ulaşıldığında sona erer. İkinci durumda, iç içe geçmiş HELPPROCEDURE yordamlarının her biri, aramanın başarısız olduğunu belirtmek üzere çağıranına başarısız şekilde döner.

6.4 Üstlere Bir Olayın Bildirilmesi

Bir yordam bazen, üstlerinin haberdar edilmesi gereken bir olaya tanık olur ya da böyle bir olaya neden olur (örneğin yordamın yürütülmesindeki önemli bir adımın başlaması veya tamamlanması). Protokole aşağıdaki sistem yordamının eklenmesi, ortamın çağrılanın üstlerini keyfi bir olay hakkında bilgilendirmesini sağlar:

NOTEPROCEDURE (tid, numara, bilgi)
    INDEX  INDEX  any

HELPPROCEDURE gibi, argümanları etkilediği işlemin TID tanımlayıcısını, bildirilen olayı tanımlayan bir NUMBER’ı ve keyfi ek INFORMATION’ı içerir.

Bu yeni yordamın, ortamın uygulama programına sunmasını sağladığı ilkel işlem, aynı çağrı dizisine sahiptir. Bunun uygulanması yalnızca ortamın iç tablolarından uzak süreci belirlemesini ve o süreçte NOTEPROCEDURE’u çağırmasını gerektirir.

NOTEPROCEDURE’a yapılan her çağrı için onay istenerek ve gerekirse bu işlemi etkileyen sonraki çağrılar onay gelene kadar geciktirilerek, çağıran ortam kaba bir akış denetimi biçimi sağlar ve böylece uzak sürecin tamponlarının taşması önlenir.

Yordamın üstlerinin bilgilendirilmesi, çağıranın sürecinde NOTEPROCEDURE’un çağrılmasıyla başlar ve denetim iş parçacığı boyunca özyinelemeli olarak yukarı doğru ilerleyerek en üst düzeye ulaşana kadar devam eder.

7. Yürütülen Yordamların İptal Edilmesi

Kullanıcıdan komut kabul eden geleneksel sistemler, bazen yanlışlıkla ya da hatalı parametrelerle verilmiş, ya da tamamlanmasını bekleyemeyeceği bir komutu iptal etmesine izin verir. Bu yetenek, özellikle komutun (örneğin bir kaynak dosyayı derleyen bir komutun) önemli bir yürütme süresine sahip olduğu durumlarda büyük önem taşır. Dağıtık bir sistemde, böyle bir komutun yürütülmesi bir veya daha fazla uzak yordamın çağrılmasını içerebilir. Dolayısıyla bu komutun iptali, beklemede olan tüm uzak yordam çağrılarının durdurulmasını gerektirir.

Protokole aşağıdaki sistem yordamının eklenmesi, ortamın daha önce çağrılmış başka bir yordamı durdurmasına olanak tanıyarak bir komut iptali olanağı için temel sağlar:

ABRTPROCEDURE (tid)
	       INDEX

Tek argümanı, etkilediği işlemin belirtilen TID tanımlayıcısıdır.

Bu yeni yordamın, ortamın uygulama programına sunmasını sağladığı ilkel işlem, aynı çağrı dizisine sahiptir. Bunun uygulanması yalnızca yerel ortamın iç tablolarından uzak süreci belirlemesini ve o süreçte ABRTPROCEDURE’u çağırmasını gerektirir.

SONUÇ

Bu makalede önerilen genişletmeler sonucunda ortaya çıkan GENİŞLETİLMİŞ Protokol ve Model, sırasıyla Ek B ve Ek C’de özetlenmiştir. Söylemeye gerek yok ki, Ek D’nin birkaçını önerdiği, süreç etkileşiminin daha birçok biçimi ve yönü hâlâ araştırılmayı beklemektedir. Bununla birlikte, çalışma zamanı ortamı tarafından halihazırda sunulan ilkel işlemler, uygulama programcısına dağıtık sistemler kurmak için güçlü ve tutarlı bir araçlar kümesi sağlar.

TEŞEKKÜRLER

Hem SRI’nin Augmentation Research Center’ı (ARC) içinde hem de daha geniş ARPANET topluluğunda yer alan birçok kişi, bu makalede ve eşlik eden çalışmasında tanımlanan Protokol ve Model’in geliştirilmesine zamanlarını ve fikirlerini katkıda bulunmuştur. Aşağıdaki kişilerin katkıları özellikle belirtilmektedir: ARC’den Dick Watson, Jon Postel, Charles Irby, Ken Victor, Dave Maynard, Larry Garlick; ve Bolt, Beranek and Newman, Inc.’ten Bob Thomas ve Rick Schantz.

ARC, birkaç yıldır ağ tabanlı dağıtık sistemler için yüksek seviyeli bir çerçeve üzerinde çalışmaktadır [2]. Bu özel Protokol ve Model, ARC tarafından Temmuz 1974’te başlatılan bir araştırmanın sonucudur. Bu araştırma, Model’in geliştirilmesini; belirli bir makine için bir prototip çalışma zamanı ortamının tasarlanmasını, belgelenmesini ve uygulanmasını içermiştir [4, 5]; özellikle Bolt, Beranek and Newman, Inc. tarafından geliştirilen Tenex işletim sistemini çalıştıran bir PDP-10 üzerinde [6]. On iki aylık bir dönem boyunca üç tasarım yinelemesi gerçekleştirilmiş ve ortaya çıkan belirtim Tenex için uygulanmıştır. Tenex RTE, bu makalede önerilen yeteneklerin bir üst kümesini sağlar.

Burada rapor edilen çalışma, Savunma Bakanlığı’na bağlı Advanced Research Project Agency ve Hava Kuvvetleri’nin Rome Air Development Center’ı tarafından desteklenmiştir.

EK A

PCP VERİ NESNELERİ İÇİN İLETİM BİÇİMLERİ

Veri nesneleri, Protokol aracılığıyla bir süreçten diğerine gönderilebilmeden önce standart bir iletim biçiminde kodlanmalıdır. Etkili bir strateji, birden fazla biçim tanımlamak ve çalışma zamanında en uygun olanı seçerek Protokole biçim uzlaşması için bir mekanizma eklemektir. Biçim uzlaşması, ortamın bir başka sorumluluğu olacaktır ve bu nedenle uygulama programı için tamamen görünmez hale getirilebilir.

Aşağıda iki iletim biçimi önerilmektedir. Birincisi, 36 bitlik makineler arasında kullanım için 36 bitlik bir ikili biçimdir; ikincisi ise farklı makineler arasında kullanım için 8 bitlik ikili, “evrensel” bir biçimdir. Veri nesneleri, her iki biçimde de tam olarak türlendirilmiştir; böylece bu hizmetin uygulama programına sağlanması istenirse, ortam gelen parametreleri otomatik olarak çözümleyip içselleştirebilir.

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

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

EK B

GENİŞLETİLMİŞ PROSEDÜR ÇAĞRI PROTOKOLÜ

Bu makalede önerilen genişletmelerden ortaya çıkan Protokol aşağıda özetlenmiştir. Okuyucu, PCP veri türleri kavramının sağladığı temel sayesinde mümkün olan özlü sözdizimsel tanımı not etmelidir.

Parametre listesi maskeleri, makalede önerildiği gibi yalnızca CALL iletisinin ek parametreleri olarak değil, aynı zamanda TAKEPROCEDURE ve SGNLPROCEDURE sistem prosedürlerinin argümanları olarak da dahil edilmiştir. Protokol tanımı boyunca “MASK”, aşağıdakinin kısaltmasıdır:

[LIST (değişken [CHARSTR], ...)]

İletiler

OUTCOME FALSE ise:

RESULTS, `LIST (error INDEX, diagnostic CHARSTR)` biçimindedir

Süreçle İlgili Sistem Prosedürleri

Paketle İlgili Sistem Prosedürleri

Değişkenle İlgili Sistem Prosedürleri

Prosedürle İlgili Sistem Prosedürleri

EK C

RTE İLKELLERİNİN ÖZETİ

Bu makalede önerilen Model genişletmelerinin bir sonucu olarak uygulama programına sunulan DPS ilkelleri aşağıda özetlenmiştir. Toplu olarak, uygulama programcısına dağıtık sistemler kurmak için güçlü ve tutarlı bir araçlar kümesi sağlarlar. Bazı ilkeller (örneğin, CRTPROCESS ve DELPROCESS), DPS’nin bir gün kendisinin evrilebileceği bir “ağ işletim sistemi (NOS)” için gerekli unsurlardır.

Süreçler

Paketler

Değişkenler

Prosedürler

EK D

ARAŞTIRMA İÇİN EK ALANLAR

Bu makalede geliştirilen ve önceki ekte özetlenen genişletilmiş dağıtık programlama sistemi zaten oldukça güçlü olmakla birlikte, süreç etkileşiminin daha birçok yönü elbette incelenmeyi beklemektedir. Protokolün, ortamın sonunda sağlayabilmesini mümkün kılması gereken ek olanaklar arasında aşağıdaki mekanizmalar yer almaktadır:

  1. Prosedür çağrılarını uzun süreler boyunca (örneğin, günlerce) kuyrukta tutma.
  2. İstekleri süreç gruplarına yayınlama.
  3. Çalışmayı diğer süreçlere alt sözleşme yoluyla devretme (aracı olarak kalmadan).
  4. Başlangıç yükü en aza indirilmiş, kısa veya seyrek süreçler arası alışverişleri destekleme.
  5. Sistem hatalarından kurtulma ve sonrasında yeniden başlatma.

KAYNAKLAR

  1. White, J. E., "A High-Level Framework for Network-Based Resource Sharing," 1976 Ulusal Bilgisayar Konferansı’nın AFIPS Konferans Bildirileri’nde yayımlanmak üzere sunulmuştur.
  2. 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).
  3. White, J. E., DPS-10 Version 2.5 Implementor's Guide, Augmentation Research Center, Stanford Research Institute, Menlo Park, California, 15 Ağustos 1975 (SRI-ARC Katalog Öğesi 26282).
  4. 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).
  5. 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).
  6. 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.

ŞEKİL LİSTESİ