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

Dağıtık Yetenekli Hesaplama Sistemi (DCCS)

Yazar
J.E. Donnelley
Kurum
Tarih
Şubat 1976
Durum
Network Working Group Yorum Talebi
Kanal
protokol/

Ağ Çalışma Grubu

Yorum İsteği: 712
J.E. Donnelley
Lawrence Livermore Laboratuvarı
Şubat 1976

Dağıtık Yetenekli Hesaplama Sistemi (DCCS)

Bu makale, 3 Ağustos 1976 tarihinde Toronto, Kanada’da düzenlenecek olan uluslararası Bilgisayar İletişimi Konferansı ICCC-76’ya sunulmak üzere hazırlanmıştır.

Bu, bildiriler dergisinde yayımlanması amaçlanan bir makalenin ön baskısıdır. Yayımlanmadan önce değişiklikler yapılabileceğinden, bu ön baskı yazarın izni olmaksızın atıf yapılmayacağı anlayışıyla erişime sunulmaktadır.

Bu makalede raporlanan çalışma, kısmen Çevre Koruma Ajansı ile yapılan #EPA-IAG-D5-E681-DB numaralı sözleşme kapsamında ve kısmen Ulaştırma Bakanlığı ile yapılan #[RA] 76-12 numaralı sözleşme kapsamında desteklenmiştir. Rapor, ABD Enerji Araştırma ve Geliştirme Ajansı için #W-7405-Eng-48 numaralı sözleşme kapsamında hazırlanmıştır.

Dağıtık Yetenekli Hesaplama Sistemi (DCCS)

Bu makale dağıtık bir hesaplama sistemini tanımlamaktadır. İlk bölümde CCS (Capability Computing System – Yetenekli Hesaplama Sistemi) adı verilen idealleştirilmiş bir işletim sistemi tanıtılmaktadır. İkinci bölümde DCCS protokolleri tanımlanmakta ve DCCS’nin bir CCS üzerinde desteklenmesi için gerekli süreçler açıklanmaktadır. Makalenin geri kalan kısmı, heterojen sistemleri içeren bir bilgisayar ağında DCCS protokolünün kullanılmasını tartışmakta ve bazı uygulamaları sunmaktadır. Sunulan uygulamalar, dağıtık veri erişimi için tek kopya probleminin en iyi şekilde çözülmesi ve saydam bir ağ kaynak optimizasyon mekanizmasının inşa edilmesidir.

Yetenekli Hesaplama Sistemi (CCS)

CCS, mevcut hiçbir işletim sistemine birebir benzememekle birlikte, literatürde tanımlanan bazı mevcut yetenek listesi (C-list) işletim sistemlerine oldukça benzemektedir [1–7]. CCS’nin birçok özelliği, RATS işletim sistemine önerilen bir değişiklikten gelmektedir [1–3].

Çoğu bilgisayar sisteminin belgelerinde farklı türde nesnelere pek çok gönderme bulunmaktadır. Tipik olarak tartışılan nesneler şunlardır: dosyalar, süreçler, işler, hesaplar, semaforlar, görevler, sözcükler, aygıtlar, çatallar, olaylar vb. C-list sistemlerinin amaçlarından biri, bu tür tüm nesnelere tekdüze bir erişim yöntemi sağlamaktır. Tüm CCS nesnelerine tekdüze bir mekanizma üzerinden erişilmesi, DCCS’nin türden bağımsız bir biçimde uygulanmasına olanak tanır.

CCS, süreç adı verilen etkin bir öğeyi destekleyen çoklu işlemeli bir sistemdir. Çoğu amaç için, okuyucunun bir sürecin ne olduğu konusundaki sezgisel anlayışı yeterlidir. Bir süreç, ticari olarak mevcut bilgisayarlardakilere benzer talimatları yürütebilir. Kendisiyle ilişkili bir bellek alanına sahiptir ve “RUN” ve “WAIT” gibi bazı durum göstergelerine sahiptir. Ancak C-list sistemlerinde bir sürecin ayrıca bir yetenek listesi (C-list) de vardır. Bu liste, sürecin erişmesine izin verilen nesnelere yönelik işaretçilerin tutulduğu bir alandır. Bu işaretçiler sistem tarafından korunur. Sürecin kendisi, C-list’ini yalnızca erişim için bir yetenek kaynağı olarak ve kendisine verilen yetenekler için bir depo olarak kullanabilir. Şekil 1, daha sonra tartışılan bazı tipik süreçleri diyagram olarak göstermektedir. Diyagramlarda, bir süreç kutusunun sol yarısı C-list, sağ yarısı ise bellektir.

CCS’deki tekdüze erişim yönteminin anahtarı çağırma (invocation) mekanizmasıdır. Bu, bir sürecin C-list’indeki bir yetenek üzerinde istek yaptığı mekanizmadır. Bir çağırma, çoğu bilgisayar sistemindeki alt yordam çağrısına çok yakından benzer. Bir istek yapıldığında, çağıran süreç bir hizmet yordamına bazı parametreler geçirir ve karşılığında bazı parametreler alır.

Bununla birlikte, çağırma mekanizması ile olağan alt yordam çağırma mekanizmaları arasında birkaç önemli fark vardır. İlk fark, çağrılan hizmet yordamının genellikle sürecin bellek uzayında bulunmamasıdır. Hizmet yordamı, korumalı yetenek tarafından işaret edilir ve donanımda, mikrokodda, sistem çekirdeği kodunda, başka herhangi bir süreçte ya da DCCS’de göreceğimiz üzere başka bir bilgisayar sisteminde uygulanabilir. Örneğin Şekil 1’de, hizmet veren süreç semafor isteğinde bulunan süreç için bir çağırmaya hizmet etmektedir.

İkinci fark, bir yetenek çağrılırken, yalnızca veri parametreleriyle birlikte başka yeteneklerin de geçirilebilmesi ve geri döndürülebilmesidir. DCCS’de, yetenekler ve veriler bir iletişim ağı üzerinden de geçirilebilir.

Çağırma mekanizmasının son önemli ayırt edici özelliği, bankalarda sıkça görülen dış gişe pencereleri benzetmesiyle en iyi şekilde açıklanabilir. Bu pencerelerde genellikle müşteri ya da gişe görevlisi tarafından açılabilen, ancak ikisi tarafından birden açılamayan bir çekmece bulunur. Bu çekmece dışında, müşteri ile görevli fiziksel olarak yalıtılmıştır. Çağırma mekanizması durumunda, çağıran süreç belirli yetenekleri ve bilgileri açıkça hizmet yordamına geçirir ve geri dönüş parametreleri için C-list konumlarını ve bellek alanlarını belirtir. Bu parametreler dışında, çağıran süreç ile hizmet veren yordam yalıtılmıştır. DCCS’de bu koruma mekanizması, sistemler ağı boyunca genişletilmektedir.

CCS’de, bir yeteneği çağırmak, bir sürecin bilgi ya da yetenek geçirip alabilmesinin tek yoludur. Tipik bir işletim sisteminde genellikle sistem çağrıları olarak adlandırılan işlemlerin tümü, CCS’de uygun yetenekler üzerindeki çağırmalardır. Bir CCS C-list’i, sürecini tamamen sarar. Bu gerçek, ağ optimizasyonuna ilişkin ikinci uygulamada (sayfa 23) açıklandığı gibi süreçlerin saydam biçimde taşınabilmesi için gereklidir.

CCS Yetenekleri

DCCS’yi inşa etmek için CCS’de belirli ilkel yeteneklerin var olduğu varsayılacaktır. Aşağıdaki çağırmalar, verimlilik ya da pratiklikten ziyade basitlik amacıyla gösterilmektedir. Uygulamada, yetenekler genellikle çeşitli hata dönüşleri vb. içeren, çok daha yüksek derecede optimize edilmiş çağırmalara sahiptir. Bir yeteneği tanımlamak için, kendisine ne geçirildiğinin bir fonksiyonu olarak ne döndürdüğünü açıklamak yeterlidir. Aşağıda kullanılan gösterimde, geçirilen parametre listesi bir > işareti ile, ardından döndürülen parametre listesi ile takip edilir. Her parametre listesinde, veri parametrelerini bir ; ve ardından yetenek parametreleri izler.

1. Dosya Yeteneği

2. Dizin Yeteneği

3. Nil Yeteneği

Bir dizin ilk oluşturulduğunda, yalnızca nil yetenekleri içerir. Nil her zaman “Empty” döndürür.

4. Süreç Yeteneği

a. ve b. çağırmaları sürecin bellek uzayına gider. c., d. ve e. çağırmaları C-list’ine gider. f. ve g. süreç yürütmesini başlatır ve durdurur.

CCS Genişletme Mekanizması

DCCS’nin CCS üzerinde uygulanabilmesi için gerekli olan bir temel yetenek mekanizması daha vardır. Bu mekanizma, süreçlerin kendilerini hizmet verebilecekleri yeni yetenekler üretecek şekilde ayarlamalarına olanak tanır. Bu tür mekanizmalar, mevcut C-list sistemlerinde büyük farklılıklar gösterir. Çalışabilir bir mekanizma burada tanımlanmaktadır. Başlangıcı sağlamak için bir ilkel yetenek daha gereklidir:

5. Sunucu Yeteneği

Yukarıda sunucuya ek olarak iki yetenek daha tanıtıldı: requestor ve request yetenekleri. Bu yetenekler, bir sunucu üzerindeki çağırmalar tanımlanırken açıklanacaktır.

İlk çağırma, bir requestor yeteneği üretir ve döndürür. Geçirilen numara, requestor ile ilişkilendirilir. Requestor yeteneği, üretilen yeni yetenektir. Bir requestor üzerinde her türlü çağırma gerçekleştirilebilir. Var olma nedenleri tamamen budur. Bir sunucu yeteneğine sahip olan bir süreç, bir requestor’u herhangi bir tür yetenek gibi gösterebilir.

“My requestor?” çağırması, bir yeteneğin çağrılan sunucuya ait bir requestor olup olmadığını belirlemek için kullanılabilir. Şunlardan birini döndürür:

Son çağırma, yani “Wait”, sunucunun dikkatini gerektiren bir şey gerçekleşene kadar bekler. Bir hizmet yordamının bilgilendirilmesi gereken iki önemli olay vardır. Bir requestor’a ait son yetenek üzerine yazılırsa ve bu nedenle yeni bir tane üretilene kadar requestor tekrar çağrılamaz hale gelirse, “Wait” şu şekilde döner:

Son iki parametre olan 0 ve Nil, döndürülen PD ve request için yalnızca dolgu niteliğindedir (bkz. 5c). “Wait” bir “Deleted” döndürdüğünde, hizmet yordamı numaralandırılmış requestor’a hizmet etmek için kullanılan tüm kaynakları geri dönüştürebilir (örneğin requestor numarası).

“Wait”in dönmesine neden olan en önemli olay, sunucuya ait requestorlardan birinin çağrılmasıdır. Bu durumda sunucu şu şekilde döner:

PD olarak etiketlenen üçüncü parametre, Parametre Tanımlayıcısı anlamına gelir. Bir requestor çağırması sırasında her iki yönde geçirilen her tür parametrenin sayısını tanımlar. Özellikle dört sayıdan oluşur: geçirilen veri bitleri, geçirilen yetenekler, istenen veri bitleri ve istenen yetenekler.

Alınan son parametre olan request yeteneği, hizmet veren süreç tarafından geçirilen parametreleri almak ve istenen parametreleri istekte bulunan sürece geri döndürmek için kullanılır. Buna uygun olarak aşağıdaki çağırmalara sahiptir:

6. Request Yeteneği

“Return” çağırması, istekte bulunan süreci yeniden başlatma gibi ek bir etkiye sahiptir.

Sunucu mekanizmasıyla ilgili dikkat edilmesi gereken bir nokta, bir sunucunun requestor’ları üzerindeki çağırmaların, sunucu üzerinde “Wait” çağırılana kadar kuyrukta bekletilmesidir. Bir isteğe ayrı bir yetenek verilmesinin nedenlerinden biri de budur. Hizmet veren süreç, isterse isteği hizmet verilmesi için başka bir sürece devredebilirken, kendisi sunucusu üzerinde daha fazla istek beklemeye geri dönebilir. Banka gişesi benzetmesindeki karşılık gelen durum, gişe görevlisinin isteği hizmet verilmesi için bir başkasına verip, kendisinin bekleyen müşterilere dönmesi olurdu. Request yeteneği, geri dönüşün doğru şekilde gerçekleştirilebilmesi için istekte bulunan süreci işaret eder.

Bilinen semafor [8] hizmet yordamına ait bir örnek hizmet, hizmet verdiği her semafor için semafor değerlerini içeren bir tablo tutar. Ayrıca, semafor değeri sıfıra eşit ya da sıfırdan küçük olduğunda semafor üzerinde “P” işlemi yapan süreçlerin semaforda askıda kalmasını temsil eden kuyruklanmış isteklerin bir listesini de tutar. Bir semafor üzerindeki çağırmalar şunlardır:

7. Semafor

Semafor hizmet veren süreci için bir diyagram ve akış şeması Şekil 1 ve 2’de verilmiştir. Akış şemaları, temel yetenek çağırmalarının çoğunu içermekte, ancak tablo aramalarının ayrıntılı tanımlarını içermemektedir. Semafor hizmet yordamına ait tablo yapısı, desteklenen her semafor için girdiler içerir. Her girdi, semafor değerini ve semaforda askıda kalan isteklere ait işaretçilerin listesine bir bağlantıyı içerir (varsa).

Sunucu mekanizmasının en önemli özelliği, onun kullanılmasıyla herhangi bir yeteneğin işlevselliğinin taklit edilebilmesidir.

[9] numaralı kaynakta tartışılan ekleme özelliğine benzer olan bu özellik, DCCS’nin temel taşıdır. Taklidin temel fikri, sunucunun istekleri beklemek için “Wait” etmesi ve bunları taklit edilen yeteneğe iletmesidir. Tek bir yeteneğin bu şekilde taklit edilmesi Şekil 3’te akış şeması olarak gösterilmiştir. Gösterilen taklit, tüm durumları doğru şekilde ele almayan bir genel bakıştır. Örneğin, bir yetenek çağırmalara alındıkları sırayla geri dönmeyebilir. Bu durumlar DCCS’de de ortaya çıkar; bu nedenle bunların ele alınması burada değil, DCCS kapsamında tartışılacaktır. İşleme ve iletişimden kaynaklanan gecikmeler dışında, DCCS’de yapılan taklidin birebir olduğu önemle belirtilmelidir.

DCCS’nin Uygulanması

DCCS başlangıçta bir CCS sistemleri ağı üzerinde tanımlanacaktır. Bir ağ yeteneğinin var olduğu varsayılacaktır:

8. Ağ Yeteneği

“Output” çağırmasının, mesajı çıkış için kuyruğa aldıktan hemen sonra döndüğü ve “Input” çağırmasının ise bir mesaj mevcut olana kadar beklediği varsayılmaktadır.

Eğitsel amaçlarla, DCCS’nin tanımı iki bölüme ayrılacaktır. Önce önemli mekanizmaların kısa bir genel görünümü verilecektir. Bu genel görünüm, bazı önemli konuların üzerinden yüzeysel geçecek olup, genel görünümü izleyen daha ayrıntılı açıklamada bu konular tek tek çözümlenecektir.

DCCS’nin amacı, bir ana makinedeki yeteneklerin, uygun yeteneklere sahip diğer ana makinelerdeki süreçler tarafından referans alınabilmesini sağlamaktır. Bunu gerçekleştirmek için, her ana makine diğer ana makineler tarafından kullanılmak üzere desteklediği yeteneklerin bir listesini tutar. Her ana makine ayrıca, uzak ana makine tarafından desteklenen karşılık gelen yetenekmiş gibi görünmesi sağlanan requestor’lar dağıtan bir sunucuyu da destekler. Bu taklit edilen requestor’lardan biri çağrıldığında, parametreleri taklit eden ana makine tarafından ağ üzerinden destekleyen ana makineye geçirilir. Destekleyen ana makine daha sonra uygun yeteneğin çağrılmasını sağlar ve parametreleri ona iletir. Çağrılan yetenek geri döndüğünde, geri dönüş parametreleri ağ üzerinden tekrar taklit eden ana makineye iletilir. Taklit eden ana makine de geri dönüş parametrelerini istekte bulunan sürece döndürür.

Örneğin, şekil 4’te diyagramı verilen bir dosya üzerindeki "Read" isteğini ele alalım. Emüle edilen dosya (bir istekçi) çağrıldığında, emüle eden süreç "invoke", istekçi numarası, PD; istek alır. Geri döndürülen istekçi numarası aslında iki sayıdan oluşan bir tanımlayıcıdır: ana bilgisayar numarası ve yetenek numarası. Bu tanımlayıcılara Uzak Yetenek Tanımlayıcıları (Remote Capability Descriptors, RCDs) denir. Bir RCD, bir ana bilgisayarı ve o ana bilgisayar tarafından desteklenen yetenekler listesindeki bir yeteneği tanımlar. Bir isteği aldıktan sonra, emüle eden süreç, istekte bulunan süreç tarafından geçirilen parametreleri okur ve bunları Parametre Tanımlayıcısı ile birlikte "Invoke" iletisinde uzak ana bilgisayara gönderir.

Uzak ana bilgisayar bu bilgileri aldığında, parametreleri desteklenen dosya yeteneğine onu çağırarak geçirir ve Parametre Tanımlayıcısında belirtildiği üzere uygun dönüş parametrelerini belirtir. Çağrılan dosya parametreleri döndürdüğünde, dönen veriler ağ üzerinden "Return" iletisinde emüle eden ana bilgisayara geri gönderilir. Dönen veriler daha sonra, emüle eden ana bilgisayarın başlangıçta aldığı istek yeteneği üzerinde bir "Return" çağrısı gerçekleştirilerek istekte bulunan sürece geri döndürülür. İstekte bulunan süreç dönüşle uyandırıldığında, ona tam olarak yerel bir dosya çağrılmış gibi görünecektir.

Bu, geçirilen ve döndürülen parametreler yalnızca bilgiden oluştuğunda sorunsuz çalışır; peki ya yetenekler söz konusu olduğunda ne olur? Bu durumda yordamlar mevcut uzak yetenek erişim mekanizmasını kullanır ve uygun tanımlayıcıyı geçirir. Örnek olarak, bir dizin üzerindeki "Take" çağrısı şekil 5’te diyagramı verilmiştir. Tek temel fark, bir yeteneğin geri döndürülmesi gerekliliğidir. Yetenek, çağrılan dizin (ya da gerçekte her ne ise) tarafından döndürüldüğünde, destekleyen ana bilgisayar yetenek için desteklenen yetenekler listesinde yeni bir yuva ayırır ve emüle eden ana bilgisayara yeni bir tanımlayıcı döndürür. Emüle eden ana bilgisayar tanımlayıcıyı aldığında, döndürülen tanımlayıcıyı istekçi numarası olarak kullanan yeni bir istekçi oluşturur ve istekçiyi çağıran sürece döndürür. Böylece döndürülen istekçi, uzaktan erişilen dizinden alınan yetenek gibi davranır ve gerçek yetenekmiş gibi tam olarak çağrılabilir.

Bu mekanizma hakkında fark edilmesi gereken önemli bir nokta, ne emüle eden ana bilgisayarın ne de destekleyen ana bilgisayarın hangi tür yetenekleri desteklediklerine dair herhangi bir fikre sahip olmasının gerekmediğidir. Mekanizma türden bağımsızdır. Bir diğer önemli husus da, her iki ana bilgisayarın da birbirine, haklı olarak verilmiş yeteneklerden fazlasıyla güvenmek zorunda olmamasıdır. DCCS süreçlerinin kendilerinin bile yalnızca ağ yetenekleri ve desteklenen yeteneklerle ilgili olarak güvenilir olması yeterlidir. Son olarak, güvenlik için ifşa edilebilecek gizli parolalara ihtiyaç duyulmadığına dikkat ediniz. DCCS, CCS koruma mekanizmalarını doğrudan genişletir.

Şimdi DCCS’nin daha eksiksiz bir tanımı verilecektir. Ancak gereksiz karmaşıklıktan kaçınmak için hata göstergeleri, sistemin yeniden başlatılması ve kurtarılması, ağ arızaları, ileti boyutu sınırlamaları, kaynak sorunları vb. gibi çeşitli konular ele alınmamaktadır. Bu konular DCCS’ye özgü değildir ve çözümleri burada ilgili değildir.

Daha önce belirtildiği gibi, eksiksiz bir DCCS, ilk genel bakışta üstü kapalı geçilen çeşitli konuları ele almak zorundadır. Bu konular tartışılırken, genel bakışta ele alınan "Invoke" ve "Return" iletilerinin ötesinde çeşitli ileti türleri tanıtılmaktadır. Tüm DCCS iletilerinin biçimleri şekil 6’da özetlenmiştir.

A. Zamanlama

Çağrıların tamamlanması çok uzun zaman alabilir. Daha önce semafor yeteneğinde bir örnek görmüştük. Daha da çarpıcı bir örnek, 100 yıl geçtikten sonra hiçbir şey döndürmesi istenen bir saat yeteneği olabilir. Açıkça, emüle eden sürecin, daha fazla çağrıyı hizmete almadan önce uzak ana bilgisayardan bir "Return" iletisi alana kadar beklemesini istemeyiz.

Emüle eden ana bilgisayarda yapılan şey, destekleyen ana bilgisayara "Invoke" iletisini gönderdikten sonra istek yeteneğini bekleyen istekler listesine eklemektir (bu, önceki semafor örneğine biraz benzer). Emülatör daha sonra geri dönüp başka yerel istekleri bekleyebilir.

Destekleyen tarafta da benzer bir sorun vardır. Ağ girişi yeteneği üzerinde bekleyen sürecin, desteklenen yeteneği basitçe çağırıp dönüşü beklemesini istemeyiz. Yapması gereken, desteklenen yeteneği gerçekten çağıracak bir çağrı süreci kurmaktır; böylece bekleyen ağ girişleri hızlıca hizmet alabilir. Çağıran süreç, parametreleri aldıktan sonra bunları geri döndürmelidir.

Bu ek mekanizmalar, ana bilgisayarlar arasında birden fazla isteğin etkin olmasının getirdiği karmaşıklığı ekler. Bu istekler bir Uzak İstek Numarası (Remote Request Number, RRN) ile tanımlanır. RRN, bekleyen istekler listesindeki bir indekstir.

B. Döngüler

Eğer A ana bilgisayarı bir yeteneği B ana bilgisayarına geçirir ve B’den, yeteneği emüle etmek için kullanılan istekçiyi A’ya geri geçirmesi istenirse, B istekçiyi destek listesine ekleyip A’nın ona uzaktan erişmesine izin vermeli midir? Eğer bunu yaparsa, A üzerindeki yeni istekçi çağrıldığında, parametreler B’ye geçirilir; burada çağıran süreç tarafından istekçiye aktarılır. İstekçinin çağrılması, parametrelerin ağ üzerinden A’ya geri gönderilmesine neden olur ve burada gerçek yetenek nihayet çağrılır. Ardından dönüş parametreleri, B üzerinden A’ya geri dönmek için ters prosedürü izlemek zorunda kalır. Bu açıkça en uygun mekanizma değildir.

Bu sorunun çözümü, 5b’de tanımlanan bir sunucu yeteneği üzerindeki "My requestor?" çağrısını kullanır. B, A’ya döndürülecek bir yeteneği "My requestor?" çağrısı ile denetlediğinde ve yeteneğin, desteklendiğinin A olduğunu belirten bir istekçi numarasına sahip kendi istekçilerinden biri olduğunu bulduğunda, istekçi numarasını (bunun aslında bir Uzak Yetenek Tanımlayıcısı, RCD olduğunu hatırlayınız) doğrudan A’ya geri döndürebilir; bu tanımlayıcı, belirtilen yeteneğin A’ya yerel olduğunu ve A’ya desteklenen yetenekler listesindeki yeteneğin indeksini verir.

C. Güvenlik

B bölümünde sunulan mekanizma bir tür güvenlik sorununu gündeme getirir. Eğer B, A’nın desteklenen listesinde bir yeteneği çağırmaya çalışırsa, A bunu sorgusuz sualsiz kabul etmeli midir? Eğer ederse, ağdaki herhangi bir ana bilgisayar kötü niyetle başka herhangi bir ana bilgisayar tarafından desteklenen herhangi bir yeteneği çağırabilir. Erişime yalnızca standart çağrı mekanizması aracılığıyla verilmişse izin vermek için, her ana bilgisayar belirli bir yeteneğe hangi ana bilgisayarların erişimi olduğunu gösteren bir bit vektörü tutabilir. Bir ana bilgisayar geçersiz bir istek alırsa, bu bir hata durumudur.

D. Dolaylılık

B bölümünde belirtilen döngü sorununa ek bir varyasyon vardır. Bu varyasyon, A’nın bir yeteneği B’ye geçirmesi ve B’nin de onu C’ye geçirmek istemesi durumunda ortaya çıkar. Burada da B, geçireceği yeteneği bildiği Uzak Yetenek Tanımlayıcısını (RCD) göndererek açıkça belirtebilir. RCD yeteneği belirtir; ancak A muhtemelen C’nin buna erişmesi gerektiğine inanmayacaktır.

B, A’ya şunu söylemelidir: “Ben, senin i’inci yeteneğine erişimi olan biri olarak, bunu C ana bilgisayarına vermek istiyorum.” Bunu yapmak için başka bir ileti türü kullanılır. "Give" iletisi, desteklenen yeteneği ve verilmesi gereken ana bilgisayarı belirtir (şekil 6’ya bakınız). Burada da, sahip olmadığınız bir yeteneği vermeye çalışmak bir hata durumudur.

E. Onaylama

"Give" iletisiyle ilgili son bir sorun vardır. Eğer B "Give" iletisini A’ya gönderir ve ardından Uzak Yetenek Tanımlayıcısını (RCD) C’ye göndermeye devam ederse, C, "Give" A tarafından alınmadan önce RCD’yi kullanmaya çalışabilir. Bu nedenle, B’nin RCD’yi C’ye göndermeden önce A’nın "Give" iletisini onaylamasını beklemesi gerekir. Bu mekanizma, ana bilgisayarların onaylanmamış "Give" iletilerini kuyruklamasını gerektirir. Bir "ACK" için biçim şekil 6’da verilmiştir. Bu kuyruklama, belirli bir RCD için ilkinden sonraki çoğu "Give" iletisi için önlenebilir; ancak bu, çok daha fazla bellek kullanımı ve "Delete" iletilerinin yayınlanması pahasına olur (aşağıdaki F bölümüne bakınız).

F. Silme

B üzerinde desteklenen belirli bir yetenek için A üzerindeki tüm istekçiler silinirse, A bunu B’ye bildirebilir; böylece B:

Bu işlev yeni bir "Delete" iletisi gerektirir.

Şekil 6 ileti biçimlerinin bir özetidir. Şekiller 7–11, eksiksiz DCCS’yi akış diyagramlarıyla gösterir. Akış diyagramlarında, dizinleri belirtmek için kısaltmalar kullanılır:

Tablo işlemleri ayrıntılı olarak verilmemiştir. Üç tablo gereklidir. İlki CSL ile ilişkilidir ve yukarıdaki C bölümünde belirtildiği üzere erişimi gösteren bit vektörlerini içerir. İkinci tablo RRL ile ilişkilidir ve her etkin istek için bir ana bilgisayar numarası içerir. İstenen ana bilgisayardan başka bir ana bilgisayar tarafından bir istek üzerinde dönüş yapılmaya çalışılması bir hata durumudur. Son tablo ise bekleyen "Invoke" ve "Return" isteklerini içeren bir ileti arabelleğidir.

CSL’ye ve onun tablosuna başvururken tehlikelerden kaçınmak için CSLS adlı bir semafor kullanılır. Benzer şekilde, ileti arabelleğini kilitlemek için bir ileti arabelleği semaforu olan MBS kullanılır. RRL ve IPL için, verilen algoritmalarla herhangi bir kilide gerek yoktur.

Genelleştirme ve Uygulama

DCCS’yi uygulamak için, bir CCS sistemleri ağı varsaydık. Ancak CCS’nin teknik özellikleri oldukça gevşekti. Örneğin, komut kümelerinden hiç söz edilmedi. CCS benzeri herhangi bir uygulama, burada tanımlanan mekanizmaları kullanarak nesnelerini paylaşabilir. Örneğin, farklı bir komut kümesine sahip bir sisteme geçirilen bir süreç, verimli bir emülatör olarak kullanılabilir.

DCCS’nin en önemli genelleştirmesi, belirli bir uygulamanın ağ üzerinden hangi tür ana bilgisayarla konuştuğuna dair hiçbir fikrinin olmamasıdır. Her tür ana bilgisayar, verilen iletileri kullanarak bir protokol uygulayabilir. Örneğin, tek kullanıcılı bir sistem, kullanıcısının uzak yetenekler üzerinde keyfi çağrılar yapmasına ve döndürülen yeteneklerin bir tablosunu tutmasına izin verebilir. Böyle bir sistem, uzak süreçlere verilebilecek bir tür standart terminal yeteneğini de destekleyebilir. Çok kullanıcılı bir sistemde, benzer işlevler her kullanıcı için gerçekleştirilebilir.

Bir anlamda, DCCS protokolünü uygulayan herhangi bir sistem bir C-list sistemi haline gelir. Örneğin tek kullanıcılı sistem, tek kullanıcılı sisteme veya başka herhangi bir sisteme istekçi veren uzak sunucu yeteneklerine hizmet eden uzak süreçler kurabilir. Çağrılardan dönen sonuçlar, terminal yeteneğinin uzaktan çağrılması yoluyla tek kullanıcının terminalinde görünebilir, vb.

C-list olmayan sistemlerde DCCS’nin uygulanması, bazı açılardan Amerika Birleşik Devletleri Savunma Bakanlığı’nın ARPA ağındaki bazı ana bilgisayardan ana bilgisayara protokol uygulamalarında olanlara benzer [10]. ARPA ağı ana bilgisayardan ana bilgisayara protokolleri, bir sistemdeki bir sürecin başka bir sistemdeki bir süreçle iletişim kurmasına izin verir. ARPA ağı protokol uygulamalarının birçoğu, daha önce hiç olmayan ana bilgisayarlarda yerel süreçten sürece iletişimi fiilen ortaya çıkarmıştır.

Uygulamalar

I. Tek Kopya

İlk uygulama, bilgi kaynakları için adlandırdığım tek kopya problemine bir çözümdür. Bir süreç bir bilgi kaynağından bilgi aldığında, yalnızca bilginin yerel bir kopyasını alabilir. Bu durum, bilgi dağıtık bir veritabanından geldiğinde açıktır; ancak paylaşılan bellekten gelen bilginin işleme için yerel yazmaçlara kopyalanması gereken, sıkı bağlı sanal bellek durumlarında da geçerlidir. Bir süreç bir bilginin yerel bir kopyasına sahip olduktan sonra, bilginin güncel kalmasını, yani tek kopya olmasını sağlamaya çalışmak isteyebilir.

Bu sorunun geleneksel çözümü, yerel bir kopya almadan önce bilgi kaynağını bir semaforla kilitlemek ve ardından kaynağın kilidini açmadan önce yerel kopyayı geçersiz kılmaktır. Bu çözüm, diğer süreçler kopyalanan veriyi istemese bile, her ihtimale karşı verinin hızla kilidinin açılması gerektiği gerçeğinden muzdariptir. Bu da birçok gereksiz kopyanın yapılmasına yol açabilir.

Gereken şey, yerel kopyaları tam olarak diğer süreçlerin isteklerinin geçersiz kılmayı zorunlu kılacağı anda geçersiz kılacak bir mekanizmadır. Böyle bir mekanizma sunmak için, bir bilgi kaynağı, olağan okuma ve yazma çağrılarına ek olarak aşağıdakilere sahip olabilir:

Bildirim yetenekleri üzerindeki önemli çağrı şudur:

Temel fikir, bir sürecin, kopyasının geçersiz kılınmasına yönelik bir girişim olduğunda bilgilendirilmesini istemesine izin vermektir. Kopya yalnızca okuma için kullanılıyorsa, sürecin yalnızca verinin değiştirilmesine yönelik girişimlerin bildirimlerini istemesi yeterlidir ("Write lock"). Bir süreç bu şekilde bilgilendirildiğinde, kopyasını geçersiz kılması ve bekleyen yazma erişiminin devam edebileceğini bilgi kaynağı sunucusuna bildirmek için write notify yeteneğini silmesi beklenir.

Okuma-yazma kilidi durumunda, RW notify yeteneği bölümün okunması ve yazılması için de kullanılabilir. Bölüme yapılacak herhangi bir başka erişim bildirimle sonuçlanır. Bildirim alındığında, RW notify yeteneğine sahip sürecin, yeteneğini silmeden önce bilginin en son kopyasını geri yazması beklenir.

Alan kısıtları bu mekanizma için daha fazla ayrıntı sunmaya izin vermemektedir. Fark edilmesi gereken önemli nokta, bilginin geniş ölçüde dağıtılmış olabilmesine rağmen tek bir kopyaymış gibi görünmesini sağlayacak şekilde bir bilgi kaynağının paylaşılmasına izin vermesidir. Bu mekanizma, dağıtık veritabanları için önemli uygulamalara sahiptir.

II. Ağ Kaynaklarının Optimizasyonu

Muhtemelen DCCS’nin yararlılığını en iyi gösteren uygulama, daha önce tanıtılan en azından ilkel yetenekleri meydana getirmek için kullanılabilecek türden bir ağ optimizasyon yeteneğidir:

9. Hesap Yeteneği

Geçirilen type parametresi en azından şunlardan herhangi biri olabilir: "File", "Directory", "Process" veya "Server". Uygun türde bir yetenek geri döndürülür. Yetenek için kullanılan kaynaklar ilgili hesaba ücretlendirilir.

Şimdi, bir DCCS ağı içindeki bir CCS sisteminde bulunan bir kullanıcının, diğer birkaç CCS sistemindeki hesap yeteneklerine uzaktan erişimi olduğunu varsayalım. Bu kullanıcı, ağ kaynaklarının kullanımını optimize etmek için süper hesap yeteneği olarak adlandırılabilecek bir şey oluşturabilir. Süper hesap yeteneği, aslında bir süreç tarafından hizmet verilen bir istekçi olacaktır. İstenen optimizasyon tamamen kullanıcı kontrolünde olacaktır; ancak daha bariz örneklerden bazıları aşağıda sunulmuştur:

1. Statik Nesne Oluşturma Optimizasyonu

2. Dinamik Optimizasyon

Dinamik optimizasyon yapmak için, süper hesap, talepte bulunan sürece, statik optimizasyonundan sonra uzak hesaptan aldığı yeteneği doğrudan vermez; bunun yerine, gerçek yetenek gibi çalışacak ancak optimize edilmiş bir talepçi sunar.

Böyle bir süper hesap, optimize edilen nesnelerin işlevsel özelliklerini değiştirmeden, bir kullanıcının ağ kaynaklarını kullanıcının gereksinimlerine uygun biçimde otomatik olarak optimize edebilir.

Son Not

Bu makalede tanımlanan DCCS mekanizmaları, şu anda ARPA bilgisayar ağı üzerinde deneysel bir protokol olarak kullanılmak üzere bir Digital Equipment Corporation PDP-11/45 bilgisayarında uygulanmaktadır [10]. DCCS protokolü ayrıca ARPA ağı ile Energy Research and Development Administration'ın CTR ağı arasında bir ağ geçidi için temel oluşturacaktır [11]. Yazarın umudu, DCCS mekanizmasının, hesaplama kaynaklarında gerçekten serbest bir pazar oluşturmak için gerekli olan türde ağlara yaklaşımı hızlandırmasıdır.

Teşekkürler

Yazar, bu makalede sunulan fikirlere elverişli bir ortam meydana getirdikleri için Lawrence Livermore Laboratory'deki Computer Research Project'in yöneticilerine ve personeline teşekkür etmek ister. Mevcut RATS sisteminde uygulandığı şekliyle C-listesi fikirlerinin birçoğu için Charles Landau'ya özel teşekkür borçludur.

Kaynaklar

  1. C. R. Landau, The RATS Operating System, Lawrence Livermore Laboratory, Rapor UCRL-77378 (1975)
  2. C. R. Landau, An Introduction to RATS (RISOS/ARPA Terminal System): An Operating System for the DEC PDP-11/45, Lawrence Livermore Laboratory, Rapor UCRL-51582 (1974)
  3. J. E. Donnelley, Notes on RATS and Capability List Operating Systems, Lawrence Livermore Laboratory, Rapor UCID-16902 (1975)
  4. B. W. Lampson, "On Reliable and Extendable Operating Systems", Techniques in Software Engineering, NATO Sci. Comm. Workshop Material, Cilt II (1969)
  5. W. Wulf ve diğerleri, "HYDRA: The Kernel of a Multiprocessor Operating System", Communications of the ACM 17(6) (1974)
  6. P. Neumann ve diğerleri, "On the Design of a Provably Secure Operating System", International Workshop on Protection in Operating Systems, IRIA (1974)
  7. R. S. Fabry, "Capability-Based Addressing", Communications of the ACM 17(7) (1974)
  8. E. W. Dijkstra, "Cooperating Sequential Processes", içinde Programming Languages, F. Genuys (ed.), Academic Press, ss. 43–112 (1968)
  9. F. A. Akkoyunlu ve diğerleri, "Some Constraints and Tradeoffs in the Design of Network Communications", Proceedings of the Fifth Symposium on Operating System Principles, Cilt 9, No. 5, ss. 67–74 (1975)
  10. L. G. Roberts ve B. D. Wessler, "Computer Network Development to Achieve Resource Sharing", AFIPS Conference Proceedings 36, ss. 543–549 (1970)
  11. "National CTR Computer Center", Lawrence Livermore Laboratory Energy and Technology Review, UCRL-52000-75-12, Aralık (1975)

Şekiller çevrimiçi sürüme dahil edilmemiştir. Şekilleri de içeren belgelerin basılı bir kopyasını edinmek isteyen okuyucular, aşağıdaki adresten UCRL-77800 numaralı belgenin bir kopyasını talep edebilirler:

Technical Information Department
Lawrence Livermore Laboratory
University of California
Livermore, California 94550

Sorular veya yorumlar memnuniyetle karşılanır ve yazara yönlendirilmelidir:

ABD Postası Yoluyla:

James E. Donnelley
Lawrence Livermore Laboratory L-307
P.O. Box 808
Livermore, California 94550

Telefon ile:

(415) 447-1100 dahili 3406

ARPA Net Postası Üzerinden:

JED@BBN

"Bu rapor, Amerika Birleşik Devletleri Hükümeti tarafından desteklenen çalışmaların bir dökümü olarak hazırlanmıştır. Ne Amerika Birleşik Devletleri ne de Amerika Birleşik Devletleri Energy Research & Development Administration'ı, ne de bunların herhangi bir çalışanı ya da yüklenicileri, alt yüklenicileri veya bunların çalışanları; açıklanan herhangi bir bilginin, aygıtın, ürünün ya da sürecin doğruluğu, eksiksizliği veya kullanışlılığı konusunda açık ya da zımni herhangi bir garanti vermez veya herhangi bir hukuki sorumluluk ya da yükümlülük üstlenmez ya da bunların kullanımının özel mülkiyete ait hakları ihlal etmeyeceğini beyan etmez."