Bu makalenin amacı terminolojiyi tartışmaktır. Makale nasıl ve neden hakkında değil, yalnızca terminolojinin kullanımı hakkındadır. Makale, yazarın görüşünü yansıtır ve bilimsel olma iddiasında değildir.

giriiş

Programlama alanında çalışıyorsanız dağıtılmış sistemler veya içinde sistemler entegrasyonu, o zaman burada sunulanların çoğu sizin için yeni değil.

Sorun, insanlar kullanarak buluştuğunda ortaya çıkar. farklı teknolojiler ve bu insanlar teknik konuşmalara başladığında. Bu durumda, genellikle terminoloji nedeniyle karşılıklı bir yanlış anlama vardır. Burada farklı bağlamlarda kullanılan terminolojileri bir araya getirmeye çalışacağım.

terminoloji

Bu alanda net bir terminoloji ve sınıflandırma yoktur. Aşağıda kullanılan terminoloji, yazarın modelinin bir yansımasıdır, yani tamamen özneldir. Her türlü eleştiriye ve her türlü tartışmaya açığız.

Terminolojiyi üç alana ayırdım: RPC (Uzaktan Prosedür Çağrısı), Mesajlaşma ve REST. Bu alanların tarihsel kökleri vardır.

RPC

RPC teknolojiler en eski teknolojilerdir. RPC'nin en parlak temsilcileri - ÇORBA Ve DCOM.

O günlerde, esas olarak sistemleri hızlı ve nispeten güvenilir bir şekilde bağlamak zorundaydınız. yerel ağlar. RPC'nin arkasındaki ana fikir, uzaktaki sistemleri çağırmayı bir program içindeki işlevleri çağırmaya benzer hale getirmekti. Tüm uzaktan arama mekaniği, programcıdan gizlendi. En azından saklamaya çalıştılar. Çoğu durumda programcılar, sıralama terimlerinin ortaya çıktığı daha derin bir düzeyde çalışmak zorunda kaldılar ( Sıralama) Ve marşalizasyon(Rusça'da nasıl?), bu da esasen serileştirme anlamına geliyordu. İşlemler içindeki normal işlev çağrıları, arayan V vekil ve sistemin işlevi yerine getiren tarafında, Sevk görevlisi. İdeal olarak, ne çağıran sistem ne de işlem yapan sistem, sistemler arasında veri aktarımının inceliklerini halletmiyordu. Tüm bu incelikler, kodu otomatik olarak oluşturulan Proxy - Dispatcher paketinde yoğunlaştı.

Dolayısıyla, yerel bir işlevi çağırmakla uzak bir işlevi çağırmak arasında herhangi bir fark görmezsiniz, fark etmemelisiniz.
Şimdi bir tür RPC rönesansı var ve bunların en önde gelen temsilcileri Google ProtoBuf, Thrift, Avro.

mesajlaşma

Zamanla, programcıyı çağrılan işlevin yerel olandan hala farklı olduğu gerçeğinden koruma girişiminin istenen sonuca yol açmadığı ortaya çıktı. Dağıtılmış sistemler arasındaki uygulama ayrıntıları ve temel farklılıklar, otomatik olarak oluşturulan Proxy kodu kullanılarak çözülemeyecek kadar büyüktü. Yavaş yavaş, sistemlerin güvenilmez, yavaş, düşük hızlı bir ortamla birbirine bağlı olduğu gerçeğinin program koduna açıkça yansıtılması gerektiği anlayışı geldi.

Teknolojiler ortaya çıktı Ağ hizmetleri. konuşmaya başladık ABC: Adres, Bağlayıcılık, Sözleşme. Giriş argümanları için esasen Zarflar (zarflar) olan sözleşmelerin neden ortaya çıktığı tam olarak açık değildir. Sözleşmeler genellikle tüm modeli basitleştirmek yerine karmaşıklaştırır. Aman neyse.

Şimdi programcı açıkça yarattı hizmet(Hizmet) veya müşteri(müşteri) servisi çağıran. Servis bir setti. operasyonlar (operasyon), her biri girişte aldı rica etmek(Rica etmek) ve yayınlandı cevap(Cevap). müşteri açıkça gönderilmiş(Aziz) istek, açıkça alınan hizmet ( almak) ve yanıtladı (Gönderildi), yanıtı gönderiyor. Müşteri cevabı aldı (Aldı) ve bunun üzerine arama sona erdi.

Tıpkı RPC'de olduğu gibi, Proxy ve Dispatcher burada bir yerde çalıştı. Ve daha önce olduğu gibi, kodları otomatik olarak oluşturuldu ve programcının bunu anlaması gerekmiyordu. İstemci açıkça Proxy'den sınıfları kullanmadığı sürece.

İstekler ve yanıtlar açıkça tel biçimine dönüştürülür. Çoğu zaman bir bayt dizisidir. dönüşüm denir Serileştirme Ve seri kaldırma ve bazen proxy kodunda gizlenir.
Mesajlaşmanın doruk noktası, bir paradigmanın ortaya çıkmasında kendini gösterdi. ESB (Kurumsal Hizmet Veriyolu). Kimse gerçekten ne olduğunu formüle edemez, ancak herkes ESB'deki verilerin mesaj biçiminde hareket ettiği konusunda hemfikirdir.

DİNLENMEK

Kodun karmaşıklığıyla sürekli bir mücadele içinde olan programcılar bir sonraki adımı attılar ve kodu yarattılar. DİNLENMEK.

REST'in temel prensibi, işlev işlemlerinin ciddi şekilde sınırlandırılması ve yalnızca bir dizi işlem bırakmasıdır. CRUD: Oluştur - Oku - Güncelle - Sil. Bu modelde, tüm işlemler her zaman bazı verilere uygulanır. CRUD'de bulunan işlemler çoğu uygulama için yeterlidir. REST teknolojileri çoğu durumda kullanımı içerdiğinden HTTP protokolü, ardından CRUD komutları komutlara yansıtıldı HTTP (Postalamak - Elde etmek - Koymak - Silmek) . Sürekli olarak REST'in mutlaka HTTP'ye bağlı olmadığı tartışılır. Ancak pratikte, işlem imzalarının HTTP komutlarının sözdizimine yansıması yaygın olarak kullanılmaktadır. Örneğin, bir işlev çağrısı

EntityAddress ReadEntityAddress(dize param1, dize param2)

Şu şekilde ifade edilir:

GET: entityAddress?param1=değer1¶m2=değer2

Çözüm

Dağıtılmış sistemler veya entegrasyon hakkında bir tartışma başlatmadan önce bazı terminoloji tanımlayın. Proxy, farklı bağlamlarda her zaman aynı şeyi ifade ediyorsa, örneğin, istek RPC açısından çok az şey ifade edecek ve sıralama, REST teknolojilerini tartışırken şaşkınlığa neden olacaktır.

Bir ağ üzerinden iletişim kuran programların bir iletişim mekanizmasına ihtiyacı vardır. Alt seviyede, paketlerin gelmesi üzerine, ağ sinyal işleme programı tarafından işlenen bir sinyal gönderilir. En üst düzeyde, Ada dilinde benimsenen buluşma mekanizması (rendezvous) ç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 göre, istemci önce sunucuya istek gönderen bir yordamı çağırır. Paketin istekle gelmesi üzerine, sunucu açılış prosedürünü başlatır, istenen hizmeti gerçekleştirir, bir yanıt gönderir ve kontrol istemciye geri döner.

RPC arayüzünün üç katmandan oluştuğu düşünülebilir:

1. En üst seviye tamamen "şeffaftır". Bu seviyedeki bir program, örneğin, uzak makinedeki kullanıcı sayısını döndüren rnusers() prosedürüne bir çağrı içerebilir. Aramayı program içinde yaptığınız sürece RPC mekanizmasını kullanmayı bilmenize gerek yoktur.
2. Orta katman, en yaygın uygulamalar içindir. Bu seviyedeki RPC çağrıları, registerrpc() ve callrpc() altyordamları tarafından işlenir: registerrpc() sistem çapında kod alır ve callrpc() bir uzaktan prosedür çağrısı yürütür. rnuusers() çağrısı, bu iki alt program kullanılarak gerçekleştirilir.
3. Alt seviye, varsayılanları prosedür parametresi değerlerine değiştiren daha karmaşık görevler için kullanılır. Bu seviyede, RPC mesajlarını göndermek için kullanılan yuvaları açıkça değiştirebilirsiniz.

Genel bir kural olarak üst katı kullanmalı ve çok gerekli olmadıkça alt katları kullanmaktan kaçınmalısınız.

Bu eğitimde sadece C arayüzünü ele alsak da, herhangi bir dilden uzaktan prosedür çağrıları yapılabilir. Farklı makinelerdeki işlemler arasındaki iletişimi organize etmek için RPC mekanizmasının çalışması, aynı makinedeki işleyişinden farklı değildir.

RPC (Uzaktan Prosedür Çağrısı, Uzaktan Prosedür Çağrısı Hizmeti) arasında bir arayüzdür. uzak kullanıcılar Ve belirli programlar bu kullanıcıların isteği üzerine başlatılan ana bilgisayar. Bir ana bilgisayarın RPC hizmeti, genellikle istemcilere bir dizi program sağlar. Bu programların her biri sırayla bir veya daha fazla uzak prosedürden oluşur. Örneğin, uzaktan hizmet dosya sistemi RPC çağrıları üzerine kurulu olan NFS, yalnızca iki programdan oluşabilir: örneğin, bir program üst düzey kullanıcı arabirimleriyle, diğeri ise düşük düzey G / Ç işlevleriyle etkileşime girer.

Her uzaktan yordam çağrısında yer alan iki taraf vardır: sunucuya bir yordam çağrısı isteği gönderen etkin istemci ve istemciye geri yanıt gönderen sunucu.

Not. Bu durumda "istemci" ve "sunucu" terimlerinin belirli bir işlemi ifade ettiğini unutmayın.Belirli bir ana bilgisayar veya yazılım (işlem veya program) hem istemci hem de sunucu görevi görebilir. Örneğin, uzaktan yordam hizmeti sağlayan bir program, bir ağ dosya sistemiyle çalışan bir istemci de olabilir.

RPC protokolü, yerel prosedür çağrılarına benzer bir uzaktan prosedür çağrısı modeli üzerine kuruludur. Yerel bir yordamı çağırdığınızda, bağımsız değişkenleri yığında veya bellekte belirli bir konuma gönderirsiniz. Ortam Değişkenleri ve sürecin kontrolünü belirli bir adrese aktarın. İşiniz bittiğinde, belirli bir adreste sonuçları okursunuz ve işleminize devam edersiniz.

Bir uzak yordamla çalışma durumunda temel fark, uzak işlev çağrısına iki işlem tarafından hizmet verilmesidir: istemci işlemi ve sunucu işlemi.

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

RPC protokolü, işlemler arasındaki ek iletişimlere herhangi bir gereksinim getirmez ve gerçekleştirilen işlevlerin senkronizasyonunu gerektirmez, yani çağrılar eşzamansız ve karşılıklı olarak bağımsız olabilir, böylece müşteri yanıt beklerken diğer prosedürleri gerçekleştirebilir. RPC sunucusu her bir fonksiyon için ayrı bir process veya sanal makine tahsis edebilir, bu sayede bir önceki isteklerin bitmesini beklemeden bir sonraki istekleri hemen kabul edebilir.

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

1. Hata işleme. İstemciye her durumda, sunucuda veya ağda uzaktan yordam çağrıları yapılırken oluşan hatalar bildirilmelidir.
2. Küresel değişkenler. Sunucunun istemcinin adres alanına erişimi olmadığından, uzaktan yordam çağrıları gizli parametreleri genel değişkenler olarak kullanamaz.
3. Verim. Uzaktan prosedürleri yürütme hızı, kural olarak, benzer yerel prosedürleri yürütme hızından bir veya iki kat daha düşüktür.
4. kimlik doğrulama. Uzak 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ünü kullanabilir. RPC protokolünün sorumluluğu sadece standartları sağlamak ve ileti geçişlerini yorumlamaktır. Mesaj iletiminin güvenilirliği ve güvenilirliği tamamen taşıma katmanı tarafından sağlanır.

Ancak RPC, taşıma protokolünün seçimini ve bazı özelliklerini kontrol edebilir. RPC ile bir aktarım protokolü arasındaki etkileşime örnek olarak, RPC - Portmapper aracılığıyla bir uygulama işlemi için bir RPC bağlantı noktası atama prosedürünü ele alalım.

Bu işlev, dinamik olarak (talep üzerine) belirli bir bağlantı noktasını bir RPC bağlantısına atar. Portmapper işlevi, RPC için ayrılan taşıma bağlantı noktaları kümesi sınırlı olduğundan ve potansiyel olarak aynı anda çalışabilen işlem sayısı çok yüksek olduğundan, oldukça sık kullanılır. Örneğin, NFS sisteminin istemcisi ile sunucusu arasındaki iletişim için bağlantı noktalarını seçerken Portmapper çağrılır.

Portmapper hizmeti, belirli bir bağlantı noktası olan III'te RPC yayın mesajı mekanizmasını kullanır. İstemci bu bağlantı noktasına bir bağlantı noktası isteği yayın mesajı gönderir. belirli bir hizmet RPC. Portmapper hizmeti mesajı işler, yerel RPC hizmetinin adresini belirler ve istemciye bir yanıt gönderir. RPC Portmapper hizmeti, hem TCP hem de UDP protokolleriyle çalışabilir.

RPC, çeşitli aktarım protokolleriyle çalışabilir, ancak işlevlerini asla çoğaltmaz, yani RPC, TCP'nin üzerinde çalışıyorsa, RPC bağlantısının güvenilirliği ve güvenilirliği ile ilgili tüm endişeler TCP'ye atanır. Ancak, RPC UDP üzerinden kurulursa, mesaj teslimini sağlamak için ek yerel özellikler sağlayabilir.

Not.

Uygulama görevleri, RPC protokolünü bir JSR (Atlama Alt Programı Talimatı) ağı üzerinden bir işlevi çağırmak için özel bir prosedür olarak kabul edebilir.

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 tanımlaması. RPC istekleri üç tanımlayıcı alan içerir - uzak programın (hizmetin) numarası, uzak programın sürüm numarası ve uzak yordamın numarası belirtilen program. Program numarası servis sağlayıcı tarafından atanır, prosedür numarası belirli işlevi gösterir. bu servis
2. RPC protokol versiyonunun 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 koordine etmek 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 istekte 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 yok
• AUTH_UNIX - UNIX standart kimlik doğrulaması
• AUTH_SHORT - Kendi kodlama yapısına sahip UNIX standart kimlik doğrulaması
• AUTH_DES - DES kimlik doğrulaması

1. Karşılık gelen isteklere yanıt mesajlarının tanımlanması. RPC yanıt mesajları, oluşturuldukları istek tanımlayıcısını içerir. Bu kimlik, RPC çağrısının işlem kimliği olarak adlandırılabilir. Bu mekanizma, özellikle eşzamansız modda çalışırken ve birkaç RPC çağrısı dizisini yürütürken gereklidir.
2. Protokol hatalarının tanımlanması. Tüm ağ veya sunucu hatalarının, bağlantıdaki her bir katılımcının hatanın nedenini belirleyebileceği benzersiz tanımlayıcıları vardır.

Protokol Mesaj Yapıları

RPC mesajlarını bir taşıma protokolü üzerinden iletirken, birden çok RPC mesajı tek bir taşıma paketi içinde bulunabilir. Bir mesajı diğerinden ayırmak için bir kayıt işaretleyici (RM - Kayıt İşaretleyici) kullanılır. Her RPC mesajı, tam olarak bir RM ile "etiketlenir".

Bir RPC mesajı birkaç parçadan oluşabilir. Her parça, dört başlık baytından ve (0'dan 2**31-1'e kadar) verilerden oluşur. Başlığın ilk biti verilen parçanın sonuncusu olup olmadığını, kalan 31 bit ise veri paketinin uzunluğunu gösterir.

RPC'nin yapısı, veri biçimlerinin açıklama ve temsil dilinde - XDR'de ve prosedürlerin açıklamasına ilişkin eklemelerle resmi olarak açıklanmıştır. RPC açıklama dilinin, prosedürlerle çalışmayla desteklenen XDR'nin bir uzantısı olduğu bile söylenebilir.

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

Yanıt yapısı (reply_body), bir hata durumunda iletilen yapıyı (bu durumda hata kodunu içerir) veya başarılı istek işleme yapısını (bu durumda döndürülen verileri içerir) içerebilir.

Üst düzey programlama arayüzü.

Bir programda alt programları kullanma - geleneksel yol görevi yapılandırın, daha net hale getirin. En sık kullanılan yordamlar, farklı programlar tarafından kullanılabilecekleri kitaplıklarda toplanır. Bu durumda, yerel (yerel) bir aramadan bahsediyoruz, yani hem arayan hem de aranan nesneler aynı bilgisayarda aynı program içinde çalışır.

Uzaktan arama durumunda, bir bilgisayarda çalışan bir işlem, diğer bilgisayarda da bir işlemi başlatır. uzak bilgisayar(yani aslında prosedür kodunu uzak bilgisayarda çalıştırır). Bir uzaktan prosedür çağrısının geleneksel yerel çağrıdan önemli ölçüde farklı olduğu açıktır, ancak programcının bakış açısından, pratikte böyle bir fark yoktur, yani bir uzaktan prosedür çağrısının mimarisi, bir yerel çağrıyı simüle etmenize olanak tanır.

Bununla birlikte, yerel bir arama durumunda, program parametreleri çağrılan prosedüre iletir ve çalışmanın sonucunu yığın veya paylaşılan bellek alanları aracılığıyla alırsa, o zaman bir uzak arama durumunda, parametrelerin iletilmesi, üzerinden bir istek göndermeye dönüşür. ağ ve işin sonucu gelen yanıtta.

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 korunur. RPC mekanizmasını açıklarken, arama sürecini geleneksel olarak istemci olarak adlandıracağız ve uzak süreç, prosedürü uygulayan - sunucu tarafından.

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

1. İstemci programı, saplama adı verilen bir yordama yerel bir çağrı yapar. Aynı zamanda, istemciye saplamayı çağırarak aslında sunucu prosedürünü çağırdığı "görünür". Gerçekten de, müşteri gerekli parametreleri saplamaya iletir ve sonucu döndürür. Ancak durum müşterinin düşündüğü gibi değildir. Saplamanın işi, uzak yordama yönelik bağımsız değişkenleri kabul etmek, belki de bunları bazı standart biçimlere dönüştürmek ve bir ağ isteği 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, önceki bölümlerde açıklananlar gibi uygun çağrıları kullanır. Bu durumda yalnızca TCP / IP ailelerinin değil, çeşitli aktarım protokollerinin kullanılabileceğini unutmayın.
3. Uzak ana bilgisayarda her şey olur Ters sipariş. Sunucu stub'ı bir istek bekler ve alındığında parametreleri, prosedür çağrısı bağımsız değişkenlerini alır. Ayıklama (sıralamadan çıkarma), gerekli dönüştürmeleri (örneğin, baytların yeniden sıralanması) içerebilir.
4. Saplama, ağ üzerinden alınan bağımsız değişkenleri ileterek, istemcinin talebinin adreslendiği gerçek sunucu prosedürüne bir çağrı yapar.
5. Prosedürü yürüttükten sonra kontrol, gerekli parametreleri ileterek sunucu saplamasına geri döner. İstemci koçanında olduğu gibi; sunucu saplaması, prosedürün döndürdüğü değerleri, isteğin geldiği sisteme ağ üzerinden gönderilen bir ağ yanıt mesajı oluşturmak için dönüştürür.
6. İşletim sistemi, alınan mesajı, gerekli dönüşümden sonra, değerleri (uzak prosedür tarafından döndürülen değerler olan) istemciye ileten ve bunu normal bir geri dönüş olarak yorumlayan istemci saplamasına iletir. prosedür.

Böylece müşterinin bakış açısından, tıpkı yerel bir prosedür çağrısında olduğu gibi, bir uzaktan prosedür çağrısı yapar. Aynısı sunucu için de söylenebilir: prosedür standart şekilde çağrılır, bazı nesneler (sunucu stub) 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 alır.

Bu nedenle, hem istemci hem de sunucu çağrıların yerel olarak yapıldığını düşünse de, taslaklar RPC sisteminin merkezinde yer alır ve bir istemci ile uzak sunucu (prosedür) arasında mesaj oluşturma ve iletmenin tüm yönlerinden sorumludur. Bu, RPC'nin ana konseptidir - etkileşimin dağıtılmış (ağ) doğasını saplama kodunda 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 belirli bir dağıtılmış ağ içinde çalışır. sanal makine ve prosedür çağrıları standart bir arayüze sahiptir.

Geçme parametreleri

Değer parametrelerini geçmek zor değildir. Bu durumda, istemci saplaması, belki de standart dönüştürmeler gerçekleştirerek (örneğin, endianlığı değiştirerek) ağ isteğinde parametrenin değerini yerleştirir. Parametre verinin değeri değil, adresi olduğunda işaretçileri geçerken durum çok daha karmaşıktır. Uzak prosedür tamamen farklı bir adres alanında çalıştığı için istekte bir adres iletmek anlamsızdır. en çok basit çözüm RPC'de kullanılan, kesinlikle ciddi kısıtlamalar getirmesine rağmen, istemcilerin değer dışındaki parametreleri geçirmesini engellemektir.

bağlama

Bir istemcinin bir uzak yordamı çağırabilmesi için, gerekli sunucuya sahip bir uzak sistemle ilişkilendirilmiş olması gerekir. Böylece bağlama görevi ikiye ayrılır:

1. bulma uzak ana bilgisayar gerekli sunucu ile
2. Belirli bir ana bilgisayarda gerekli sunucu işlemini bulma

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

Her bir 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 uzak yordamlar grubunu tanımlar. Her programa ayrıca bir sürüm numarası atanır, böylece programda küçük değişiklikler yaparsanız (örneğin, bir prosedür eklemek), numarasını değiştirmenize gerek kalmaz. Tipik olarak, işlevsel olarak benzer birkaç prosedür, başlatıldığında bu prosedürlerin sunucusu haline gelen ve program numarası ile tanımlanan bir program modülünde uygulanır.

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

İstemcinin bir istek göndermek için, ana bilgisayarın ağ adresini ve gerekli prosedürleri sağlayan sunucu programıyla ilişkili bağlantı noktası numarasını da bilmesi gerekir. Bu, portmap(IM) arka plan programı (bazı sistemlerde rpcbind(IM) olarak adlandırılır) kullanılarak yapılır. Arka plan programı, uzaktan yordam hizmeti sağlayan ve iyi bilinen bir bağlantı noktası numarası kullanan bir ana bilgisayarda çalışır. Bir sunucu işlemi başlatıldığında, prosedürlerini ve port numaralarını portmap(IM) içine kaydeder. Şimdi, istemcinin belirli bir yordamı çağırmak için bağlantı noktası numarasını bilmesi gerektiğinde, portmap(IM) sunucusuna bir istek gönderir, bu da ya bağlantı noktası numarasını döndürür ya da isteği doğrudan uzak yordam sunucusuna iletir ve geri döner yürüttüğünde istemciye bir yanıt. Her durumda, gerekli prosedür mevcutsa, müşteri prosedürün port numarasını portmap(IM) sunucusundan alır ve doğrudan bu porta başka isteklerde bulunabilir.

Tedavi özel durumlar(istisna)

Yerel prosedürleri çağırırken istisnaları ele almak pek problem değil. UNIX, sıfıra bölme, geçersiz bir bellek alanına erişim vb. işlem hatalarının ele alınmasını sağlar. Uzak prosedür çağrısı durumunda, hata durumlarının olasılığı artar. Sunucuya eklenen ve saplama hataları, örneğin hatalı bir ağ mesajının alınmasıyla 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ınamazsa istemciye bir hata döndürülür. TCP protokolünün kullanılması durumunda, sunucu TCP bağlantısını sonlandırdıysa istemciye bir hata döndürülür.

Arama Semantiği

Yerel bir prosedürün çağrılması, açık bir şekilde onun yürütülmesine yol açar ve ardından kontrol ana programa geri döner. Uzak bir prosedür çağrılırken durum farklıdır. İşlemin tam olarak ne zaman yapılacağı, yapılıp yapılmayacağı ve yapılacaksa kaç kez yapılacağı belirlenemez. Örneğin, sunucu programı çöktükten sonra istek uzak sistem tarafından alınırsa, prosedür hiç yürütülmeyecektir. İstemci belirli bir süre (zaman aşımı) sonunda bir yanıt almazsa, isteği yeniden gönderirse, yanıtın zaten ağ üzerinden iletildiği bir durum ortaya çıkabilir ve tekrarlanan istek, uzak prosedür tarafından işlenmek üzere yeniden kabul edilir. . Bu durumda, prosedür birkaç kez gerçekleştirilecektir.

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

• Bir ve sadece bir kez. Bu davranışın (bazı durumlarda en çok istenen davranış) olası sunucu çökmeleri nedeniyle zorunlu kılınması zordur.
• Maksimum süreler. Bu, prosedürün ya hiç yürütülmediği ya da yalnızca bir kez yürütüldüğü anlamına gelir. Normal bir yanıt yerine bir hata alındığında benzer bir iddiada bulunulabilir.
• En azından bir kere. Prosedür muhtemelen bir kez uygulandı, ancak daha fazlası da mümkündür. İçin normal operasyon böyle bir durumda, uzak yordamın idempotent özelliği olmalıdır (İngiliz atasözünden). Bu özelliğin, tekrarlanan yürütmesi kümülatif değişikliklere neden olmayan bir yordamı vardır. Örneğin, bir dosyayı okumak önemsizdir, ancak bir dosyaya metin eklemek değildir.

Temsili veri

İstemci ve sunucu aynı bilgisayarda aynı sistem üzerinde çalıştığında veri uyumsuzluğu sorunu yaşanmaz. Hem istemci hem de sunucu için ikili formdaki veriler aynı şekilde sunulur. Uzaktan arama durumunda, istemci ve sunucunun farklı veri temsiline sahip farklı mimarilere sahip sistemlerde çalışabilmesi (örneğin, bir kayan nokta değerinin temsili, endianness, vb.)

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

Örneğin, Sun Microsystems RPC'deki veri temsil formatı aşağıdaki gibidir:

1. Bayt Sırası - En Büyük Son
2. Kayan Noktalı Değerleri Temsil Etmek - IEEE
3. Karakter gösterimi - ASCII

Açık

İşlevselliğinde, RPC sistemi, uygulama katmanı ile taşıma katmanı arasında bir ara konum işgal eder. Uyarınca OSI modeli bu hüküm sunum ve oturum katmanlarına karşılık gelir. Bu nedenle, RPC teorik olarak ağın uygulanması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'ın RPC sistemi, TCP ve UDP protokollerini kullanarak ileti geçişini destekler. Bir veya başka bir protokolün seçimi, uygulamanın gereksinimlerine bağlıdır. UDP protokolünün seçimi, aşağıdaki özelliklere sahip uygulamalar için gerekçelendirilir:

• Çağrılan prosedürler önemsizdir
• İletilen bağımsız değişkenlerin ve döndürülen sonucun boyutu, UDP paketinin boyutundan daha küçüktür - 8 KB.
• Sunucu, birkaç yüz istemciyle çalışma sağlar. Sunucu, TCP protokolleriyle çalışırken aktif istemcilerin her biriyle bağlantı kurmaya zorlandığından, bu, kaynaklarının önemli bir bölümünü kaplar. UDP protokolü bu açıdan daha az kaynak yoğundur.

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

• Uygulama, güvenilir bir aktarım protokolü gerektirir
• Çağrılan prosedürler önemsiz değildir
• Bağımsız değişkenlerin veya dönüş sonucunun boyutu 8 KB'yi aşıyor

Protokol seçimi genellikle müşteriye kalır 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. Bunu yapmak için, örneğin, RFC1057 "RPC: Uzaktan Yordam Çağrısı Protokolü belirtimi sürüm 2" içinde açıklanan ve her iletinin başına iletinin boyutunu belirten 32 bitlik bir tam sayının yerleştirildiği kayıt işaretleme protokolü kullanılır. bayt cinsinden.

Aramanın anlambiliminde durum farklıdır. Örneğin, RPC güvenilir olmayan bir taşıma protokolü (UDP) kullanılarak 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ındıysa, uygulama, prosedürün en az bir kez gerçekleştirildiği sonucuna varabilir. Güvenilir Aktarım Protokolü (TCP) ile bir yanıt alınırsa, işlemin bir kez gerçekleştirildiği söylenebilir. Cevap alınmazsa işlemin yapılmadığını kesin olarak söylemek mümkün değildir3.

Nasıl çalışır?

Temel olarak, RPC sisteminin kendisi istemci programında ve sunucu programında yerleşiktir. İyi haber şu ki, dağıtılmış uygulamalar geliştirirken, RPC protokolünün veya mesaj işleme programının ayrıntılarını araştırmanıza gerek yok. Sistem, uygulamanın yaratıcılarının hayatını büyük ölçüde kolaylaştıran uygun bir geliştirme ortamının varlığını varsayar. yazılım. RPC'deki kilit noktalardan biri, dağıtılmış bir uygulamanın geliştirilmesinin, bir nesne arayüzünün - sunucu işlevlerinin özel bir dilde yapılmış resmi bir açıklaması - tanımlanmasıyla başlamasıdır. Bu arayüze bağlı olarak, istemci ve sunucu saplamaları daha sonra otomatik olarak oluşturulur. Bundan sonra yapılacak tek şey asıl prosedür kodunu yazmaktır.

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

• rpcgen(1), uzak yordam arabiriminin açıklamasına dayalı olarak, C programları biçiminde istemci ve sunucu taslakları oluşturan bir RPC derleyicisidir.
• dönüştürmek için işlevler içeren XDR (eXternal Data Representation) kitaplığı çeşitli tipler verileri makineden bağımsız bir forma dönüştürerek, heterojen sistemler arasında bilgi alışverişine izin verir.
• Sistemin bir bütün olarak çalışmasını sağlayan modüller kütüphanesidir.

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

Bunu yapmak için en az üç dosya oluşturmanız gerekir: log.x uzak yordam arabirimlerinin belirtimi (arayüz açıklama dilinde), log.c uzak yordamlarının asıl metni ve istemci ana metni ana program () - client.c (C dilinde).

rpcgen(l) derleyicisi, log.x belirtimine dayalı olarak üç dosya oluşturur: C dilindeki istemci ve sunucu taslaklarının metni (log clnt.c ve log svc.c) ve her iki taslak tarafından kullanılan log.h açıklama dosyası .

O halde programların kaynak kodlarına bir göz atalım.

Bu dosya belirtir kayıt parametreleri uzaktan prosedür - program, sürüm ve prosedür numaraları ve ayrıca çağrı arayüzünü tanımlar - giriş argümanları ve dönüş değerleri. Böylece, RLOG prosedürü, argüman olarak bir dizge (günlüğe yazılacak) alınarak tanımlanır ve dönüş değeri, varsayılan olarak, istenen işlemin başarılı veya başarısız olduğunu gösterir.

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

Bu dosyaya daha yakından bakalım. Derleyici, arabirim tanım dosyasında tanımlanan RLOG adını, büyük karakterleri küçük harflerle değiştirerek ve programın sürüm numarasını bir alt çizgi ile ekleyerek rlog_1'e çevirir. Dönüş türü int'den int *'e değişti. Kural budur - RPC, yalnızca arabirim açıklamasında belirtilen parametrelerin adreslerini göndermenize ve almanıza izin verir. Aynı kural, bağımsız değişken olarak iletilen dize için de geçerlidir. print.h dosyası bunu ima etmese 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 saplama ve sunucu saplama modülleri üretir. Temel olarak, bu dosyaların metni tüm uzak arama kodunu içerir.

Sunucu saplaması, istemciyle tüm ağ etkileşimini yöneten ana bilgisayar programıdır (daha kesin olarak, saplaması ile). İşlemi gerçekleştirmek için sunucu saplaması, metninin yazılması gereken yerel bir işlev çağrısı yapar:

İstemci saplaması, uzak yordama iletilen bağımsız değişkeni alır, gerekli dönüşümleri yapar, portmap(1M) sunucusuna bir istek gönderir, uzak yordam sunucusuyla iletişim kurar ve son olarak istemciye dönüş değerini iletir. İstemci için uzak yordam çağırmak, bir saplama çağırmaya indirgenir ve normal bir yerel aramadan hiçbir farkı yoktur.

müşteri.c

log_clnt.c istemci stub'ı client.c modülüyle birlikte çalıştırılabilir bir istemci oluşturmak için derlenir.

Şimdi bazı host server.nowhere.ru'da sunucu sürecini başlatmanız gerekiyor:

Bundan sonra, rlog istemcisi başka bir makinede başlatıldığında, sunucu günlük dosyasına uygun girişi ekleyecektir.

Bu durumda RPC işleminin şeması, Şekil 2'de gösterilmektedir. 1. Modüller aşağıdaki gibi etkileşime girer:

1. Bir sunucu işlemi başladığında, bir UDP soketi oluşturur ve herhangi bir yerel bağlantı noktasını bu sokete bağlar. Daha sonra sunucu, program numaralarını ve sürümlerini kaydetmek için svc_register(3N) kitaplık işlevini çağırır. Bunu yapmak için işlev, portmap(IM) işlemini çağırır ve gerekli değerleri iletir. Portmap(IM) sunucusu genellikle sistem başlatıldığında başlar ve iyi bilinen bir bağlantı noktasına bağlanır. Artık portmap(3N) programımızın ve versiyonumuzun port numarasını biliyor. Sunucu bir istek almayı bekliyor. Açıklanan tüm eylemlerin, rpcgen(IM) derleyicisi tarafından oluşturulan sunucu saplaması tarafından gerçekleştirildiğini unutmayın.
2. rlog programı 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 portmap(IM) sunucusuna bir istek gönderir ve günlük sunucusu için uzak bağlantı noktası numarasını alır.
3. İstemci, istemci saplamasında tanımlanan rlog_1() prosedürünü çağırır ve kontrolü saplamaya aktarır. Bu da, (argümanları XDR biçimine dönüştürerek) bir UDP paketi biçiminde bir istek oluşturur ve bunu portmap (IM) sunucusundan alınan uzak bağlantı noktasına gönderir. Daha sonra bir süre yanıt bekler ve alınmazsa isteği yeniden gönderir. Elverişli koşullar altında, istek, kaydedici sunucusu (sunucu stub modülü) tarafından kabul edilir. Saplama, hangi işlevin çağrıldığını (prosedür numarasına göre) belirler ve log.c modülünün rlog_1() işlevini çağırır. Kontrolü stub'a geri döndürdükten sonra stub, rlog_1 () işlevi tarafından döndürülen değeri XDR biçimine dönüştürür ve yine bir UDP paketi biçiminde bir yanıt üretir. Yanıtı aldıktan sonra istemci saplaması döndürülen değeri çıkarır, dönüştürür ve istemcinin ana programına geri döndürür.

İstemci-sunucu uygulamaları için çok önemli bir mekanizma RPC ( Uzaktan Prosedür Çağrısı). RPC, Sun Microsystems tarafından geliştirilmiştir ve bir dizi araç ve kitaplık işlevidir. Özellikle NIS (Ağ Bilgi Sistemi) ve NFS (Ağ Dosya Sistemi) RPC üzerinde çalışır.

Bir RPC sunucusu, bir istemcinin, yordamın parametreleriyle birlikte sunucuya bir RPC isteği göndererek iletişim kurabileceği bir yordamlar sisteminden oluşur. Sunucu belirlenen prosedürü çağıracak ve varsa prosedürün dönüş değerini döndürecektir. Makineden bağımsız olmak için, istemci ve sunucu arasında değiş tokuş edilen tüm veriler sözde bir harici veri sunumuna dönüştürülür ( Harici Veri Temsili, XDR). RPC, verileri XDR formatında aktarmak için UDP ve TCP soketleriyle ilişkilendirilir. Sun, RPC'yi kamu malı olarak ilan etti ve açıklaması RFC serisinde mevcuttur.

Bazen RPC uygulamalarındaki değişiklikler, bir arayüzün çağrı prosedüründe uyumsuzluklara yol açar. Tabii ki, basit bir değişiklikle, sunucu hala eski çağrıları bekleyen uygulamaları yok edecektir. Bu nedenle, RPC programlarının kendilerine atanmış, genellikle 1'den başlayan sürüm numaraları vardır. yeni bir versiyon RPC sürüm numarasını takip eder. Genellikle bir sunucu aynı anda birden çok sürüm sunabilir. Bu durumda istemciler kullanmak istedikleri sürüm numarasını belirtirler.

RPC sunucuları ve istemciler arasındaki ağ iletişimi biraz özeldir. RPC sunucusu bir veya daha fazla sistem prosedürü sunar, bu tür prosedürlerin her bir grubuna program denir ( programı) ve program numarası ( program numarası). Hizmet adlarının listesi genellikle aşağıda bir örneği verilen /etc/rpc içinde saklanır.

Örnek 12-4. Örnek /etc/rpc dosyası

TCP/IP ağlarında, RPC yazarlarının program numaralarını genel ağ hizmetlerine eşleme görevi vardı. Her sunucu, her program ve her sürüm için bir TCP ve UDP bağlantı noktası sağlar. Genel olarak, RPC uygulamaları veri aktarmak için UDP'yi kullanır ve aktarılacak veriler tek bir UDP datagramına sığmadığında TCP'ye geri döner.

Elbette, istemci programlarının hangi bağlantı noktasının bir program numarasına karşılık geldiğini anlamanın bir yolu olmalıdır. Bunun için bir yapılandırma dosyası kullanmak çok katı olacaktır; RPC uygulamaları ayrılmış bağlantı noktalarını kullanmadığından, bağlantı noktasının bazı uygulamalar tarafından işgal edilmediğinin ve bizim tarafımızdan kullanılabilir olduğunun garantisi yoktur. Bu nedenle, RPC uygulamaları alabilecekleri herhangi bir bağlantı noktasını seçer ve onu kaydeder. portmapper arka plan programı. Belirli bir program numarasıyla bir hizmetle bağlantı kurmak isteyen bir müşteri, istenen hizmetin port numarasını bulmak için önce bir portmapper isteğinde bulunacaktır.

Bu yöntemin dezavantajı, tek bir başarısızlık noktası ortaya çıkarmasıdır. inetdşeytan Ancak bu durum biraz daha kötü çünkü port eşleyici başarısız olduğunda tüm RPC port bilgileri kayboluyor. Bu genellikle, tüm RPC sunucularını manuel olarak yeniden başlatmanız veya makineyi yeniden başlatmanız gerektiği anlamına gelir.

Linux'ta port eşleyici /sbin/portmap veya /usr/sbin/rpc.portmap şeklindedir. Portmapper, bir ağ başlangıç ​​komut dosyasından başlatılması gerekmesi dışında, herhangi bir yapılandırma çalışması gerektirmez.

Bilgisayarı yeniden başlattıktan sonra hizmet başlamadı " Uzaktan Yordam Çağrısı (RPC)". Pek çok şey bu hizmete bağlıdır. Sonuç olarak, sistem geri yükleme, ağ ortamı, ses, Windows Yükleyici, yönetim konsolu (MMC) neredeyse çalışmıyor, görev çubuğunda gösterilmiyor açık pencereler vesaire. ve benzeri. Manuel olarak başlatmaya çalışmak hatayla sonuçlanır " xxxComp'ta...(RPC) başlatılamıyor. Hata 5: Erişim reddedildi". Antivirüs hiçbir şey bulamadı. İki günlük kazı ve bilgisayar hayata döndürüldü.

Microsoft'un tavsiyesi üzerine denediğim ilk şey kayıt şubesini bulup silmek oldu. . Belki de bazı yüklü güncellemelerin bir sonucu olarak bende yoktu.

Ardından, kayıt defterindeki hizmet ayarlarını geri yüklemeyi deneyin. Regedit.exe salt okunur/silindiği için (başka bir yan etki), değişiklik yapmak mümkün olmadı. Evet, onlara ihtiyaç yoktu çünkü. her şey yolundaydı. Bu şöyle görünmelidir:

Windows Kayıt Defteri Düzenleyicisi Sürüm 5.00 "Description"="Uç noktaların ve diğer RPC hizmetlerinin eşlenmesini sağlar." "DisplayName"="Uzak Prosedür Çağrısı (RPC)" "ErrorControl"=dword:00000001 "Group"="COM Altyapısı" "ImagePath"=hex(2):25,00,53,00,79,00,73, 00,74,00,65,00,6d,00,52,00,6f,00,6f,00,\ ,74,00,65,00,6d,00,33,00,32,00,5c, 00,73,\ 00,76,00,63,00,68,00,6f,00,73,00, 74,00,20,00,2d,00,6b,00,20,00,72,00 ,70,00,\ 63,00,73,00,73,00,00,00 "ObjectName"="NT AUTHORITY\\NetworkService" "Başlat"=dword:00000002 "Type"=dword:00000010 "FailureActions"= hex:00,00,00,00,00,00,00,00,00,00,00,00,01 ,00,00,00,00,00,00,\ 00,02,00,00,00 ,60,ea,00,00 "ServiceSidType"=dword:00000001 "ServiceDll"=hex(2):25,00 ,53,00,79,00,73,00,74,00,65,00,6d,00, 52,00,6f,00,6f,\ 00,74,00,25,00,5c,00, 73.00.79.00.73.00.74.00.65.00.6d.00.33.00.32.00.5c.00 ,00,73, 00,2e,00,64,00,6c,00,6c,00,00,00 "Güvenlik"=hex:01,00,14,80,a8,00,00,00,b4, 00,00,00 ,14,00,00,00,30,00,00,00,02,\ 00,1c,00,01,00,00,00,02,80,14,00,ff,01 ,0f,00, 01,01,00,00,00,00,00,01,00,00,\ 00,00,02,00,78,00,05,00,00,00,00,00, 14.00.8d,00.02 .00.01.01.00.00.00.00.00 ,00,01,02,00,00,00,00,00,05,20,00,00,00,\ 20,02,00,00,00,00,18, 00,8d,00,02, 00,01,02,00,00,00,00,00,05,20,00,00,00,23,\ 02,00,00,00,00,14,00 ,9d,00,00,00 ,01,01,00,00,00,00,00,05,04,00,00,00,00,00,\ 18,00,9d,00,00,00, 01,02,00,00, 00,00,00,05,20,00,00,00,21,02,00,00,01,01,00,\ 00,00,00,00,05,12 ,00,00,00,01 ,01,00,00,00,00,00,05,12,00,00,00 "0"="Kök\\LEGACY_RPCSS\\0000" "Sayı"=dword:00000001 "NextInstance"=dword:00000001

Parametre değeri başlangıç farklılık gösterebilir. Yine de kayıt defterini değiştirebilirsiniz, ancak şu adresten önyükleme yapmanız gerekir: MS ERD komutanı.

Sonraki adımları adım adım listeleyeceğim. Genel fikir, dosyaları bilinen çalışan dosyalarla değiştirmektir. Başka bir makineden veya başka bir makineden alınabilirler. Windows dağıtımı(yaptığım gibi).

• Konsolu başlatın (Başlat > Çalıştır: komut)
• cdz:\i386(bir Windows dağıtımı var)
• explorer.ex_ %TEMP%\explorer.exe dosyasını genişletin
• svchost.ex_ %TEMP%\svchost.exe dosyasını genişletin
• Görev Yöneticisini Başlatın (Ctrl+Shift+Esc)
• Exlporer.exe işlemini durdurun
• %TEMP%\explorer.exe %SYSTEMROOT% /y dosyasını kopyalayın
• Tüm svchost.exe işlemlerini durdurun. Dikkat! Bundan sonra, makineyi yeniden başlatmadan önce 60 saniyeniz olacak.
• %TEMP%\svchost.exe %systemroot%\system32 /y dosyasını kopyalayın

Bu numara da işe yaramadı. Başka bir seçenek: tüm korunanların bir taramasını çalıştırın sistem dosyaları yanlış sürümlerin doğru olanlarla değiştirilmesiyle. Konsol çalıştırmasında:

Yardımcı olmadı .. Sonra tamamen acımasız bir hareket - güvenlik ayarlarını geri yüklemek. Yine konsolda:

Yeniden başlatmanın ardından bilgisayar çalışmaya başladı, temel hizmetler başladı. Yeni bir pervaz ortaya çıktı (veya belki de en başından beri): hesabım altında, en azından disk yönetimi yöneticisi ve Windows Installer başlamadı. Erişim engellendi. Sistem diskine erişim haklarını konsol aracılığıyla "varsayılan olarak" geri yükleyebilirsiniz:

Ardından, her hesabın haklarını manuel olarak tanımlamanız gerekir. veya yeniden oluşturun, hangisi daha kolaysa.

Benim durumumda, tümüne aynı hakları atadım. sistem diski, dizine erişimi referans olarak alıyor. Standarda, etki alanındaki hesabımı diskin tüm haklarıyla ekledim. Belki bu güvenlik açısından yanlıştır, ancak her bir dizini ayrı ayrı incelemeye zamanım yok.

başka ne yapılabilir

Bilgisayar "hasta" iken bu kayıt defterinde yoktu:

"ActiveService"="RpcSs"

Belki manuel bir ekleme bir şekilde durumu değiştirir.

Hizmeti, örneğin " komutu aracılığıyla manuel olarak başlatma girişimleri net başlangıç ​​rcpss"yanlışlıkla bitti" Hata 5: erişim reddedildi". Hizmetin "NT AUTHORITY" sistem hesabı altında çalışması gerektiğinden erişimin reddedildiğini varsayıyorum. Kayıt defterinde böyle bir parametre var:

"ObjectName"="NT AUTHORITY\\NetworkService"

Yönetici hesabını buraya girmeyi ve hizmeti yeniden başlatmayı denerdim. Ancak bu, yalnızca uygulamaya kadar yaşamamış bir fikirdir.

Başka bir seçenek de, sistem haklarına sahip bir konsol elde etmek için KiTrap0D istismarını kullanmaktır. Bu istismar hakkında yazılmıştır. Aslında bir ikili. Ancak Windows güncellemelerim var, bu yüzden bu açıktan yararlanma artık çalışmıyor gibi görünüyor.

İlgili içerik:

Uzaktan Yordam Çağrısı RPC Uzaktan Yordam Çağrısı - RPC Kavramı, aynı makinede çalışan bir program içindeki kontrol ve verileri bir ağ üzerinden kontrol ve verileri iletmeye yönelik iyi bilinen ve iyi anlaşılan mekanizmayı genişletmektir. Uzaktan prosedür çağrısı araçları, dağıtılmış bilgi işlemin organizasyonunu kolaylaştırmak için tasarlanmıştır RPC kullanmanın en yüksek verimliliği, uzak bileşenler arasında kısa yanıt süresi ve nispeten az miktarda veri aktarılan etkileşimli bir bağlantının olduğu uygulamalarda elde edilir.

Bu tür uygulamalara RPC odaklı denir. Yerel prosedürleri çağırmanın karakteristik özellikleri Asimetri yani etkileşimde bulunan taraflardan birinin başlatıcı olmasıdır Eşzamanlılık yani çağrı prosedürünün duraklarda talep verildiği andan itibaren yürütülmesi ve ancak aranandan döndükten sonra devam etmesi Uzak çağrıların uygulanması, yerel prosedürlere yapılan çağrıların uygulanmasından çok daha karmaşıktır.

Başlangıç ​​olarak, çağıran ve çağrılan prosedürler farklı makinelerde çalıştığından, farklı adres alanlarına sahipler ve bu, özellikle makineler aynı değilse, parametre ve sonuçları geçerken sorun yaratır.RPC, paylaşılan belleğe güvenemeyeceği için, bu şu anlama gelir: RPC parametrelerinin yığın olmayan bellek konumlarına işaretçiler içermemesi ve parametre değerlerinin bir bilgisayardan diğerine kopyalanması gerektiği.

RPC ve yerel çağrı arasındaki bir sonraki fark, zorunlu olarak temeldeki 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 getirir. Çağıran programın ve çağrılan yerel prosedürün aynı makinede çalıştırılması, tek bir işlem çerçevesinde gerçekleştirilir, ancak RPC uygulamasında en az iki işlem yer alır - her makinede bir tane.

Bunlardan birinin çökmesi durumunda, aşağıdaki durumlar meydana gelebilir: çağıran prosedür çöktüğünde, uzaktan çağrılan prosedürler yetim hale gelir ve uzak prosedürler çöktüğünde, çağıran prosedürler, çağrı yapan prosedürlerden bir yanıt bekleyecek olan yoksul ebeveynler haline gelir. uzaktan prosedürler boşuna Ek olarak, programlama dillerinin ve işletim ortamlarının heterojenliği ile ilgili bir dizi problem vardır, herhangi bir programlama dilinde desteklenen veri yapıları ve prosedür çağrı yapıları, diğer tüm dillerde aynı şekilde desteklenmez. .

Bu ve diğer bazı problemler, birçok dağıtılmış ürünün altında yatan yaygın RPC teknolojisi ile çözülmektedir. işletim sistemleri. Temel RPC İşlemleri RPC'nin nasıl çalıştığını anlamak için, önce çevrimdışı çalışan normal bir makinede bir yerel prosedür çağrısının yürütülmesini düşünelim. sistem çağrısı say fd,buf,nbytes oku burada fd bir tamsayıdır, buf bir karakter dizisidir, nbytes bir tamsayıdır.

Aramayı yapmak için, çağırma prosedürü parametreleri yığına ters sırayla iter Şekil 3.1. Okuma çağrısı yapıldıktan sonra, dönüş değerini bir kayda yerleştirir, dönüş adresini taşır ve kontrolü, yığından parametreleri alıp sıfırlayan çağrı prosedürüne döndürür.C'de parametrelerin çağrılabileceğini unutmayın. ya isme göre referansa göre ya da değere göre değere göre. Çağrılan prosedürle ilgili olarak, değer parametreleri başlatılabilir yerel değişkenlerdir.

Çağrılan prosedür bunları değiştirebilir ve bu, çağrılan prosedürdeki bu değişkenlerin orijinallerinin değerini etkilemez. Bir değişkene işaretçi çağrılan prosedüre iletilirse, bu değişkenin değerinin çağrılan prosedür tarafından değiştirilmesi, bu değişkenin değerinin çağrılan prosedür için değiştirilmesini gerektirir, bu gerçek RPC için çok önemlidir. C dilinde kullanılmayan başka bir parametre geçirme mekanizması daha vardır: Call-by-copy restore olarak adlandırılır, bu, çağıran programın değişkenleri yığına değerler olarak kopyalamasını ve ardından çağrı tamamlandıktan sonra geri kopyalamasını gerektirir. çağrı prosedürünün orijinal değerleri üzerinden yapılmıştır.

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

Pirinç. 3.1. a Okuma çağrısından önce yığınla b Prosedür yürütme sırasında yığınla çağıran programa döndükten sonra Yığınla RPC'nin ardındaki fikir, uzak prosedür çağrısını mümkün olduğunca yerel prosedür çağrısı gibi göstermektir. Başka bir deyişle, RPC'yi şeffaf yapmak için çağıran prosedürün, çağrılan prosedürün başka bir makinede olduğunu bilmesine gerek yoktur ve bunun tersi de geçerlidir: RPC, şeffaflığı şu şekilde sağlar.

Çağrılan yordam gerçekten bir uzak yordam olduğunda, yordamın istemci stub adı verilen başka bir sürümü, yerel yordam yerine kitaplığa yerleştirilir. Orijinal prosedürde olduğu gibi, saplama Şekil 3.1'deki çağrı sırası kullanılarak çağrılır ve çekirdeğe erişilirken bir kesinti meydana gelir. Sadece orijinal prosedürden farklı olarak, kayıtlara parametreler koymaz ve çekirdekten veri talep etmez, bunun yerine uzak makinenin çekirdeğine gönderilmek üzere bir mesaj oluşturur. RPC yürütme adımlarıEtkileşim yazılım bileşenleri bir uzaktan prosedür çağrısı gerçekleştirirken Şekil 3.2'de gösterilmektedir. İstemci saplaması istemci programı tarafından çağrıldıktan sonra, ilk işi arabelleği gönderdiği mesajla doldurmaktır.

Bazı sistemlerde, istemci saplaması, her yeni istek geldiğinde baştan doldurulan tek bir sabit uzunlukta ara belleğe sahiptir. Diğer sistemlerde, mesaj arabelleği, bazıları zaten dolu olan bireysel ileti alanları için bir arabellek havuzudur.

Bu yöntem, özellikle paketin çok sayıda alandan oluşan bir biçimi olduğunda uygundur, ancak bu alanların birçoğunun değerleri aramadan aramaya değişmez. Parametreler daha sonra uygun biçime dönüştürülmeli ve mesaj arabelleğine yerleştirilmelidir.Bu noktada, mesaj iletilmeye hazırdır, bu nedenle bir çekirdek kesintisi yürütülür. Pirinç. 3.2. Uzaktan Yordam Çağrısı Çekirdek kontrolü ele geçirdiğinde, bağlamları değiştirir, işlemci kayıtlarını ve bellek haritası sayfa tanımlayıcılarını kaydeder, çekirdek modu işlemi için kullanılacak yeni bir bellek haritası kurar. Çekirdek ve kullanıcı bağlamları farklı olduğu için, çekirdeğin mesajı tam olarak kendi adres alanına kopyalaması, böylece ona erişebilmesi, hedef adresi ve muhtemelen diğer başlık alanlarını hatırlaması ve onu ağ arayüzüne iletmesi gerekir.

Bu, istemci tarafındaki işi tamamlar.

Aktarım zamanlayıcısı başlar ve çekirdek ya bir yanıt için hepsini bir kez deneme anketi gerçekleştirebilir ya da denetimi çalıştırılacak başka bir işlemi seçecek olan zamanlayıcıya aktarabilir. İlk durumda, sorgu yürütme 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ğru olup olmadığını kontrol eder ve hangi saplamanın geçmesi gerektiğini belirler.Paketi bekleyen bir saplama yoksa, kesme işleyicisi ya arabelleğe almalı ya da tamamen atmalıdır. Bekleyen bir saplama varsa, mesaj ona kopyalanır. Son olarak, kayıtları ve hafıza haritasını saplama aramayı yaptığında sahip oldukları değerlere geri yükleyen 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, sunucuya çağrı yapılır. Prosedür tamamlandıktan sonra, sunucu sonuçları istemciye gönderir, bunun için yukarıda açıklanan tüm adımlar yalnızca ters sırayla gerçekleştirilir. Şekil 3.3, her bir 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 birinde toplam RPC yürütme süresinin ne kadarının harcandığını gösterir.

Çok işlemcili bir bilgisayar üzerinde araştırma yapılmıştır. iş istasyonu DEC Firefly ve beş işlemcinin varlığı, ölçümlerin sonuçlarını zorunlu olarak etkilese de, şekilde gösterilen histogram, RPC yürütme süreci hakkında genel bir fikir vermektedir. Pirinç. 3.3. RPC prosedürünün aşamaları Şekil. 3.4. RPC yürütmesinin 14 aşaması arasındaki zaman dağılımı 1. Saplamayı çağırın 2. Arabelleği hazırlayın 3. Parametreleri paketleyin 4. Başlık alanını doldurun 5. Mesajdaki sağlama toplamını hesaplayın 6. Çekirdeğe kesinti yapın 7. Paketi kuyruğa alın yürütme için 8. Mesajı QBUS veriyolundaki kontrolöre gönderin 9. İletim süresi Ethernet ağları 10. Denetleyiciden bir paket alın 11. Kesinti rutini 12. Sağlama toplamı hesaplaması 13. Kullanıcı alanına bağlam anahtarı 14. Sunucu stub yürütme Dinamik bağlama İstemcinin sunucunun konumunu nasıl belirlediğini düşünün.

Bu sorunu çözmenin bir yolu, sunucunun ağ adresini doğrudan istemci programında kullanmaktır.

Bu yaklaşımın dezavantajı, bir sunucuyu taşıdığınızda veya sunucu sayısını artırdığınızda veya tüm bu ve diğer birçok durumda arayüzü değiştirdiğinizde son derece esnek olmamasıdır, zor kullanılan tüm programları yeniden derlemek gerekir. sunucu adresi ayarı Tüm bu sorunlardan kaçınmak için, Bazı dağıtılmış sistemlerde dinamik bağlantı adı verilen bir şey kullanılır.

Dinamik bağlantı için başlangıç ​​noktası, sunucu belirtiminin resmi tanımıdır. Spesifikasyon, 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, parametrelerinin bir açıklaması verilir ve bu parametrenin sunucuya göre girdi mi yoksa çıktı mı olduğunu belirtir.Bazı parametreler hem girdi hem de çıktı olabilir - örneğin, istemci tarafından sunucuya gönderilen bazı diziler değiştirilir. orada ve ardından işlem istemciye geri döndürülür.kopya geri yükleme . Pirinç. 3.5. RPC sunucusu belirtimi Resmi sunucu belirtimi, hem istemci hem de sunucu saplamaları oluşturan saplama oluşturma programına girdi olarak kullanılır.

Daha sonra ilgili kitaplıklarına yerleştirilirler. Bir kullanıcı istemci programı, sunucu belirtiminde tanımlanan herhangi bir yordamı çağırdığında, karşılık gelen saplama yordamı, ikili kod programlar.

Benzer şekilde, bir sunucu derlendiğinde, sunucu taslakları onunla ilişkilendirilir. Sunucu başladığında, ilk eylem sunucu arayüzünü geçmektir. özel program, bağlayıcı ohm olarak adlandırılır. 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 sunucunun konumu için bir tanıtıcı sağlamasını içerir.İşlemci sistemden bağımsızdır ve bir IP, Ethernet, X.500 veya her neyse olabilir. adres.

Ek olarak, örneğin kimlik doğrulamayla ilgili başka bilgiler de içerebilir. İstemci uzak yordamlardan birini ilk kez çağırdığında, örneğin oku, istemci saplaması henüz sunucuya bağlı olmadığını görür ve ciltleme programına arabirimin içe aktarılması isteğiyle bir mesaj gönderir. gerekli sürüm istenen sunucu.Böyle bir sunucu varsa, ciltleyici tanıtıcıyı ve benzersiz tanıtıcıyı istemci saplamasına iletir.

İstemci saplaması, istek içeren bir mesaj gönderirken, adres olarak bir tanımlayıcı kullanır. Mesaj, bu makinede birkaç tane varsa, sunucu motorunun gelen mesajı doğru sunucuya yönlendirmek için kullandığı parametreleri ve benzersiz bir tanımlayıcıyı içerir. Arayüzleri içe ve dışa aktarmanın bu yöntemi oldukça esnektir.Örneğin, aynı arayüzü destekleyen birden fazla sunucu olabilir ve istemciler sunuculara rastgele atanır.

Bu yöntemin bir parçası olarak, sunucuları periyodik olarak yoklamak, performanslarını analiz etmek ve arıza durumunda, otomatik kapanma, bu da sistemin genel hata toleransını artırır. Bu yöntem, istemci kimlik doğrulamasını da destekleyebilir. Örneğin, bir sunucu, yalnızca belirli bir listedeki istemciler tarafından kullanılabileceğini belirleyebilir, ancak dinamik bağlamanın, arabirimleri dışa ve içe aktarmanın ek yükü gibi dezavantajları vardır.

Birçok istemci işlemi kısa bir süre için mevcut olduğundan ve işlem her başladığında, arayüz içe aktarma prosedürünün yeniden gerçekleştirilmesi gerektiğinden, bu maliyet önemli olabilir. Ek olarak, büyük dağıtık sistemlerde, ciltleme programı bir darboğaza dönüşebilir ve aynı amaca yönelik birden çok program oluşturmak, süreçlerin oluşturulması ve senkronize edilmesi yükünü de artırır.Arıza durumunda RPC semantiği İdeal olarak, RPC, başarısızlıklar.

Aşağıdaki hata sınıflarını göz önünde bulundurun 1. İstemci, örneğin istenen sunucu başarısız olursa veya istemci programı uzun zaman önce derlenmiş ve kullanılmışsa, sunucunun konumunu belirleyemez. eski versiyon sunucu arayüzü. Bu durumda, bir müşteri isteğine yanıt olarak hata kodu içeren bir mesaj alınır. 2. İstemciden sunucuya yapılan istek kayboldu.En basit çözüm, isteği belirli bir süre sonra tekrarlamaktır. 3. Sunucudan istemciye kayıp yanıt mesajı.

Bu seçenek, öncekinden daha karmaşıktır, çünkü bazı prosedürler kesin değildir. Bir idempotent prosedür, yürütme talebi sonucu değiştirmeden birkaç kez tekrarlanabilen bir prosedürdür. Bir dosyayı okumak böyle bir prosedüre örnek teşkil edebilir, ancak bir banka hesabından belirli bir miktarı çekme prosedürü önemsiz değildir ve cevap kaybedilirse, tekrarlanan bir talep müşterinin hesabının durumunu önemli ölçüde değiştirebilir.

Olası bir çözüm, tüm prosedürleri önemsiz hale getirmektir. Bununla birlikte, pratikte bu her zaman mümkün değildir, bu nedenle başka bir yöntem kullanılabilir - istemci çekirdeği tarafından tüm isteklerin sıralı numaralandırılması. Sunucu çekirdeği, istemcilerin her birinden gelen en son isteğin sayısını hatırlar ve her isteği aldıktan sonra, bu isteğin birincil mi yoksa tekrarlanan mı olduğunu analiz eder. 4. Sunucu isteği aldıktan sonra çöktü.Idempotence özelliği burada da önemlidir, ancak ne yazık ki istek numaralandırma yaklaşımı uygulanamaz.

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 işlemi 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 arızalandığında istemciye destek sağlanmaz. RPC ya hiç yürütülmeyebilir ya da birçok kez yürütülebilir. Her durumda, bu yöntemin uygulanması çok kolaydır. Bu yaklaşımların hiçbiri çok çekici değil ve tam olarak birini garanti eden ideal seçenek RPC yürütme, genel durumda temel nedenlerle uygulanamaz.

Örneğin, bir uzak işlemin, bir yazıcı arabelleği yüklemeyi ve yazıcının başlamasına neden olan bazı yazıcı kontrol kaydında bir bit ayarlamayı içeren bazı metinleri yazdırıyor olmasına izin verin. kontrol biti ayarlanır. Arıza anı tamamen kurtarma prosedürünü belirler, ancak müşteri arıza anını öğrenemez.

Kısacası, bir sunucu çökmesi olasılığı, RPC'nin doğasını kökten değiştirir ve merkezi ve dağıtılmış bir sistem arasındaki farkı açıkça yansıtır. İlk durumda, sunucu çökmesi istemci çökmesine yol açar ve kurtarma imkansızdır. İkinci durumda, sistemi geri yükleme eylemleri hem mümkün hem de gereklidir. 1. İstemci bir istek 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ı ek yükü, kaynak engelleme, geçerli isteğe verilen yanıtın, sistem yeniden başlatılmadan önce istemci makine tarafından yayınlanan isteğe verilen yanıtla değiştirilmesi.

Yetimlerle nasıl başa çıkılır? 4'ü düşünün Muhtemel çözümler. Yıkım. Bir istemci saplaması bir RPC mesajı göndermeden önce, bundan sonra ne yapacağını söyleyen bir günlük girişi yapar.Günlük, diskte veya diğer hataya dayanıklı bellekte depolanır.

Kilitlenmeden sonra sistem yeniden başlatılır, günlük analiz edilir ve yetimler elenir. Bu yaklaşımın dezavantajları, ilk olarak, her bir RPC'yi diske yazmakla ilişkili artan maliyet ve ikinci olarak, birinci nesil yetimler tarafından yayınlanan RPC'ler tarafından üretilen ikinci nesil yetimlerin ortaya çıkması nedeniyle olası verimsizliktir. Reenkarnasyon Bu durumda, tüm problemler disk yazma kullanılmadan çözülür. Yöntem, zamanı ardışık olarak numaralandırılmış dönemlere bölmekten oluşur. İstemci yeniden başlatıldığında, tüm makinelere yeni bir dönemin başlangıcı hakkında bir mesaj yayınlar.

Bu mesajın alınması üzerine, tüm uzak hesaplamalar sonlandırılır. Elbette ağ bölümlere ayrılırsa bazı yetimler hayatta kalabilir. Yumuşak reenkarnasyon, önceki duruma benzer, ancak tüm uzak hesaplamalar bulunmaz ve yok edilmez, yalnızca yeniden başlatılan istemcinin hesaplamaları bulunur. Son tarih Her talebin, tamamlanması gereken standart bir T süresi vardır.

Talep, ayrılan süre içinde tamamlanmazsa, ek bir miktar tahsis edilir. Bu, ek çalışma gerektirse de, bir istemci çökmesinden sonra sunucu, istemci yeniden başlatılmadan önce bir T aralığı beklerse, o zaman tüm yetimler zorunlu olarak yok edilir.Uygulamada, bu yaklaşımların hiçbiri istenmez; Örneğin, bir yetimin bir veya daha fazla veritabanı dosyasını kilitlediğini varsayalım.

Bir yetim aniden yok edilirse, bu kilitler kalır, ayrıca yok edilen yetimler çeşitli sistem kuyruklarında ayakta kalabilir, gelecekte yeni süreçlerin yürütülmesine neden olabilir vb.

Alınan malzeme ile ne yapacağız:

Bu materyalin sizin için yararlı olduğu ortaya çıktıysa, onu sosyal ağlardaki sayfanıza kaydedebilirsiniz: