Rpc protokolü. Uzaktan Yordamlar: Uzaktan Yordam Çağrıları, Tanımı ve Özellikleri

Bir ağ üzerinden haberleşen programlar bir iletişim mekanizmasına ihtiyaç duyar. Alt seviyede, paketlerin alınması üzerine, ağ sinyali işleme programı tarafından bir sinyal işlenir. En üst düzeyde, Ada dilinde benimsenen buluşma mekanizması çalışır. NFS, istemcinin sunucuyla iletişim kurduğu bir uzaktan yordam çağrısı (RPC) mekanizması kullanır (bkz. Şekil 1). Bu işleme uygun olarak, istemci önce sunucuya istek gönderen bir prosedüre erişir. Talep içeren bir paket geldiğinde, sunucu açılması için prosedürü çağırır, talep edilen hizmeti gerçekleştirir, bir yanıt gönderir ve kontrol istemciye geri döner.

RPC arayüzünün üç katmana sahip olduğu düşünülebilir:

Üst seviye tamamen şeffaftır. Bu düzeydeki bir program, örneğin, uzak makinedeki kullanıcı sayısını döndüren rnusers () öğesini çağırabilir. Programda arama yaptığınız için RPC mekanizmasını kullanmayı bilmenize gerek yoktur.

Orta katman, en yaygın uygulamalar içindir. Bu düzeydeki RPC çağrıları registerrpc() ve callrpc() rutinleri tarafından işlenir: registerrpc() sistem genelinde karanlık kodu alır ve callrpc() bir uzak prosedür çağrısını yürütür. rnusers() çağrısı, bu iki rutin kullanılarak uygulanır.

Alt seviye, daha karmaşık görevler için kullanılır ve varsayılanı prosedür parametrelerinin değerlerine değiştirir. Bu seviyede, RPC mesajlarını iletmek için kullanılan soketleri açıkça değiştirebilirsiniz.

Genel bir kural olarak, üst katmanı kullanmalı ve alt katmanları gereksiz yere kullanmaktan kaçınmalısınız.

Bu eğitimde arayüzü sadece C olarak ele almamıza rağmen, herhangi bir dilden uzak prosedürlere çağrı yapılabilir. Farklı makinelerdeki süreçler arasındaki iletişimi organize etmek için RPC mekanizmasının çalışması, aynı makinedeki çalışmasından farklı değildir.

RPC (Uzaktan Yordam Çağrısı), uzak kullanıcılar ile bu kullanıcılar tarafından çağrılan belirli ana bilgisayar programları arasındaki bir arabirimdir. Bir ana bilgisayar için bir RPC hizmeti, genellikle istemcilere bir program paketi sağlar. Bu programların her biri sırayla bir veya daha fazla uzak prosedürden oluşur. Örneğin, RPC çağrılarına dayanan bir NFS uzak dosya sistemi hizmeti yalnızca iki programdan oluşabilir: örneğin, bir program yüksek seviyeli kullanıcı arayüzleriyle ve diğeri düşük seviyeli G/Ç işlevleriyle etkileşime girer.

Her RPC çağrısı iki taraf içerir: prosedür çağrısı talebini sunucuya gönderen aktif istemci ve istemciye yanıtı gönderen sunucu.

Not. Bu durumda "istemci" ve "sunucu" terimlerinin belirli bir işleme atıfta bulunduğunu unutmayın.Belirli bir ana bilgisayar veya yazılım (işlem veya program) bir istemci veya sunucu olarak hareket edebilir. Örneğin, uzaktan yordam hizmetinin çalışmasını sağlayan bir program, aynı zamanda ağ dosya sistemi ile çalışan bir istemci olabilir.

RPC, yerel prosedür çağrılarına benzer bir uzaktan prosedür çağrısı modeli üzerine kurulmuştur. Yerel bir yordamı çağırdığınızda, argümanları belirli bir bellek konumuna, yığına veya ortam değişkenlerine gönderirsiniz ve işlemin kontrolünü belirli bir adrese aktarırsınız. Çalışmayı tamamladıktan sonra belirli bir adreste sonuçları okuyup işleminize devam ediyorsunuz.

Uzak prosedür durumunda, temel fark, uzak işlev çağrısının iki süreç tarafından sunulmasıdır: istemci süreci ve sunucu süreci.

İstemci işlemi, çağrılan prosedürün parametrelerini içeren sunucuya bir mesaj gönderir ve çalışmasının sonuçlarını içeren bir yanıt mesajı bekler. Bir yanıt alındığında sonuç okunur ve işleme devam edilir. Sunucu tarafında, çağrı işleyici işlemi bekleme durumundadır ve bir mesaj geldiğinde prosedür parametrelerini okur, yürütür, yanıt gönderir ve bir sonraki çağrı için bekleme durumuna geçer.

RPC protokolü, süreçler arasında ek iletişimler için herhangi bir gereklilik getirmez ve gerçekleştirilen işlevlerin senkronizasyonunu gerektirmez, yani çağrılar eşzamansız ve bağımsız olmayabilir, böylece istemci bir yanıt beklerken diğer prosedürleri yürütebilir. RPC sunucusu her fonksiyon için ayrı bir süreç veya sanal makine tahsis edebilir, bu nedenle önceki isteklerin bitmesini beklemeden bir sonrakini hemen kabul edebilir.

Ancak, yerel ve uzak prosedür çağrıları arasında birkaç önemli fark vardır:

1. Hata işleme.İstemci, sunucuda veya ağda uzak prosedürler çağrılırken meydana gelen hatalardan her durumda haberdar edilmelidir.

2. Küresel değişkenler. Sunucunun istemcinin adres alanına erişimi olmadığından, uzak yordam çağrılarında genel değişkenler biçimindeki gizli parametreleri kullanamazsınız.

3. Verim. Uzak prosedürlerin yürütme hızı, kural olarak, benzer yerel prosedürlerin yürütme hızından bir veya iki büyüklük sırası daha düşüktür.

4. Kimlik doğrulama. Uzaktan yordam çağrıları ağ üzerinden gerçekleştiğinden, istemci kimlik doğrulama mekanizmaları kullanılmalıdır.

Protokol oluşturma ilkeleri.

RPC protokolü birkaç farklı aktarım protokolü kullanabilir. RPC protokolünün tek sorumluluğu standartları uygulamak ve mesaj iletimini yorumlamaktır. Mesaj iletiminin güvenilirliği ve güvenilirliği tamamen taşıma katmanı tarafından sağlanır.

Ancak RPC, aktarım protokolünün seçimini ve bazı işlevlerini kontrol edebilir. RPC ve taşıma protokolü arasındaki etkileşime bir örnek olarak, RPC aracılığıyla bir uygulama sürecinin RPC portunu atama prosedürünü düşünün - Portmapper.

Bu işlev dinamik olarak (istek üzerine) bir RPC bağlantısına belirli bir bağlantı noktası atar. İşlev Portmapper oldukça sık kullanılır çünkü RPC için ayrılmış taşıma bağlantı noktaları kümesi sınırlıdır ve potansiyel olarak eşzamanlı olarak çalışabilecek işlemlerin sayısı çok yüksektir. Portmapperörneğin, NFS istemci/sunucu iletişim bağlantı noktaları seçildiğinde çağrılır.

Hizmet Portmapper RPC yayın mesajı mekanizmasını belirli bir bağlantı noktasına kullanır - III. Bu bağlantı noktasında, istemci belirli bir RPC hizmetinin bağlantı noktası için bir istek yayınlar. Hizmet Portmapper vergi mesajını işler, yerel RPC hizmetinin adresini belirler ve müşteriye bir yanıt gönderir. RPC hizmeti Portmapper hem TCP hem de UDP protokolleriyle çalışabilir.

RPC, çeşitli taşıma protokolleriyle çalışabilir, ancak işlevlerini asla çoğaltmaz, yani RPC, TCP'nin üzerinde çalışıyorsa, RPC, TCP'ye bağlantının güvenilirliği ve güvenilirliği ile ilgili tüm endişeleri bırakır. Ancak, RPC, UDP'nin üzerine kurulursa, mesaj tesliminin garanti edilmesini sağlamak için ek yerel işlevsellik sağlayabilir.

Not. Uygulamalar, RPC protokolünü bir Jump Subroutine Instruction (JSR) ağı üzerinden tanımlanmış bir işlev çağrısı prosedürü olarak görüntüleyebilir.

RPC protokolünün çalışması için aşağıdaki koşulların karşılanması gerekir:

1. Belirli bir ana bilgisayarda uzaktan çağrılan tüm prosedürlerin benzersiz kimliği. RPC istekleri, üç tanımlayıcı alanı içerir - uzak programın (hizmetin) numarası, uzak programın sürüm numarası ve belirtilen programın uzaktan prosedür numarası. Program numarası hizmetin üreticisi tarafından atanır, prosedür numarası bu hizmetin özel işlevini belirtir.

2. RPC protokolü sürümünün tanımlanması. RPC mesajları, bir RPC protokolü sürüm alanı içerir. İstemci farklı RPC sürümleriyle çalışırken iletilen parametrelerin biçimlerini eşleştirmek için kullanılır.

3. İstemcinin sunucuya kimliğini doğrulamak için mekanizmalar sağlamak. RPC protokolü, hizmette istemcinin kimliğini doğrulamak ve gerekirse her istekle veya istemciye bir yanıt göndermek için bir prosedür sağlar. Ayrıca RPC, çeşitli ek güvenlik mekanizmalarının kullanılmasına izin verir.

RPC, dört tür kimlik doğrulama mekanizması kullanabilir:

AUTH_NULL - kimlik doğrulama gerekmez

AUTH_UNIX - UNIX standart kimlik doğrulaması

AUTH_SHORT - Kendi kodlama yapısıyla UNIX standart kimlik doğrulaması

AUTH_DES - DES kimlik doğrulaması

4. İlgili taleplere yanıt olarak mesajların tanımlanması. RPC yanıt mesajları, dayandıkları isteğin kimliğini içerir. Bu tanımlayıcı, RPC çağrısının işlem tanımlayıcısı olarak adlandırılabilir. Bu mekanizma, özellikle asenkron modda çalışırken ve birkaç RPC çağrısı dizisi yürütürken kullanışlıdır.

5. Protokol hatalarının belirlenmesi. Tüm ağ veya sunucu hatalarının, bağlantıdaki katılımcıların her birinin hatanın nedenini belirleyebileceği benzersiz tanımlayıcıları vardır.

Protokol mesaj yapıları

RPC mesajlarını bir taşıma protokolü üzerinden aktarırken, bir taşıma paketi içinde birkaç RPC mesajı bulunabilir. Bir mesajı diğerinden ayırt etmek için bir kayıt işaretçisi (RM - Kayıt İşaretleyici) kullanılır. Her RPC mesajı tam olarak bir RM ile "işaretlenir".

Bir RPC mesajı birkaç parçadan oluşabilir. Her yığın, dört baytlık başlık ve (0 ila 2 ** 31-1) veriden oluşur. Başlığın ilk biti, yığının son olup olmadığını gösterir ve kalan 31 bit, veri paketinin uzunluğunu gösterir.

RPC'nin yapısı, veri formatlarının tanım ve gösterim dilinde resmi olarak tanımlanmıştır - prosedürlerin tanımına ilişkin ilavelerle XDR. RPC biçimlendirme dilinin, prosedürlerle çalışma ile desteklenen XDR'nin bir uzantısı olduğunu bile söyleyebilirsiniz.

RPC paketinin yapısı şöyle görünür:

struct rpc_msg (

imzasız int xid;

birleşim anahtarı (msg_type mtype) (

call_body cbody;

cevap gövdesi;

xid geçerli işlemin tanımlayıcısı olduğunda, call_body istek paketidir, answer_body ise yanıt paketidir. İstek yapısı şuna benzer:

struct çağrı gövdesi (

imzasız int rpcver'ler;

imzasız int prog;

imzasız int vers;

imzasız int proc;

opaque_auth kredisi;

opaque_auth verf;

/ * prosedür parametreleri * /

answer_body yapısı, bir hata durumunda iletilen bir yapı (bu durumda hata kodunu içerir) veya isteğin başarılı bir şekilde işlenmesi için bir yapı (bu durumda döndürülen verileri içerir) içerebilir.

Üst düzey programlama arayüzü.

Bir programda alt programların kullanılması, bir görevi yapılandırmanın, daha net hale getirmenin geleneksel yoludur. En sık kullanılan alt programlar, çeşitli programlar tarafından kullanılabilecekleri kütüphanelerde toplanır. Bu durumda, yerel (yerel) bir çağrıdan bahsediyoruz, yani hem arayan hem de çağrılan nesneler aynı bilgisayarda aynı program içinde çalışır.

Uzaktan çağırma durumunda, bir bilgisayarda çalışan bir işlem, uzak bilgisayarda işlemi başlatır (yani, aslında uzak bilgisayarda prosedür kodunu çalıştırır). Açıkçası, bir uzak prosedür çağrısı, geleneksel bir yerel çağrıdan önemli ölçüde farklıdır, ancak bir programcının bakış açısından, pratikte böyle bir fark yoktur, yani, bir uzak prosedür çağrısının mimarisi, bir yerel çağrıyı simüle etmenize izin verir.

Ancak, yerel bir çağrı olması durumunda, program parametreleri çağrılan prosedüre iletir ve çalışmanın sonucunu yığın veya paylaşılan hafıza alanlarından alırsa, uzak çağrı durumunda, parametrelerin aktarımı bir ağ üzerinden bir isteğin iletilmesi ve çalışmanın sonucu alınan yanıttadır.

Bu yaklaşım, dağıtılmış uygulamalar oluşturmak için olası bir temeldir ve birçok modern sistem bu mekanizmayı kullanmasa da, birçok durumda temel kavramlar ve terimler kalır. RPC mekanizmasını tanımlarken, geleneksel olarak çağrı sürecini istemci ve prosedürü uygulayan uzak süreci sunucu olarak adlandıracağız.

Bir uzaktan prosedür çağrısı aşağıdaki adımları içerir:

1. İstemci programı, saplama adı verilen bir prosedüre yerel bir çağrı yapar. Aynı zamanda, istemci saplamayı çağırarak, aslında sunucu prosedürüne bir çağrı yapıyor gibi görünüyor. Gerçekten de, istemci gerekli parametreleri saplamaya iletir ve sonucu döndürür. Ancak, bu tam olarak müşterinin tasavvur ettiği gibi değildir. Saplamanın işi, uzak prosedür için argümanları kabul etmek, muhtemelen onları bazı standart biçime dönüştürmek ve bir ağ talebi oluşturmaktır. Argümanları paketlemek ve bir ağ isteğinde bulunmak, sıralama olarak adlandırılır.

2. Ağ isteği, ağ üzerinden uzaktaki sisteme gönderilir. Bunu yapmak için saplama, örneğin önceki bölümlerde tartışılanlar gibi uygun çağrıları kullanır. Bu durumda, yalnızca TCP / IP ailesinden değil, çeşitli taşıma protokollerinin kullanılabileceğini unutmayın.

3. Uzak ana bilgisayarda her şey ters sırada gerçekleşir. Sunucu saplaması isteği bekler ve alındığında parametreleri alır - prosedür çağrısının argümanları. Ayıklama (düzeltme) gerekli dönüştürmeleri içerebilir (örneğin, baytların sırasını değiştirme).

4. Saplama, ağ üzerinden alınan argümanları ileterek, istemcinin talebinin ele alındığı gerçek sunucu prosedürüne bir çağrı yapar.

5. Prosedürü tamamladıktan sonra, kontrol sunucu saplamasına döner ve gerekli parametreleri ona iletir. İstemci saplaması gibi; sunucu saplaması, ağ üzerinden gönderilen bir ağ yanıt mesajı oluşturmak için prosedür tarafından döndürülen değerleri isteğin geldiği sisteme dönüştürür.

6. İşletim sistemi, alınan mesajı istemci saplamasına iletir, bu da gerekli dönüşümden sonra değerleri (uzaktan prosedür tarafından döndürülen değerlerdir) müşteriye iletir ve bu da bunu normal bir dönüş olarak yorumlar. prosedürden.

Böylece, müşterinin bakış açısından, yerel bir prosedürde olduğu gibi bir uzak prosedür çağrısı yapar. Aynısı sunucu için de söylenebilir: prosedür standart şekilde çağrılır, bir nesne (sunucu saplaması) yerel prosedürü çağırır ve onun tarafından döndürülen değerleri alır. İstemci, saplamayı çağrılabilir bir sunucu prosedürü olarak ele alır ve sunucu, kendi saplamasını istemci olarak yorumlar.

Bu nedenle, taslaklar, hem istemci hem de sunucu çağrıların yerel olarak yapıldığını varsaymasına rağmen, istemci ve uzak sunucu (prosedür) arasındaki mesajların üretilmesi ve iletilmesinin tüm yönlerinden sorumlu olan RPC sisteminin çekirdeğini oluşturur. Bu, RPC'nin temel konseptidir - saplama kodunda iletişimin dağıtılmış (ağ) yapısını tamamen gizlemek. Bu yaklaşımın avantajları açıktır: hem istemci hem de sunucu ağ uygulamasından bağımsızdır, her ikisi de dağıtılmış bir sanal makine içinde çalışır ve prosedür çağrılarının standart bir arabirimi vardır.

Geçiş parametreleri

Değer parametrelerinin iletilmesi basittir. Bu durumda, istemci saplaması, muhtemelen standart forma dönüşümler gerçekleştirerek (örneğin, bayt sırasını değiştirerek) parametre değerini ağ isteğine yerleştirir. Parametre verilerin değeri değil de adresi olduğunda, işaretçilerin geçtiği durum çok daha karmaşıktır. Bir istekte adres iletmek anlamsızdır, çünkü uzak prosedür tamamen farklı bir adres alanında yürütülür. En basit RPC çözümü, kesinlikle ciddi kısıtlamalar getirmesine rağmen, istemcilerin değer dışında parametreleri iletmesini engellemektir.

bağlama

Bir istemci bir uzak yordamı çağırmadan önce, gerekli sunucuyu barındıran uzak sisteme bağlanmalıdır. Böylece, bağlama görevi ikiye ayrılır:

İstenen Sunucuyla Uzak Ana Bilgisayarı Bulma

Belirli bir ana bilgisayarda gerekli sunucu işlemini bulma

Bir ana bilgisayar bulmak için çeşitli yaklaşımlar kullanılabilir. Olası bir seçenek, ana bilgisayarların sunucularını duyurduğu ve istemcinin istenirse kendisine uygun ana bilgisayar ve prosedür adresini seçebileceği bir tür merkezi dizin oluşturmaktır.

Her RPC prosedürü, bir program ve prosedür numarası ile benzersiz bir şekilde tanımlanır. Program numarası, her biri kendi numarasına sahip olan bir grup uzak prosedürü tanımlar. Her programa ayrıca bir sürüm numarası atanır, böylece programda küçük değişiklikler yapıldığında (örneğin, bir prosedür eklendiğinde), numarasının değiştirilmesine gerek kalmaz. Genellikle, işlevsel olarak benzer birkaç prosedür, başlatıldığında bu prosedürlerin sunucusu haline gelen ve program numarasıyla tanımlanan bir program modülünde uygulanır.

Bu nedenle, bir müşteri bir uzak prosedürü çağırmak istediğinde, gerekli hizmeti sağlayan programı, versiyonu ve prosedür numaralarını bilmesi gerekir.

İsteği iletmek için, istemcinin ayrıca, gerekli prosedürleri sağlayan sunucu programıyla ilişkili ana bilgisayarın ağ adresini ve bağlantı noktası numarasını bilmesi gerekir. Bu, portmap (IM) arka plan programı (bazı sistemlerde rpcbind (IM) olarak adlandırılır) kullanılarak yapılır. Daemon, uzaktan yordam hizmetleri sağlayan ve iyi bilinen bir bağlantı noktası numarası kullanan bir ana bilgisayarda çalışır. Bir sunucu işlemi başlatıldığında, rutinlerini ve port numaralarını portmap (IM) ile kaydeder. Şimdi, istemcinin belirli bir prosedürü çağırmak için bağlantı noktası numarasını bilmesi gerektiğinde, bağlantı noktası haritası (IM) sunucusuna bir istek gönderir, bu da bağlantı noktası numarasını döndürür veya isteği doğrudan RPC sunucusuna yönlendirir ve bir yürütüldüğünde müşteriye yanıt. Her durumda, eğer gerekli prosedür mevcutsa, istemci portmap (IM) sunucusundan prosedürün port numarasını alır ve doğrudan bu porta daha fazla istek yapılabilir.

İstisnaları işleme

Yerel prosedürleri çağırırken istisnaları ele almak özellikle sorunlu değildir. UNIX, sıfıra bölme, geçersiz bellek erişimleri vb. gibi işlem hatalarını işler.Uzak bir prosedürün çağrılması, hata durumlarının olasılığını artırır. Sunucuya eklenen ve saplama hataları, örneğin hatalı bir ağ mesajı almayla ilgili hatalardır.

Örneğin, taşıma protokolü olarak UDP kullanıldığında, mesajlar belirli bir zaman aşımından sonra yeniden iletilir. Belirli sayıda denemeden sonra sunucudan yanıt alınmazsa, istemciye bir hata döndürülür. TCP protokolünün kullanıldığı durumda, sunucu TCP bağlantısını sonlandırdıysa, istemciye bir hata döndürülür.

çağrı semantiği

Yerel bir prosedürün çağrılması, açık bir şekilde yürütülmesine yol açar, ardından kontrol ana programa döner. Uzak bir prosedür çağırırken durum farklıdır. Prosedürün tam olarak ne zaman uygulanacağını, uygulanıp uygulanmayacağını ve yapılacaksa kaç kez gerçekleştirileceğini belirlemek imkansızdır? Örneğin, sunucu programı anormal bir şekilde sonlandıktan sonra uzak sistem tarafından istek alınırsa, prosedür hiç yürütülmeyecektir. İstemci, belirli bir süre sonra (zaman aşımı) yanıt alamayınca talebi yeniden gönderirse, yanıtın ağ üzerinden iletilmekte olduğu bir durum ortaya çıkabilir ve tekrarlanan istek, tekrar işleme için kabul edilir. uzaktan prosedür. Bu durumda, prosedür birkaç kez gerçekleştirilecektir.

Böylece, bir uzak prosedürün yürütülmesi aşağıdaki anlambilim ile karakterize edilebilir:

- Bir ve sadece bir kez. Bu davranışın (bazı durumlarda en çok istenen) olası sunucu çökmeleri nedeniyle uygulanması zordur.

- Maksimum zamanlar. Bu, işlemin ya hiç yapılmadığı ya da yalnızca bir kez yapıldığı anlamına gelir. Normal bir yanıt yerine bir hata alındığında da benzer bir açıklama yapılabilir.

- En azından bir kere. Prosedür muhtemelen bir kez yapıldı, ancak daha fazlası mümkün. Böyle bir durumda normal çalışma için, uzak prosedürün idempotency (İngiliz idemponentinden) özelliğine sahip olması gerekir. Bu özellik, tekrarlanan yürütülmesi kümülatif değişikliklere neden olmayan bir prosedüre sahiptir. Örneğin, bir dosyayı okumak önemsizdir, ancak bir dosyaya metin eklemek değildir.

Veri sunumu

İstemci ve sunucu aynı bilgisayar üzerinde aynı sistem üzerinde çalıştığında veri uyumsuzluğu sorunu yaşanmaz. İkili veriler, hem istemci hem de sunucu için aynı şekilde temsil edilir. Uzak çağrı durumunda, istemci ve sunucunun farklı veri temsillerine sahip farklı mimarilere sahip sistemler üzerinde çalışabilmesi (örneğin, kayan nokta değeri gösterimi, bayt sıralaması vb.)

Çoğu RPC uygulaması, isteklerde ve yanıtlarda geçirilen tüm değerlerin dönüştürülmesi gereken bazı standart veri temsillerini tanımlar.

Örneğin, Sun Microsystems'in RPC'deki verileri temsil etme biçimi aşağıdaki gibidir:

Bayt Sırası - En Önemli - Son

Kayan Nokta Gösterimi - IEEE

Karakter gösterimi - ASCII

İşlevsellik açısından, RPC sistemi, uygulama katmanı ile taşıma katmanı arasında orta düzeydedir. OSI modeline göre bu hüküm sunum ve oturum katmanlarına karşılık gelmektedir. Bu nedenle, RPC teorik olarak ağ uygulamasından, özellikle taşıma katmanı ağ protokollerinden bağımsızdır.

Sistemin yazılım uygulamaları, kural olarak, bir veya iki protokolü destekler. Örneğin, Sun Microsystems'in RPC sistemi, TCP ve UDP protokollerini kullanarak mesajlaşmayı destekler. Bir veya başka bir protokolün seçimi, uygulamanın gereksinimlerine bağlıdır. UDP seçimi, aşağıdaki özelliklere sahip uygulamalar için doğrulanır:

Denilen prosedürler önemsizdir

Geçirilen bağımsız değişkenlerin boyutu ve döndürülen sonuç, UDP paketinin boyutundan daha küçüktür - 8 KB.

Sunucu, birkaç yüz istemciyle çalışma sağlar. TCP protokolleriyle çalışırken, sunucu aktif istemcilerin her biri ile bağlantı kurmaya zorlandığından, bu, kaynaklarının önemli bir bölümünü alır. UDP bu konuda daha az kaynak yoğundur.

Öte yandan TCP, aşağıdaki özelliklere sahip uygulamaların verimli çalışmasını sağlar:

Uygulama Güvenilir Aktarım Protokolü Gerektiriyor

Denilen Prosedürler Aynı Değil

Bağımsız değişkenler veya döndürülen sonuç 8 KB'den büyük

Protokol seçimi genellikle müşteriye aittir ve sistem mesajların oluşumunu ve iletimini farklı şekillerde düzenler. Bu nedenle, iletilen verilerin bir bayt akışı olduğu TCP protokolünü kullanırken, mesajları birbirinden ayırmak gerekir. Bu, örneğin, her mesajdan önce mesaj boyutunu bayt olarak belirten 32 bitlik bir tamsayı ile gelen RFC1057 "RPC: Uzaktan Yordam Çağrı Protokolü spesifikasyonu sürüm 2" kayıt etiketleme protokolü kullanılarak yapılabilir.

Çağrının semantiğinde durum farklıdır. Örneğin, güvenilir olmayan bir aktarım protokolü (UDP) kullanılarak RPC gerçekleştirilirse, sistem mesajı kısa aralıklarla (zaman aşımları) yeniden iletir. İstemci uygulaması bir yanıt almazsa, prosedürün sıfır veya daha fazla kez yürütüldüğünü söylemek güvenlidir. Bir yanıt alınmışsa, başvuru işlemin en az bir kez yürütüldüğü sonucuna varabilir. Güvenilir aktarım protokolü (TCP) ile bir yanıt alındığında işlemin bir kez gerçekleştirilmiş olduğu söylenebilir. Herhangi bir yanıt alınmazsa işlemin yapılmadığını kesin olarak söylemek mümkün değildir3.

Nasıl çalışır?

Esasen, gerçek RPC sistemi, istemci programında ve sunucu programında yerleşiktir. Dağıtılmış uygulamalar geliştirirken, RPC protokolünün veya program mesaj işlemenin ayrıntılarına girmenize gerek kalmaması sevindiricidir. Sistem, uygulama yazılımı yaratıcılarının yaşamını büyük ölçüde kolaylaştıran uygun bir geliştirme ortamının varlığını varsayar. RPC'deki kilit noktalardan biri, dağıtılmış bir uygulamanın geliştirilmesinin bir nesne arabiriminin tanımıyla başlamasıdır - sunucu işlevlerinin özel bir dilde yazılmış resmi bir açıklaması. İstemci ve sunucu saplamaları daha sonra bu arabirimden otomatik olarak oluşturulur. Bundan sonra yapılması gereken tek şey gerçek prosedür kodunu yazmaktır.

Örnek olarak, Sun Microsystems'in RPC'sini düşünün. Sistem üç ana bölümden oluşmaktadır:

Rpcgen (1), uzak yordam arabiriminin açıklamasına dayalı olarak C programları olarak istemci ve sunucu saplamaları oluşturan bir RPC derleyicisidir.

Çeşitli veri türlerini makineden bağımsız bir forma dönüştürmek için işlevler içeren ve heterojen sistemler arasında bilgi alışverişine olanak tanıyan XDR Kitaplığı (eXternal Data Representation).

Sistemin bir bütün olarak çalışmasını sağlayan modüllerden oluşan bir kütüphane.

Basit bir dağıtılmış olay günlüğü uygulaması örneğine bakalım. İstemci, başlangıçta, uzak bilgisayarın günlük dosyasına bir mesaj yazmak için uzak yordamı çağırır.

Bunu yapmak için en az üç dosya oluşturmanız gerekecektir: log.x uzak prosedürlerinin arayüzlerinin belirtimi (arayüz tanımlama dilinde), log.c uzak prosedürlerinin gerçek metni ve müşterinin ana programı main () - client.c (C dilinde).

rpcgen (l) derleyicisi, log.x belirtimine dayalı olarak üç dosya oluşturur: C istemcisi ve sunucu saplama metni (log clnt.c ve log svc.c) ve her iki saplama tarafından kullanılan log.h tanım dosyası.

Öyleyse, programların kaynak kodlarına bakalım.

Bu dosya, uzak prosedürün kayıt parametrelerini - program, sürüm ve prosedür numaraları - belirtir ve çağıran arabirimi - giriş argümanları ve dönüş değerlerini tanımlar. Böylece, argüman olarak bir dize alan (günlüğe yazılacak) RLOG prosedürü tanımlanır ve varsayılan olarak dönüş değeri, sipariş edilen işlemin başarısını veya başarısızlığını gösterir.

LOG_PROG programı (

sürüm LOG_VER (

int RLOG (dize) = 1;

) = 0x31234567;

rpcgen (l) derleyicisi, özellikle prosedürlerin tanımlandığı bir log.h başlık dosyası oluşturur:

günlük.h

* Lütfen bu dosyayı düzenlemeyin.

* rpcgen kullanılarak oluşturulmuştur.

#ifndef _LOG_H_RPCGEN

#define _LOG_H_RPCGEN

#Dahil etmek

/ * Program numarası * /

#define LOG_PROG ((işaretsiz uzun) (0x31234567))

#define LOG_VER ((işaretsiz uzun) (1)) / * Sürüm numarası * /

#define RLOG ((işaretsiz uzun) (1)) / * Rutin numarası * /

harici int * rlog_l();

/ * Dahili prosedür - onu kullanmamız gerekmeyecek * / extern int log_prog_l_freeresult ();

#endif / *! _LOG_H_RPCGEN * /

Bu dosyaya daha yakından bakalım. Derleyici, arabirim tanımlayıcısında belirtilen RLOG adını, büyük harfleri küçük harflerle değiştirerek ve program sürüm numarasını bir alt çizgi ile ekleyerek rlog_1'e çevirir. Dönüş türü int'den int *'ye değişti. Kural budur - RPC, arabirimi tanımlarken yalnızca bildirilen parametrelerin adreslerini göndermenize ve almanıza izin verir. Aynı kural, argüman olarak iletilen dize için de geçerlidir. Bu, print.h dosyasından gelmese de, aslında satırın adresi de rlog_l() işlevine bir argüman olarak iletilir.

Başlık dosyasına ek olarak, rpcgen (l) derleyicisi, istemci saplaması ve sunucu saplaması modülleri üretir. Esasen, bu dosyaların metni, uzak aramanın tüm kodunu içerir.

Sunucu saplaması, istemciyle (daha doğrusu saplaması ile) tüm ağ etkileşimini yöneten baş programdır. İşlemi gerçekleştirmek için sunucu saplaması, metninin yazılması gereken işleve yerel bir çağrı yapar:

log.c

#Dahil etmek

#include "log.h"

int * rlog_1 (char ** arg)

/ * Dönüş değeri statik olarak tanımlanmalıdır * /

statik int sonucu;

int fd; / * Günlük dosyası tanımlayıcısı * /

/ * 0 günlük dosyasını açın (mevcut değilse oluşturun), arıza durumunda hata kodunu döndürün == 1. * /

if ((fd = open ("./ server .log",

O_CREAT | O_RDWR | O_APPEND))< 0) return (&result);

len = strlen (* arg);

if (yaz (fd, * arg, strlen (* arg))! = len)

dönüş (& sonuç); / * Sonucu döndür - adres sonucu * /

İstemci saplaması, uzak prosedüre iletilen bir argüman alır, gerekli dönüşümleri yapar, portmap (1M) sunucusuna bir istek gönderir, uzak prosedür sunucusuyla iletişim kurar ve son olarak dönüş değerini istemciye iletir. İstemci için uzaktan prosedür çağrısı bir saplama çağrısıdır ve normal bir yerel çağrıdan farklı değildir.

müşteri.c

#Dahil etmek

#include "log.h"

ana (int argc, char * argv)

char * server, * mystring, * clnttime;

if (argc! = 2) (

fprintf (stderr, "Çağrı biçimi:% s Ana Bilgisayar_adresi \ n",

/ * İstemci tanımlayıcısını alın. Başarısızlık durumunda, sizi bilgilendireceğiz

sunucu ile bağlantı kurmanın imkansızlığı * /

if ((с1 = clnt_create (sunucu,

LOG_PROG, LOG_VER, "udp")) == BOŞ) (

clnt_pcreateerror (sunucu);

/ * Dize için bir arabellek ayırın * /

mystring = (char *) malloc (100);

/ * Etkinliğin zamanını belirle * /

bintime = zaman ((time_t *) NULL);

clnttime = ctime (& bintime);

sprintf (mystring, "% s - İstemci başlatıldı", clnttime);

/ * Günlük - istemcinin çalışmaya başladığı zaman için bir mesaj gönderelim. Arıza durumunda bir hata bildiririz * /

if ((sonuç = rlog_l (& mystring, cl)) == NULL) (

fprintf (stderr, "hata2 \ n");

clnt_perror (cl, sunucu);

/ * Uzak bilgisayarda arıza olması durumunda bir hata bildireceğiz * /

if (* sonuç! = 0)

fprintf (stderr, "Günlüğe yazma hatası \ n");

/ * 0 tanımlayıcıyı serbest bırak * /

cint yok et (cl);

İstemci saplaması log_clnt.c, istemcinin yürütülebilir dosyasını almak için client.c modülüyle derlenir.

cc -o rlog client.c log_clnt.c -Insl

log_svc.c sunucu saplaması ve log.c yordamı, sunucunun yürütülebilir dosyasını almak için derlenir.

cc -o kaydedici log_svc.c log.c -Insl

Şimdi bazı sunucularda server.nowhere.ru sunucu sürecini başlatmak gerekiyor:

Ardından, rlog istemcisi başka bir makinede başlatıldığında, sunucu günlük dosyasına karşılık gelen bir giriş ekleyecektir.

Bu durumda RPC işleminin şeması Şek. 1. Modüller aşağıdaki şekilde etkileşime girer:

1. Sunucu işlemi başladığında, bir UDP yuvası oluşturur ve herhangi bir yerel bağlantı noktasını bu yuvaya bağlar. Sunucu daha sonra program numaralarını ve sürüm numaralarını kaydetmek için svc_register (3N) kitaplık işlevini çağırır. Bunu yapmak için fonksiyon portmap (IM) işlemini çağırır ve gerekli değerleri iletir. Portmap (IM) sunucusu genellikle sistem başlatma sırasında başlatılır ve bazı iyi bilinen bağlantı noktalarına bağlanır. Portmap (3N) artık programımızın ve versiyonumuzun port numarasını biliyor. Sunucu isteği almayı bekliyor. Açıklanan tüm eylemlerin, rpcgen (IM) derleyicisi tarafından oluşturulan bir sunucu saplaması tarafından gerçekleştirildiğini unutmayın.

2. rlog başladığında, yaptığı ilk şey clnt_create (3N) kitaplık işlevini çağırarak ona uzak sistemin adresini, program ve sürüm numaralarını ve taşıma protokolünü vermektir. İşlev, uzak sistem server.nowhere.m'nin bağlantı noktası haritası (IM) sunucusuna bir istekte bulunur ve günlük sunucusu için uzak bağlantı noktası numarasını alır.

3. İstemci, istemci saplamasında tanımlanan rlog_1 () yordamını çağırır ve denetimi saplamaya aktarır. Bu da isteği (argümanları XDR formatına dönüştürerek) bir UDP paketi biçiminde oluşturur ve portmap (IM) sunucusundan alınan uzak bağlantı noktasına iletir. Ardından bir süre yanıt bekler ve alınmazsa isteği yeniden gönderir. Uygun koşullar altında, istek günlükçü sunucusu (sunucu saplama modülü) tarafından kabul edilir. Saplama, hangi işlevin (prosedür numarasına göre) çağrıldığını belirler ve log.c modülünün rlog_1 () işlevini çağırır. Kontrol saplamaya geri döndükten sonra saplama, rlog_1 () işlevi tarafından döndürülen değeri XDR biçimine dönüştürür ve yanıtı ayrıca bir UDP paketi biçiminde oluşturur. Yanıtı aldıktan sonra, istemci saplaması döndürülen değeri çıkarır, dönüştürür ve istemci ana bilgisayarına geri gönderir.

Windows işletim sistemindeki herhangi bir değişiklik, XP sürümünden başlayarak, RPC olarak belirlenmiş bir hizmet bileşenini içerir. Sıradan kullanıcıların çoğu ne olduğunu bilmiyor, ayrıca bu hizmetin ne için olduğunu ve nasıl çalıştığını bilmiyorlar. Bu bağlamda, gereksiz ve karmaşık teknik terimler açıklamadan, bileşenin kendisi, çalışma prensipleri ve kullanım alanı ile ilgili bazı temel hususların dikkate alınması önerilmektedir. Olası servis hataları ve bunların hızlı bir şekilde ortadan kaldırılması için yöntemler üzerinde ayrı ayrı duralım.

Uzak prosedürler (uzaktan prosedür çağrısı): nedir?

Görünüşe göre, bu hizmet bileşeninin adına dayanan birçok kullanıcı, bunun ne olduğu sonucuna varmıştır. Gerçekten de, uzak prosedürler (uzak prosedürler olarak adlandırılır), yerel bilgisayarda değil, uzak bilgisayarda (çoğunlukla sunucuda) yürütüldüklerinde bazı eylemleri ifade eder.

Yani, istek bir terminalde oluşturulur, daha sonra yürütüldüğü diğerine aktarılır, ardından yürütmeye ilişkin bir yanıt (rapor) ilk bilgisayara döndürülür. Ama bu sadece ilkel bir açıklama. Aslında, her şey çok daha karmaşık, çünkü burada veri aktarım protokollerini (UDP, TCP, HTTP) ve diğer birçok mekanizmayı hesaba katmanız gerekiyor.

Bu hizmet ne için?

Asıl amacına rağmen, RPC RPC farklı bilgisayarlar yerine tek bir bilgisayarda kullanılabilir. En basit örnek, bir programın işlevini başka bir uygulamadan çağırmaktır. Sanal stüdyolar ve sıralayıcılarla çalışan birçok müzisyen, bu tür her bir uygulamanın, her zaman kullanıcının gereksinimlerini karşılamayan kendi ses düzenleme veya işleme modülüne sahip olduğunu bilir. Ve herhangi bir stüdyo, bunun yerine başka herhangi bir harici programı bağlamanıza izin verir.

Örneğin, FL Studio sıralayıcının ayarlarında, ana program ortamında ses dosyalarını (örnekleri) düzenlemek için varsayılan olarak kullanılacak başka bir uygulama (örneğin, Adobe Audition) belirtebilirsiniz. Aynı zamanda, Adobe Audition'ın FL Studio'ya bağlantısı VST, RTAS veya DX gibi sanal ana bilgisayarlar aracılığıyla değil, doğrudan RPC hizmetinin kullanımı yoluyla gerçekleştirilecektir. Açıklanan bileşenin kapsamı çok daha geniş olduğu için bu örneğin tek olmadığını söylemeye gerek yok.

Çoğu zaman bu hizmet, aralarında etkileşimli bir bağlantının kurulduğu terminaller üzerindeki bilgi işlem yükünün dağılımı ile de ilişkilidir. Aynı zamanda, birkaç bilgisayarın bilgi işlem kaynakları üzerindeki yük eşit olarak dağıtılırsa, maksimum performans ancak küçük miktarlarda veri alışverişi yapıldığında ve bileşenler arasında hızlı yanıt verildiğinde elde edilebilir.

Uzaktan Yordam Çağrısı Hatası: Nedeni Nedir?

Ne yazık ki, bu talep nedeniyle, bu hizmetle ilgili arıza ve hataların ortaya çıkması oldukça yaygın bir durumdur.

Sonuç olarak, yalnızca bileşenin kendisini kullanmak imkansız hale gelir. Bazen bazı sistem ayarlarına erişmek bile mümkün değildir ve Windows XP sadece çöker, ardından normal çalışma durumuna geri yüklemek oldukça sorunlu olabilir. Başka bir sorun, işletim sistemiyle birlikte verilen çevrimiçi DISM onarım aracıdır.

Çalışmasındaki ihlallerle, RPC hizmetinin bileşenlerinin işleyişini doğrudan etkileyen 1726 hatasının ortaya çıkmasıyla ilişkilidir.

Bu tür hataların ana nedenleri, DISM işlemi etkinken veya düzgün bir şekilde kapatılamadığında (örneğin, DISM ve SFC araçları aynı anda iki komut konsolundan başlatıldığında) bir sistem denetleyicisinin veya sistem geri yüklemesinin çağrılması olarak adlandırılır; hizmet, RPC bileşenlerinin bakımıyla paralel olarak çalıştığında; hizmet virüsten koruma yazılımı tarafından engellendiğinde.

Bu nedenle, Windows 7 ve üzeri sürümlerde RPC başarısız olursa, yapılacak ilk şey DISM'den çıkmak, bilgisayarınızı yeniden başlatmak ve hizmeti yeniden başlatmaktır. Bu işe yaramazsa, kurtarma süresi boyunca güvenli moda geçmeyi ve virüsten koruma korumasını tamamen devre dışı bırakmayı deneyebilirsiniz. Uzaktan yordam çağrısı sırasında ve herhangi bir Windows değişikliği sırasında herhangi bir arızayı düzeltmeye yardımcı olacak ek önlemler üzerinde duracağız. Bu arada bu sistem bileşeninin devre dışı bırakılmasıyla ilgili sorunlara bir bakalım (ne yazık ki, sorunun özünü bilmeyen birçok kullanıcı tam da böyle şeyler yapmaya çalışıyor).

RPC hizmetini devre dışı bırakabilir miyim?

Öyleyse, RPC'yi devre dışı bırakmanın ne kadar gerçekçi olduğunu görelim. Geliştiricilerin tavsiyelerine dayanan uzaktan prosedürler hiçbir koşulda devre dışı bırakılmamalıdır. Bu önemli! Prensip olarak, kendisi buna izin vermeyecek. Elbette, ek yazılım kullanımını içeren bazı geçici çözümler vardır, ancak bariz nedenlerden dolayı bu tür uygulamaların adları verilmez, çünkü yanlış kullanılırlarsa tüm sistem kullanılamaz hale gelebilir.

RPC İşlemlerini Devre Dışı Bırakmanın Sonuçları

Kullanıcı uzak prosedürleri (uzaktan prosedür çağrıları) bir şekilde devre dışı bırakmayı başarsa bile, sonuçlar ne yazık ki çok tahmin edilemez olabilir. Daha önce de belirtildiği gibi, Windows XP tamamen çalışmayı durdurabilir ve sonuç olarak, yalnızca kritik Windows ayarlarına erişimin olmaması nedeniyle ortadan kaldırılamayan çok sayıda sistem hatası ortaya çıkabilir. ve parametreler, ayrıca güvenli modda veya çıkarılabilir ortamdan başlatılırken bile. Ancak, Windows 10 veya önceki işletim sistemlerinde RPC'leri çağırırken bir kilitlenmeyi düzeltebilirsiniz. Yöntem en kolayı değil, bu yüzden kullanırken çok dikkatli olmanız gerekiyor.

Uzaktan Erişim Bulucuyu Devre Dışı Bırak

Bu nedenle, ana RPC hizmeti devre dışı bırakılamaz. Ancak, beraberindeki bazı bileşenlerini devre dışı bırakmak mantıklı olabilir mi? Evet, gerçekten, sistem hizmetleri ve bileşenleri (services.msc) bölümüne giderseniz, sözde RPC bulucuyu burada bulabilirsiniz.

Ancak felaket sonuçlarından korkmadan devre dışı bırakılabilir. Parametrelerinin düzenlenmesini girdikten sonra, bileşeni durdurmanız ve başlatma türünü devre dışı olarak ayarlamanız gerekir. Uzak prosedürleri kullanabilen programlar, yine de (yardımı olmadan) bir uzaktan prosedür çağrısı yapacaktır.

Herhangi bir nedenle ayarlanan parametreler çalışmazsa, Windows yükleme diskini kullanarak önyükleme yaparken komut satırını çağırın ve aşağıdakileri girin:

cd X: \ i386 (X, çıkarılabilir sürücünün harfidir);
explorer.ex_% TEMP% \ explorer.exe'yi genişletin;
svchost.ex_% TEMP% \ svchost.exe dosyasını genişletin.

Yeniden başlattıktan sonra, "Görev Yöneticisi" çağrılır ve komut satırına kopyala% TEMP% \ explorer.exe% SYSTEMROOT% / y kombinasyonu biter, bundan sonra kesinlikle tüm svchost işlemleri "Görevde sonlandırılır. Yönetici". Şimdi özellikle dikkatli olmalısınız, çünkü işlemleri komut konsolunda yalnızca altmış saniye içinde tamamladıktan sonra copy% TEMP% \ svchost.exe% systemroot% \ system32 / y komutunu yazmak için zamanınız olması gerekir.

Bir kullanıcının, örneğin normal veya güvenli modda, sistem kayıt defterine erişimi varsa, HKCC şubesindeki düzenleyicide (regedit) CSConfigFlags parametresini bulun ve ona sıfır değeri atayın.

1726 kilitlenme sorunlarını giderme

Son olarak, 1726 hatası için sorun giderme de kayıt defteri aracılığıyla yapılır. Ancak bu durumda, HKLM dalında RpcSs dizinini bulmanız ve sağda Start parametresinin değerini düzenlemeniz gerekir.

Genellikle varsayılan olarak ayarlanan dörtten ikiye değiştirilmesi ve ardından sistemi yeniden başlatması gerekir.

son söz

RPC çağrılarının hepsi bu kadar. Uzak prosedürler, bu bileşenin genişletilmiş bir versiyonda çalışma prensipleri çok uzun bir süre açıklanabilir, ancak sunulan materyaldeki vurgu, hizmetle genel bir aşinalık ve yapabileceği hataları ve arızaları ortadan kaldırmak için bazı yöntemler üzerinde yapılmıştır. bir bilgisayar sisteminde neden olur. Sıradan kullanıcılar sabırlı olmalı ve çok dikkatli olmalıdır, çünkü kayıt defterindeki bir yanlış işlem işletim sisteminin tamamen çökmesine neden olabilir.

Lütfen bu tür çökmelerin, optimize ediciler ve Windows işletim sistemi ayar düzenleyicileri gibi başka yollarla ele alınmadığını unutmayın. Tüm arzu ile, ne komut satırı, ne de dahası, bu tür yazılım paketlerinde düzenleme anahtarları düzeyinde kayıt defterine müdahale sağlanmaz.

ders 4

4.1 Uzaktan Yordam Çağrısı Kavramı

Uzak prosedürleri çağırmanın ardındaki fikir (Uzaktan Prosedür Çağrısı - RPC) Kontrol ve verileri bir ağ üzerinden aktarmak için bir makinede çalışan bir program içinde kontrol ve veri aktarımı için iyi bilinen ve iyi anlaşılan mekanizmanın genişletilmesinden oluşur. Uzaktan prosedür çağrısı olanakları, dağıtılmış bilgi işlemin organizasyonunu kolaylaştırmak için tasarlanmıştır. RPC'nin en etkin kullanımı, uzak bileşenler arasında kısa yanıt süreleri ve nispeten az veri aktarımı ile etkileşimli iletişimin olduğu uygulamalarda elde edilir. Bu tür uygulamalara RPC odaklı denir.

Yerel prosedürlere çağrının karakteristik özellikleri şunlardır: asimetri, yani etkileşimde bulunan taraflardan biri başlatıcıdır; eşzamanlılık, yani, talebin verildiği andan itibaren durduğunda çağıran prosedürün yürütülmesi ve yalnızca çağrılan prosedürden döndükten sonra devam ettirilmesi.

Uzak çağrıları uygulamak, yerel prosedür çağrılarını uygulamaktan çok daha karmaşıktır. Başlangıç olarak, arayan ve aranan farklı makinelerde yürütüldüğünden, farklı adres alanlarına sahiptirler ve bu, özellikle makineler aynı değilse, parametreleri ve sonuçları geçerken sorun yaratır. RPC, paylaşılan belleğe güvenemeyeceğinden, bu, RPC parametrelerinin yığın olmayan bellek konumlarına işaretçiler içermemesi ve bu parametre değerlerinin bir bilgisayardan diğerine kopyalanması gerektiği anlamına gelir. RPC ve yerel çağrı arasındaki bir sonraki fark, mutlaka temel alınan iletişim sistemini kullanmasıdır, ancak bu, prosedürlerin tanımında veya prosedürlerin kendisinde açıkça görülmemelidir. Uzaklık ek sorunları beraberinde getirir. Çağıran programın ve çağrılan yerel prosedürün aynı makinede yürütülmesi tek bir işlemde yapılır. Ancak RPC uygulamasında yer alan en az iki süreç vardır - her makinede bir tane. Bunlardan biri çökerse, aşağıdaki durumlar ortaya çıkabilir: Çağırma prosedürü çökerse, uzaktan aranan prosedürler "yetim kalır" ve uzaktan prosedürler anormal bir şekilde sona ererse, arayanlar, arayanların "yoksun ebeveynleri" olur. uzak prosedürlerden bir yanıt beklemek boşuna.

Ek olarak, programlama dillerinin ve işletim ortamlarının heterojenliği ile ilgili bir takım sorunlar vardır: herhangi bir programlama dilinde desteklenen veri yapıları ve prosedür çağrısı yapıları, diğer tüm dillerde aynı şekilde desteklenmez.

Bu ve diğer bazı sorunlar, birçok dağıtık işletim sisteminin altında yatan yaygın RPC teknolojisi tarafından çözülür.

Temel RPC İşlemleri

RPC'nin nasıl çalıştığını anlamak için önce özerk olarak çalışan geleneksel bir makinede yerel bir prosedür çağrısı yürütmeyi düşünün. Örneğin, bir sistem çağrısı olsun

say = oku (fd, buf, nbytes);

fd bir tamsayıdır;

buf - karakter dizisi;

nbytes bir tamsayıdır.

Aramayı yapmak için, arama prosedürü parametreleri ters sırada yığına iter. Okuma çağrısı yürütüldükten sonra, dönüş değerini bir kayıt defterine yerleştirir, dönüş adresini ilerletir ve kontrolü, parametreleri yığından çıkararak orijinal durumuna döndüren arama prosedürüne döndürür. C'de parametrelerin referansla (ada göre) veya değerle (değere göre) çağrılabileceğini unutmayın. Çağrılan prosedüre göre, değer parametreleri başlatılabilir yerel değişkenlerdir. Çağrılan prosedür, çağrı prosedüründeki bu değişkenlerin orijinallerinin değerini etkilemeden bunları değiştirebilir.

Çağrılan prosedüre bir değişkene işaretçi iletilirse, çağrılan prosedür tarafından bu değişkenin değerini değiştirmek, bu değişkenin değerini çağıran prosedür için de değiştirecektir. Bu gerçek RPC için gereklidir.

Parametreleri geçirmek için C dilinde kullanılmayan başka bir mekanizma daha vardır.Call-by-copy/restore olarak adlandırılır ve çağıran programın değişkenleri yığına değerler olarak kopyalaması ve sonra tekrar kopyalaması gerekliliğinden oluşur. arama, arama prosedürünün orijinal değerleri üzerinden yapılır.

Hangi parametre geçiş mekanizmasının kullanılacağına karar vermek dil tasarımcılarına kalmıştır. Bazen aktarılan verinin türüne bağlıdır. Örneğin, C'de tamsayı ve diğer skaler veriler her zaman değere göre iletilir ve diziler her zaman referansa göre iletilir.

RPC'nin arkasındaki fikir, uzak bir prosedür çağrısının yerel bir prosedür çağrısına mümkün olduğunca yakın görünmesini sağlamaktır. Başka bir deyişle, RPC'yi şeffaf yapın: arayanın, çağrılan prosedürün farklı bir makinede olduğunu bilmesine gerek yoktur ve bunun tersi de geçerlidir.

RPC, şeffaflığı şu şekilde elde eder. Çağrılan yordam gerçekten uzak olduğunda, yerel yordam yerine, yordamın istemci saplaması (saplama) adı verilen başka bir sürümü kitaplığa yerleştirilir. Orijinal prosedürde olduğu gibi, stub, çağrı dizisi kullanılarak çağrılır ve çekirdeğe erişirken bir kesme meydana gelir. Yalnızca, orijinal prosedürün aksine, parametreleri kayıtlara koymaz ve çekirdekten veri istemez, bunun yerine uzak makinenin çekirdeğine göndermek için bir mesaj oluşturur.

RPC adımları

Bir uzaktan prosedür çağrısı gerçekleştirirken yazılım bileşenlerinin etkileşimi Şekil 2'de gösterilmektedir.

Şekil 2. Uzaktan Yordam Çağrısı

İstemci saplaması istemci programı tarafından çağrıldıktan sonra, ilk görevi arabelleği gönderilen mesajla doldurmaktır. Bazı sistemlerde, istemci saplaması, her yeni istek geldiğinde baştan doldurulan tek, sabit uzunluklu bir arabelleğe sahiptir. Diğer sistemlerde, bir mesaj arabelleği, bireysel mesaj alanları için bir arabellek havuzudur, bu arabelleklerin bazıları zaten dolu. Bu yöntem özellikle paket çok sayıda alanla biçimlendirildiğinde kullanışlıdır, ancak bu alanların birçoğunun değerleri çağrıdan çağrıya değişmez.

Parametreler daha sonra uygun biçime dönüştürülmeli ve mesaj arabelleğine eklenmelidir. Bu noktada mesaj gönderilmeye hazırdır, bu nedenle çekirdek çağrısında bir kesme gerçekleştirilir.

Çekirdek kontrolü ele geçirdiğinde, bağlamları değiştirir, işlemci kayıtlarını ve bir bellek haritasını (sayfa tanımlayıcıları) kaydeder ve çekirdek modunda çalışmak için kullanılacak yeni bir bellek haritası yükler. Çekirdek ve kullanıcı bağlamları farklı olduğundan, çekirdeğin mesajı tam olarak kendi adres alanına kopyalaması gerekir, böylece ona erişebilir, hedef adresi (ve muhtemelen diğer başlık alanlarını) hatırlayabilir ve ayrıca iletiyi alıcıya iletmelidir. ağ Arayüzü. Bu, istemci tarafındaki işi tamamlar. İletim zamanlayıcısı etkinleştirilir ve çekirdek, bir yanıt için döngüsel olarak yoklayabilir veya denetimi, yürütülecek başka bir işlemi seçen bir zamanlayıcıya iletebilir. İlk durumda, sorgu yürütmesi hızlandırılır, ancak çoklu programlama yoktur.

Sunucu tarafında, gelen bitler, alıcı donanım tarafından yerleşik bir arabelleğe veya RAM'e yerleştirilir. Tüm bilgiler alındığında, bir kesme oluşturulur. Kesme işleyicisi, paket verilerinin doğruluğunu doğrular ve hangi saplamanın iletilmesi gerektiğini belirler. Saplamalardan hiçbiri bu paketi beklemiyorsa, işleyici onu ya bir arabelleğe yerleştirmeli ya da tamamen atmalıdır. Bekleyen bir saplama varsa, mesaj ona kopyalanır. Son olarak, kayıtların ve hafıza haritasının geri yüklendiği ve saplamanın alma çağrısını yaptığı anda sahip oldukları değerleri alarak bir bağlam anahtarı gerçekleştirilir.

Artık sunucu saplaması çalışmaya başlar. Parametreleri paketinden çıkarır ve uygun şekilde yığına iter. Her şey hazır olduğunda, bir sunucu çağrısı yapılır. Prosedürü tamamladıktan sonra sunucu sonuçları istemciye gönderir. Bunun için yukarıda açıklanan tüm adımlar sadece ters sırada gerçekleştirilir.

Şekil 3, her RPC çağrısı için yürütülmesi gereken komutların sırasını gösterir.

Şekil 3. RPC Prosedürünün Aşamaları

RPC kullanmanın en büyük verimliliği, mevcut olduğu uygulamalarda elde edilir. uzak bileşenler arasında etkileşimli iletişimİle kısa tepki süresi ve nispeten az miktarda iletilen veri.Bu tür uygulamalara RPC odaklı denir.

Yerel prosedür çağrıları aşağıdakilerle karakterize edilir:

asimetri, yani, etkileşimde bulunan taraflardan biri başlatıcıdır;

eşzamanlılık yani, çağrı prosedürünün yürütülmesi, talebin verildiği andan itibaren askıya alınır ve ancak çağrılan prosedür geri döndükten sonra devam ettirilir.

Uzak çağrıları uygulamak, yerel prosedür çağrılarını uygulamaktan çok daha karmaşıktır.

1. Çağırma ve çağrılma prosedürleri farklı makinelerde yürütüldüğünden başlayalım. farklı adres alanlarına sahip olmak ve bu yaratır özellikle makineler aynı değilse, parametrelerin ve sonuçların aktarılmasında sorunlar.

RPC, paylaşılan belleğe güvenemeyeceğinden, bunun anlamı şudur: RPC parametreleri, yığın olmayan bellek konumlarına işaretçiler içermemelidir Ve ne parametre değerleri bir bilgisayardan diğerine kopyalanmalıdır.

2. RPC ile yerel arama arasındaki bir sonraki fark, mutlaka temel iletişim sistemini kullanır ama, bu prosedürlerin tanımında veya prosedürlerin kendisinde açıkça görünmemelidir. .

Uzaklık ek sorunları beraberinde getirir. Çağıran programı ve çağrılan yerel prosedürü aynı makinede yürütmek içinde uygulananBir tek işlem... Fakat RPC uygulamasına dahilen az iki süreç - her arabada bir tane... Bunlardan biri çökerse, aşağıdaki durumlar ortaya çıkabilir:

çağıran prosedür çökerse, uzaktan çağrılan prosedürler "yetim kalır" ve

uzak prosedürlerin anormal şekilde sonlandırılması, arayanları "dezavantajlı ebeveynler" yapacak ve uzak prosedürlerden bir yanıt bekleyecek ve sonuç alınmayacaktır.

Ayrıca, var programlama dillerinin ve işletim ortamlarının heterojenliği ile ilgili bir takım problemler : Herhangi bir programlama dilinde desteklenen veri yapıları ve prosedür çağrısı yapıları diğer tüm dillerde aynı şekilde desteklenmez.

Bu ve diğer bazı sorunlar, birçok dağıtık işletim sisteminin altında yatan yaygın RPC teknolojisi tarafından çözülür.

RPC'nin arkasındaki fikir, uzak bir prosedür çağrısının yerel bir prosedür çağrısına mümkün olduğunca yakın görünmesini sağlamaktır. Başka bir deyişle, RPC'yi şeffaf yapın: arayanın, çağrılan prosedürün farklı bir makinede olduğunu bilmesine gerek yoktur ve bunun tersi de geçerlidir.

RPC, şeffaflığı şu şekilde elde eder. Çağrılan yordam gerçekten uzak olduğunda, yerel yordam yerine, yordamın istemci saplaması (saplama) adı verilen başka bir sürümü kitaplığa yerleştirilir. Orijinal prosedür gibi, stub çağrı dizisi kullanılarak çağrılır (Şekil 3.1'deki gibi) ve çekirdeğe erişilirken bir kesme meydana gelir. Yalnızca orijinal prosedürden farklı olarak, parametreleri kayıtlara koymaz ve çekirdekten veri istemez, bunun yerine uzak makinenin çekirdeğine göndermek için bir mesaj oluşturur..

Pirinç... 3.2. Uzaktan prosedür çağrısı

Uzaktan Yordam Çağrısı (RPC) Uzaktan Yordam Çağrısı Konsepti

Uzaktan Yordam Çağrısının (RPC) arkasındaki fikir, kontrolü ve verileri bir ağ üzerinden aktarmak için tek bir makine üzerinde çalışan bir program içinde kontrol ve veri aktarımı için iyi bilinen ve iyi anlaşılmış mekanizmayı genişletmektir. Uzaktan prosedür çağrısı olanakları, dağıtılmış bilgi işlemin organizasyonunu kolaylaştırmak için tasarlanmıştır. RPC'nin en etkin kullanımı, uzak bileşenler arasında kısa yanıt süreleri ve nispeten az veri aktarımı ile etkileşimli iletişimin olduğu uygulamalarda elde edilir. Bu tür uygulamalara RPC odaklı denir.

Yerel prosedür çağrıları aşağıdakilerle karakterize edilir:

Asimetri, yani etkileşimde bulunan taraflardan biri başlatıcıdır; Eşzamanlılık, yani, çağrı yapıldığı andan itibaren durdurulduğunda çağrı prosedürünün yürütülmesi ve yalnızca çağrılan prosedürden döndükten sonra devam etmesi.

Bu ve diğer bazı sorunlar, birçok dağıtık işletim sisteminin altında yatan yaygın RPC teknolojisi tarafından çözülür.

Temel RPC İşlemleri

RPC'nin nasıl çalıştığını anlamak için önce özerk olarak çalışan geleneksel bir makinede yerel bir prosedür çağrısı yürütmeyi düşünün. Örneğin, bir sistem çağrısı olsun

Say = oku (fd, buf, nbytes);

fd bir tam sayıdır,
buf bir dizi karakterdir,
nbytes bir tamsayıdır.

Aramayı yapmak için, arama prosedürü parametreleri ters sırada yığına iter (Şekil 3.1). Okuma çağrısı yürütüldükten sonra, dönüş değerini bir kayıt defterine yerleştirir, dönüş adresini ilerletir ve kontrolü, parametreleri yığından çıkararak orijinal durumuna döndüren arama prosedürüne döndürür. C'de parametrelerin referansla (ada göre) veya değerle (değere göre) çağrılabileceğini unutmayın. Çağrılan prosedüre göre, değer parametreleri başlatılabilir yerel değişkenlerdir. Çağrılan prosedür, çağrı prosedüründeki bu değişkenlerin orijinallerinin değerini etkilemeden bunları değiştirebilir.

Pirinç. 3.1. a) Okuma çağrısı yapılmadan önceki yığın;
b) İşlemin yürütülmesi sırasında yığın;
c) Çağıran programa döndükten sonra yığın

RPC, şeffaflığı şu şekilde elde eder. Çağrılan yordam gerçekten uzak olduğunda, yerel yordam yerine, yordamın istemci saplaması (saplama) adı verilen başka bir sürümü kitaplığa yerleştirilir. Orijinal prosedür gibi, stub çağrı dizisi kullanılarak çağrılır (Şekil 3.1'deki gibi) ve çekirdeğe erişilirken bir kesme meydana gelir. Yalnızca, orijinal prosedürün aksine, parametreleri kayıtlara koymaz ve çekirdekten veri istemez, bunun yerine uzak makinenin çekirdeğine göndermek için bir mesaj oluşturur.

RPC adımları

Bir uzaktan prosedür çağrısının yürütülmesi sırasında yazılım bileşenlerinin etkileşimi Şekil 3.2'de gösterilmektedir. İstemci saplaması istemci programı tarafından çağrıldıktan sonra, ilk görevi arabelleği gönderilen mesajla doldurmaktır. Bazı sistemlerde, istemci saplaması, her yeni istek geldiğinde baştan doldurulan tek, sabit uzunluklu bir arabelleğe sahiptir. Diğer sistemlerde, bir mesaj arabelleği, bireysel mesaj alanları için bir arabellek havuzudur, bu arabelleklerin bazıları zaten dolu. Bu yöntem özellikle paket çok sayıda alanla biçimlendirildiğinde kullanışlıdır, ancak bu alanların birçoğunun değerleri çağrıdan çağrıya değişmez.

Pirinç. 3.2. Uzaktan prosedür çağrısı

Sunucu tarafında, gelen bitler, alıcı donanım tarafından yerleşik bir arabelleğe veya RAM'e yerleştirilir. Tüm bilgiler alındığında, bir kesme oluşturulur. Kesme işleyicisi, paket verilerinin doğruluğunu doğrular ve hangi saplamanın iletilmesi gerektiğini belirler. Saplamalardan hiçbiri bu paketi beklemiyorsa, işleyici onu arabelleğe almalı veya tamamen atmalıdır. Bekleyen bir saplama varsa, mesaj ona kopyalanır. Son olarak, kayıtların ve hafıza haritasının geri yüklendiği ve saplamanın alma çağrısını yaptığı anda sahip oldukları değerleri alarak bir bağlam anahtarı gerçekleştirilir.

Şekil 3.3, her RPC çağrısı için yürütülmesi gereken komutların sırasını gösterir ve Şekil 3.4, açıklanan 14 aşamanın her birinin yürütülmesi için toplam RPC yürütme süresinin ne kadarının harcandığını gösterir. Araştırma, DEC Firefly çok işlemcili bir iş istasyonunda gerçekleştirilmiştir ve beş işlemcinin varlığı ölçüm sonuçlarını mutlaka etkilemiş olsa da, şekilde gösterilen histogram, RPC yürütme sürecine genel bir bakış sağlar.

Pirinç. 3.3. RPC Prosedür Adımları

Pirinç. 3.4. 14 RPC Çalıştırması Arasında Süre Ayırma

1. Çağrı saplaması

2. Tamponu hazırlayın

3. Paket parametreleri

4. Başlık alanını doldurun

5. Mesajdaki sağlama toplamını hesaplayın

6. Çekirdeğe kesinti

7. Yürütme için paket kuyruğu

8. QBUS aracılığıyla kontrolöre mesaj gönderme

9. Ethernet iletim süresi

10. Denetleyiciden bir paket alın

11. Kesinti işleme prosedürü

12. Sağlama toplamının hesaplanması

13. Bağlamı kullanıcı alanına çevirme

14. Bir sunucu saplaması yürütme

Dinamik bağlantı

İstemcinin sunucu konumunu nasıl belirlediği sorusunu düşünün. Bu sorunu çözmenin bir yöntemi, istemci programında sunucunun ağ adresini doğrudan kullanmaktır. Bu yaklaşımın dezavantajı aşırı esnek olmamasıdır: sunucu taşındığında veya sunucu sayısı artırıldığında veya arayüz değiştirildiğinde, tüm bu ve diğer birçok durumda, kullanılan tüm programları yeniden derlemek gerekir. sunucu adresinin zor atanması. Tüm bu sorunlardan kaçınmak için bazı dağıtık sistemler dinamik bağlantı denilen şeyi kullanır.

Dinamik bağlamanın başlangıç noktası, sunucunun resmi tanımıdır (belirtimidir). Belirtim, dosya sunucusunun adını, sürüm numarasını ve bu sunucu tarafından istemciler için sağlanan hizmet prosedürlerinin bir listesini içerir (Şekil 3.5). Her prosedür için, bu parametrenin sunucuya göre girdi mi yoksa çıktı mı olduğunu gösteren parametrelerinin bir açıklaması verilir. Bazı parametreler aynı anda girdi ve çıktı olabilir - örneğin, istemci tarafından sunucuya gönderilen, orada değiştirilen ve daha sonra istemciye geri döndürülen bazı diziler (kopyalama / geri yükleme işlemi).

Pirinç. 3.5. RPC Sunucu Spesifikasyonu

Resmi sunucu belirtimi, hem istemci hem de sunucu saplamaları oluşturan bir saplama oluşturucu programına girdi olarak kullanılır. Daha sonra uygun kütüphanelere yerleştirilirler. Kullanıcı (istemci) programı, sunucu belirtiminde tanımlanan herhangi bir prosedürü çağırdığında, ilgili saplama prosedürü, program ikili dosyasıyla ilişkilendirilir. Benzer şekilde, bir sunucu derlendiğinde, sunucu saplamaları onunla ilişkilendirilir.

Sunucu başlatıldığında, ilk eylemi, sunucu arayüzünü bağlayıcı adı verilen özel bir programa teslim etmektir.Sunucu kayıt işlemi olarak bilinen bu işlem, sunucunun adını, sürüm numarasını, benzersiz tanımlayıcısını ve tanımlayıcısını göndermesini içerir. sunucunun konumu Tanımlayıcı sistemden bağımsızdır ve bir IP, Ethernet, X.500 veya başka bir adres olabilir ve ayrıca kimlik doğrulama gibi başka bilgileri de içerebilir.

İstemci, örneğin okuma gibi uzak prosedürlerden birini ilk kez çağırdığında, istemci saplaması henüz sunucuya bağlı olmadığını görür ve bağlayıcı programa doğru sürümün arabirimini içe aktarmasını isteyen bir mesaj gönderir. gerekli sunucunun Böyle bir sunucu varsa, bağlayıcı, istemci saplamasına bir tanıtıcı ve benzersiz bir tanımlayıcı iletir.

İstemci saplaması, bir istek mesajı gönderirken adres olarak bir tanımlayıcı kullanır. Mesaj, bu makinede birkaç tane varsa, gelen mesajı doğru sunucuya iletmek için sunucu çekirdeğinin kullandığı parametreleri ve benzersiz bir tanımlayıcıyı içerir.

Bu arayüzleri içe/dışa aktarma yöntemi çok esnektir. Örneğin, aynı arayüzü destekleyen birden fazla sunucu olabilir ve istemciler sunucular arasında rastgele dağıtılır. Bu yöntem çerçevesinde, sunucuları periyodik olarak sorgulamak, performanslarını analiz etmek ve arıza durumunda sistemin genel hata toleransını artıran otomatik kapatma yapmak mümkün hale gelir. Bu yöntem ayrıca istemci kimlik doğrulamasını da destekleyebilir. Örneğin, bir sunucu yalnızca belirli bir listedeki istemciler tarafından kullanılabileceğini belirleyebilir.

Bununla birlikte, dinamik bağlantının, arayüzleri dışa ve içe aktarmanın ek yükü (zaman) gibi dezavantajları vardır. Bu maliyetlerin büyüklüğü önemli olabilir, çünkü birçok istemci süreci kısa bir süre için mevcuttur ve sürecin her başlangıcında, arayüz içe aktarma prosedürü tekrar gerçekleştirilmelidir. Ek olarak, büyük dağıtılmış sistemlerde, bağlayıcı programı bir darboğaz haline gelebilir ve benzer bir amaca yönelik birden çok program oluşturmak, aynı zamanda, oluşturma ve senkronizasyon süreçlerinin ek yükünü de arttırır.

Başarısızlıkta RPC semantiği

İdeal olarak, bir arıza durumunda RPC doğru şekilde çalışmalıdır. Aşağıdaki başarısızlık sınıflarını göz önünde bulundurun:

İstemci, örneğin gerekli sunucu başarısız olursa veya istemci programı uzun zaman önce derlendiğinden ve sunucu arabiriminin eski bir sürümünü kullandığından, sunucunun konumunu belirleyemez. Bu durumda, müşterinin isteğine yanıt olarak bir hata kodu içeren bir mesaj alınır. İstemciden sunucuya istek kayboldu. En basit çözüm, belirli bir süre sonra isteği tekrarlamaktır. Sunucudan istemciye kayıp yanıt mesajı. Bu seçenek, bazı prosedürler yetersiz olmadığı için öncekinden daha karmaşıktır. İdempotent bir prosedür, yürütme talebi birkaç kez tekrarlanabilen ve sonucu değişmeyecek bir prosedürdür. Böyle bir prosedürün bir örneği, bir dosyayı okumaktır. Ancak bir banka hesabından belirli bir miktarı çekme prosedürü önemsiz değildir ve cevap kaybolursa, tekrarlanan bir talep müşterinin hesabının durumunu önemli ölçüde değiştirebilir. Olası çözümlerden biri, tüm prosedürleri bağımsız bir forma getirmektir. Bununla birlikte, pratikte bu her zaman mümkün değildir, bu nedenle başka bir yöntem kullanılabilir - tüm isteklerin istemci çekirdeği tarafından sıralı numaralandırılması. Sunucu çekirdeği, her bir istemciden gelen en son isteğin numarasını hatırlar ve her bir istek alındığında, bu isteğin birincil mi yoksa tekrarlı mı olduğunu analiz eder. Sunucu, isteği aldıktan sonra çöktü. Idempotency özelliği de burada önemlidir ancak sorgu numaralandırma yaklaşımı maalesef uygulanamamaktadır. Bu durumda, arızanın ne zaman meydana geldiği önemlidir - operasyondan önce veya sonra. Ancak istemci çekirdeği bu durumları tanıyamaz, yalnızca yanıtın zaman aşımına uğradığını bilir. Bu soruna üç yaklaşım vardır: Sunucu yeniden başlayana kadar bekleyin ve yeniden deneyin. Bu yaklaşım, RPC'nin en az bir kez ve muhtemelen daha fazla tamamlanmasını sağlar. Hatayı hemen uygulamaya bildirin. Bu yaklaşım, RPC'nin en fazla bir kez yürütülmesini sağlar. Üçüncü yaklaşım hiçbir şeyi garanti etmez. Sunucu başarısız olduğunda, istemci için destek yoktur. RPC, hiç veya birçok kez gerçekleştirilebilir veya gerçekleştirilmeyebilir. Her durumda, bu yöntemin uygulanması çok kolaydır.

Bu yaklaşımların hiçbiri çok çekici değil. Ve genel durumda, tam olarak bir RPC yürütmesini garanti edecek ideal seçenek, ilkesel nedenlerle uygulanamaz. Örneğin, bir uzaktan işlemin, yazıcı arabelleğinin yüklenmesini ve yazıcının bazı kontrol kayıtlarında bir bitin ayarlanmasını içeren bir metin yazdırdığını ve bunun sonucunda yazıcının başladığını varsayalım. Bir sunucu çökmesi, kontrol biti ayarlandıktan bir mikro saniye önce veya bir mikro saniye sonra meydana gelebilir. Arıza anı, kurtarma prosedürünü tamamen belirler, ancak müşteri arıza anını bilemez. Kısacası, bir sunucu çökmesi olasılığı, RPC'nin doğasını kökten değiştirir ve merkezi bir sistem ile dağıtılmış bir sistem arasındaki farkı açıkça yansıtır. İlk durumda, bir sunucu çökmesi istemcinin çökmesine neden olur ve kurtarma imkansızdır. İkinci durumda, sistemi geri yüklemek için eylemleri gerçekleştirmek mümkün ve gereklidir.

İstemci, isteği gönderdikten sonra çöktü. Bu durumda kimsenin beklemediği sonuçlar üzerinden hesaplamalar yapılır. Bu tür hesaplamalara "yetim" denir. Yetimlerin varlığı çeşitli sorunlara neden olabilir: CPU zamanının ek yükü, kaynakların engellenmesi, mevcut isteğe verilen yanıtın sistem yeniden başlatılmadan önce istemci makine tarafından verilen bir isteğe verilen yanıtla değiştirilmesi.

Yetimler ne yapmalı? 4 olası çözüm düşünelim.

Yıkım. İstemci saplaması bir RPC mesajı göndermeden önce, şimdi ne yapacağını bildiren günlükte bir not alır. Günlük, diskte veya hataya dayanıklı başka bir bellekte depolanır. Kazadan sonra sistem yeniden başlatılır, log analiz edilir ve yetimler elimine edilir. Bu yaklaşımın dezavantajları arasında, ilk olarak, her bir RPC hakkında diske yazma ile ilişkili artan maliyetler ve ikinci olarak, birinci nesil yetimler tarafından verilen RPC çağrıları tarafından oluşturulan ikinci nesil yetimlerin ortaya çıkması nedeniyle olası verimsizlik yer alır. Reenkarnasyon. Bu durumda diske yazma kullanılmadan tüm problemler çözülür. Yöntem, zamanı sıralı olarak numaralandırılmış periyotlara bölmekten oluşur. İstemci yeniden başlatıldığında, yeni bir dönem başlatmak için tüm makinelere yayın yapar. Bu mesajın alınmasından sonra, tüm uzak hesaplamalar sonlandırılır. Tabii ki, ağ bölümlere ayrılırsa, bazı yetimler hayatta kalabilir. Yumuşak reenkarnasyon, tüm uzak hesaplamaların bulunup yok edilmemesi, ancak yalnızca yeniden başlatan istemcininkiler dışında önceki duruma benzer. Son kullanma tarihi. Her isteğe, yerine getirilmesi gereken standart bir T zaman aralığı atanır. Talep ayrılan süre içinde tamamlanmazsa, ek bir kuantum tahsis edilir. Bu ek çalışma gerektirse de, bir istemci çökmesinden sonra sunucu istemciyi yeniden başlatmadan önce T aralığını beklerse, tüm yetimler mutlaka yok edilir.

Pratikte bu yaklaşımların hiçbiri arzu edilmez; üstelik yetimleri öldürmek durumu daha da kötüleştirebilir. Örneğin, bir yetimin bir veya daha fazla veritabanı dosyasını kilitlediğini varsayalım. Yetim aniden yok edilirse bu kilitler kalır, ayrıca bozulan yetimler çeşitli sistem kuyruklarında ayakta kalabilir, ileride yeni işlemlerin yürütülmesine neden olabilir vb.