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

BİR MESAJ ANAHTARLAMA PROTOKOLÜ İÇİN ÖNERİLEN BİR DENEY

Yazar
Kurum
Tarih
15 Mayıs 1972
Durum
Network Working Group Yorum Talebi
Kanal
protokol/

BİR MESAJ ANAHTARLAMA PROTOKOLÜ İÇİN ÖNERİLEN BİR DENEY

Network Working Group — Bob Bressler
Request for Comments: 333 — MIT/Dynamic Modeling
NIC # 9926 — Dan Murphy
Kategori: C9 (deneysellik) — BBN/TENEX
Yerine Geçer: 62 — Dave Walden
Günceller: yok — BBN/IMP
Tarih: 15 Mayıs 1972

İçindekiler

Giriş

Bir mesaj anahtarlama protokolü (MSP), işlevi mesajları portları arasında anahtarlamak olan bir sistemdir.

Örneğin, her bir Interface Message Processor içinde bir MSP uygulaması bulunmaktadır. Bilgisayar işletim sistemleri tarafından haberleşme ağlarının etkin biçimde kullanılmasının, MSP’lerin daha iyi anlaşılmasını gerektirdiğine inanıyoruz. Özellikle, ARPA Bilgisayar Ağı (ARPANET) üzerinde uygulanmış oldukları şekliyle Network Control Program’ların (NCP’ler), ağ oluşturmanın haberleşme yönlerini yeterince vurgulamadığını düşünüyoruz — yani, sistem uzmanlarının bizim akış yönelimi olarak adlandırdığımız yaklaşımdan uzaklaşma konusundaki belirli bir isteksizliğini yansıtmaktadırlar. Mevcut NCP’ler kullanılarak yapılan ağ geliştirmelerine bir ek olarak, MSP’lerin dikkate alınmasıyla başlayarak NCP düzeyindeki yazılımın tasarımını yeniden düşünmeyi öneriyoruz.

Bu notun temel amacı, ARPANET’teki en alt düzey ana bilgisayar–ana bilgisayar protokolünün MSP’ler etrafında nasıl organize edileceğini ve bu organizasyonun ana bilgisayar yazılımının uygulanmasını nasıl etkileyeceğini ana hatlarıyla ortaya koymaktır.

Bazı Arka Plan Bilgileri

Geçtiğimiz birkaç hafta boyunca, birkaç ARPA Network Ana Bilgisayarında, hat anahtarlama kavramı yerine mesaj anahtarlama kavramına dayanan bir protokolü izleyen NCP’lerin deneysel olarak uygulanabilmesi olasılığı hakkında önemli ölçüde gayriresmî tartışma yapılmıştır (NIC belgesi 8246’nın, Host/Host Protocol for the ARPA Network, 6. sayfasının ilk paragrafındaki parantez içi cümleye bakınız). Bu tartışmaya katılanlar Bob Bressler (MIT/Dynamic Modeling), Steve Crocker (ARPA), Will Crowther (BBN/IMP), Tom Knight (MIT/AI), Alex McKenzie (BBN/IMP), Bob Metcalfe (MIT/Dynamic Modeling), Dan Murphy (BBN/TENEX), Jon Postel (UCLA/NMC) ve Dave Walden’dır (BBN/IMP).

Bu tartışma sırasında birkaç ilginç nokta ve sonuca ulaşılmıştır:

  1. Bressler, Dynamic Modeling PDP-10 için mesaj anahtarlamalı bir süreçler arası haberleşme sistemi geliştirmiş ve bunu, Dynamic Modeling PDP-10 ile AI PDP-10 üzerindeki süreçler arasında süreçler arası haberleşme için kullanılabilecek şekilde genişletmiştir. Bunun, kendi NCP’sinden yaklaşık bir büyüklük mertebesi daha küçük olduğunu bildirmektedir.

  2. Murphy, mesaj anahtarlamaya dayalı bir Host/Host protokolünün deneysel olarak uygulanabileceğini ve deneyler için ayrılmış bağlantıların bir kısmı kullanılarak gerçek Host/Host protokolüyle paralel olarak çalıştırılabileceğini belirtmiştir. Ayrıca Murphy, bu deneysel mesaj anahtarlama protokolü TENEX’te uygulanırsa, çok sayıda (TENEX) sitenin deneye kolayca katılabileceğini ifade etmiştir.

  3. Tartışmaya katılanların ortak görüşü, Bressler’ın bir mesaj anahtarlama protokolü tanımı hazırlamaya girişmesi gerektiği* ve bu tanımın uygulanmasının görece kolay görünmesi hâlinde, Murphy ve Bressler tarafından iki BBN TENEX ile MIT Dynamic Modeling ve AI makinelerinde deneysel protokolün uygulanması için kaynak bulunmasına yönelik ciddi bir çaba gösterilmesi gerektiğidir.

  4. Message Switching Protocol için MSP kısaltması seçilmiş ve MSP deneyi için 192–195 bağlantıları ayrılmıştır.

*Bu not, Bressler’ın bir MSP tanımı üretme yönünde üstlenmiş olabileceği herhangi bir yükümlülüğü yerine getirmektedir.

Bu deneyle ilgili olarak Network Working Group’tan yorum ve öneriler talep ediyoruz. Ancak, yorum ve önerileri büyük ölçüde takdir edecek olmamıza rağmen, bunun sınırlı bir deney olması ve ARPA Network için mevcut Host/Host protokolünün yerini alacak bir protokol tanımlama girişimi olmaması nedeniyle, önerileri keyfi olarak reddedebiliriz.

Kaynaklar

Bu notun geri kalanının okunabilmesi için aşağıdaki kaynaklara aşinalık yararlı olacaktır.

  1. NIC belgesi 8246, Host/Host Protocol for the ARPA Network
  2. Telnet Protokolü üzerine NIC belgesi 9348
  3. NIC belgesi 7101, Official Initial Connection Protocol, Document #2
  4. A system of interprocess communication in a resource sharing computer network, CACM, Nisan 1972.

4 numaralı kaynak, RFC 62’nin bir revizyonudur. Okuyucunun, bu RFC’yi okumaya girişmeden önce 4 numaralı kaynağa aşina olmasını kuvvetle öneririz; 4 numaralı kaynağın bir yeniden basımı ek olarak iliştirilmiştir.

MSP Tanımı

Bizim MSP’miz, dördüncü kaynağın 3. Bölümünde ana hatları verilen süreçler arası haberleşme sisteminin esasen bir genellemesidir. (Bundan sonra, 4 numaralı kaynağın 3. Bölümünde sunulan süreçler arası haberleşme sisteminden söz etmemiz gerekirse, buna IPC diyeceğiz.) İki sürecin MSP kullanarak haberleşebilmesi için, göndermek isteyen sürecin bir anlamda bir SEND yürütmesi ve almak isteyen sürecin de bir anlamda bir RECEIVE yürütmesi gerekir. SEND ve RECEIVE, fiilen bir yerde buluşur ve iletimin gerçekleşmesine izin verilir.

RECEIVE ile birlikte (diğer şeylerin yanı sıra) bir from-port-id, bir to-port-id ve bir buluşma Ana Bilgisayarı belirtilir. SEND ile birlikte ise bir from-port-id, bir to-port-id, bir buluşma Ana Bilgisayarı ve (muhtemelen) iletilecek bazı veriler belirtilir. SEND ve RECEIVE kullanılarak, bir gönderici süreçten bir alıcı sürece mesaj gönderimi aşağıdaki şekilde gerçekleşir.

Gönderici süreç, bir OUT-mesajının ve belirtilen verilerin SEND içinde buluşma Ana Bilgisayarı olarak belirtilen Ana Bilgisayara iletilmesine neden olan bir SEND yürütür. Eşzamanlı olarak (ancak mutlaka aynı anda olmak zorunda değildir), alıcı süreç, bir IN-mesajının RECEIVE içinde buluşma Ana Bilgisayarı olarak belirtilen Ana Bilgisayara gönderilmesine neden olan bir RECEIVE yürütür. Buluşma Ana Bilgisayarında, OUT-mesajları ve IN-mesajları buluşma tablosu adı verilen bir tabloya kaydedilir.

Eşleşen to-port-id, from-port-id ve buluşma Ana Bilgisayarı’na sahip bir OUT-mesajı ile bir IN-mesajı tespit edildiğinde, üç şey yapılır:

  1. OUT-mesajı ve veriler, IN-mesajının kaynağı olan Ana Bilgisayara iletilir.
  2. IN-mesajı, OUT-mesajının kaynağı olan Ana Bilgisayara iletilir.
  3. IN-mesajı ile OUT-mesajı ve veriler, buluşma Ana Bilgisayarındaki buluşma tablosundan silinir.

Buluşma Ana Bilgisayarının, gönderici Ana Bilgisayar ya da alıcı Ana Bilgisayardan biri olması durumunda süreç büyük ölçüde basitleşir. Bu dizileri ayrıntılı olarak sıralayan özgül algoritmalar bu notun ilerleyen bölümlerinde yer almaktadır.

Temel kavramları açıklığa kavuşturmak için, SND, RCV ve RNDZ adlarını vereceğimiz üç Ana Bilgisayarı içeren bir duruma bakalım. SND Ana Bilgisayarında S süreci bir gönderim yapmakta, RCV Ana Bilgisayarında ise R süreci bir alım yapmaktadır. Her ikisi de buluşma noktası olarak RNDZ Ana Bilgisayarını belirtmektedir.

S süreci şimdi aşağıdakilerle bir SEND yürütür:

SND Ana Bilgisayarı daha sonra buluşma tablosunda bir tablo girdisi oluşturur ve S’nin verileriyle birlikte bir OUT mesajını RNDZ Ana Bilgisayarına gönderir.

Eşzamanlı olarak, RCV Ana Bilgisayarındaki R süreci aşağıdakilerle bir RECEIVE yürütür:

RCV Ana Bilgisayarı buluşma tablosunda bir tablo girdisi oluşturur ve RNDZ Ana Bilgisayarına bir IN mesajı gönderir.

(Şimdi ara bir Ana Bilgisayardaki arabelleğe alma konusunda paniğe kapılmayın. Panik zamanı, argümanlarımızın geri kalanını okuyup anladıktan sonradır.)

RNDZ Ana Bilgisayarı, SND Ana Bilgisayarından gelen OUT ile RCV Ana Bilgisayarındaki R’den gelen IN’in birbiriyle eşleştiğini fark eder ve böylece RNDZ Ana Bilgisayarı üç eylem gerçekleştirir:

  1. SND Ana Bilgisayarına bir IN gönderir (from-port-id = S, to-port-id = R, rendezvous-Host = RNDZ).
  2. RCV Ana Bilgisayarına bir OUT ve arabelleğe alınmış verileri gönderir (from-port-id = S, to-port-id = R, rendezvous-Host = RNDZ).
  3. Tablosundaki girdiyi temizler.

RCV Ana Bilgisayarı OUT’u ve verileri alır ve tablosunda eşleşen girdiyi bulur. Verileri R sürecine verir ve tablosundaki girdiyi temizler.

SND Ana Bilgisayarı, tablosundaki bir girdiye uyan bir IN alır ve bu girdiyi temizler. Bu mesaj, S sürecine iletilebilecek birleşik bir onay ve devam sinyali işlevi görür.

İletim artık tamamlanmıştır.

Gönderici ve alıcı süreçlerin her ikisi, biri ya da hiçbiri uzak bir buluşma Ana Bilgisayarı belirtmediğinde, dört önemli farklı iletim türü gerçekleşebilir. Bunlar aşağıdaki dört şekilde gösterilmektedir. Şekillerde, kesişen ya da paralel noktalı çizgiler buluşmayı göstermek için kullanılmıştır. Kesişen buluşmanın yeri, şekillerde gösterilen iletim türleri arasındaki önemli farktır. Daireler süreçleri, dikdörtgenler ise buluşma tablolarını gösterir.

Şekiller ayrıca “IN” ve “OUT” mesajlarının süreçlere aktarılmasını da göstermektedir. Parantezler, IN ve OUT’un süreçlere yalnızca kavramsal olarak aktarıldığını belirtmek için kullanılmıştır. Gerçekte ne olacağı uygulamaya bağlıdır. Süreç, SEND ya da RECEIVE verirken engellendiyse uyandırılabilir ve kendisine başka bir bilgi verilmeyebilir. Süreç kesintiye uğratılabilir ve IN’den to-port-id ya da OUT’tan from-port-id gibi bazı bilgiler aktarılabilir. Sürece gerçekten IN ya da OUT mesajının tamamı da aktarılabilir.

------         _________           ------
     (      )       |         |         (      )
     (      ) SEND  |         | RECEIVE (      )
     (      )------>|--+  +---|<--------(      )
     (      )       |   \/    |         (      )
     (      ) (IN)  |   /\    |  (OUT)  (      )
     (      )<------|--+   +--|-------->(      )
     (______)       |_________| +DATA   (______)

     |<------------- Host K ------------------>|

               Gönderici Ana Bilgisayarında Buluşma

      ----         _______               ______          ----
     (    )       |       |             |      |        (    )
     (    ) SEND  |       |      IN     |      | RECEIVE(    )
     (    )------>|-+  +--|<------------|------|<-------(    )
     (    )       |  \/   |             |      |        (    )
     (    ) (IN)  |  /\   |  OUT+DATA   |      | (OUT)  (    )
     (    )<------|-+  +--|------------>|------|------->(    )
     (____)       |_______|             |______| +DATA  (____)

     |<---- Host K ------>|<-- Network-->|<----- Host L ----->|

               Gönderici Ana Bilgisayarında Buluşma

      ----         ______                _______          ----
     (    )       |      |              |       |        (    )
     (    ) SEND  |      |   OUT+DATA   |       | RECEIVE(    )
     (    )------>|------|------------->|-+  +--|<-------(    )
     (    )       |      |              |  \/   |        (    )
     (    ) (IN)  |      |      IN      |  /\   | (OUT)  (    )
     (    )<------|------|<-------------|-+  +--|------->(    )
     (    )       |      |              |       | +DATA  (    )
     (____)       |______|              |______ |        (____)

     |<---- Host K ----->|<-- Network-->|<----- Host L ----->|

               Alıcı Ana Bilgisayarında Buluşma

  ----         ______            _______            ______         ----
 (    )       |      |          |       |          |      |       (    )
 (    ) SEND  |      | OUT+DATA |       |    IN    |      | RECEIVE(    )
 (    )------>|------|--------->|-+  +--|<---------|------|<------(    )
 (    )       |      |          |  \/   |          |      |       (    )
 (    ) (IN)  |      |    IN    |  /\   | OUT+DATA |      | (OUT) (    )
 (    )<------|------|<---------|-+  +--|--------->|------|------>(    )
 (    )       |      |          |       |          |      | +DATA (    )
 (____)       |______|          |______ |          |______|       (____)

 |<---- Host K ----->|<-- Net -->|<- Host M ->|<-- Net -->|<----- Host L ----->|

               Ara Bir Ana Bilgisayarda Buluşma

SORUNLAR

Zaman Aşımı

Zaman aşımı konusu oldukça çetrefillidir. Tutarlı bir zaman aşımı sistemi her şeyi basitleştirir ve yarış durumlarını ortadan kaldırır. Ancak birçok Ana Bilgisayar, özellikle süresi belirlenmiş zaman aşımlarını kullanmak istememekte ya da kullanamamaktadır.

Bu zaman aşımları olmadan, zaman aşımına uğradığında bir IN ya da OUT’un kaynağına geri giden bir olumsuz onaya muhtemelen ihtiyaç vardır. Ancak bu durum şimdi yarışlara yol açar.

Bir olumsuz onay (bundan sonra FLUSH mesajı olarak adlandıracağız) bir Ana Bilgisayar tarafından şu anlamlarda kullanılabilir:

  1. Tabloımda yer yok.
  2. Artık kullanılabilir arabellek alanım yok, ya da
  3. Tablo girdisini/arabelleği artık tutmak istemiyorum.

Genel olarak, bir Ana Bilgisayarın, mesajları tutmak artık kendisi için uygun olmadığında herhangi bir IN ya da OUT+veriyi atmasına izin verilmesi gerektiğine inanıyoruz. Bu, bir mesajın geliş anında hemen yapılabilir; örneğin, Ana Bilgisayar, kullanıcı arabelleği bulunmayan trafik için arabelleğe alma yapmak istemiyorsa. Zaman aşımlarının yerine, bir süreç SEND ya da RECEIVE verdiği herhangi bir anda, eşleşen RECEIVE ya da SEND’i vererek bunu geri alabilir.

Send ya da Receive Sonrası Sürecin Engellenmesi

Bu, uygulamaya bağlı bırakılan bir sorudur. Genel olarak, bir SEND’den sonra sürecin engellenmesinin iyi bir fikir olduğunu düşünmüyoruz; çünkü süreç başka bir porta başka bir işlem yapmak isteyebilir ya da hatta bir RECEIVE gerçekleştirebilir. Aslında, haberleşen süreçler ne yaptıklarını bildikleri sürece, bir sürecin aynı porta iki ya da daha fazla SEND yapmasında doğası gereği yanlış bir şey görmüyoruz.

Elbette, bazı haberleşen süreçler aynı portlar arasında birden fazla eşzamanlı mesajın aktarımda olmasını yasaklayacaktır; örneğin TELNET’ler bunu pekâlâ yasaklayabilir. Ancak bant genişliğini artırma gibi nedenlerle, iki süreç pekâlâ birden fazla eşzamanlı mesaj isteyebilir. Bu durumda, mesajların sıralanmasıyla ilgili endişelerin süreçlere ait olması gerektiğini düşünüyoruz; bununla birlikte, süreçlerinin mesaj sıralamasını kendilerinin ele almasını isteyen kullanıcıları, BBN Raporu 1822’nin Ek F’sinde belgelenmiş olan IMP/Very Distant Host arayüzünde kullanılan yönteme yönlendiriyoruz.

Mesaj Arabelleğe Alma

Mesaj arabelleğe alma ile ilgili olarak birkaç noktadan bahsetmeye değer. İlk olarak, çoğu OUT muhtemelen veri ile birlikte olacaktır. Dolayısıyla, genel olarak, alıcı süreç takaslanmış olabileceğinden, alıcı Ana Bilgisayar (Host) izleyicisinin bir yerlerde bir miktar veriyi arabelleğe almaya hazır olması gerekir.

Gerekli arabelleğe alma miktarını en aza indirmek için izleyici, IMP’den gelen önceki trafik bir disk veya tambur üzerine yazılana kadar IMP’den gelecek ilave trafiği reddedebilir. Ya da izleyici, belleğin izleyici alanında IMP’den gelen trafik geldikçe doldurduğu ve alıcı süreçler takaslandıkça alıcı süreçler tarafından daha önce talep edilmiş arabelleklerle takas edilen az sayıda arabellek bulundurabilir.

RECEIVE çağrıları hiçbir zaman daha uzun bir mesaj uzunluğu belirtmiyorsa, arabelleklerin maksimum alt ağ mesaj boyutundan daha kısa olabileceğini unutmayın — elbette bu zorunlu kılınabilir. Son olarak, mesaj boyutunun, receive-port-id’nin vb., IMP’den gelen ilk 144 bit içinde mevcut olduğunu not edin. Mesajın geri kalanının hangi arabelleğe okunacağına karar vermeden önce bunu okumak yararlı olabilir.

Pozitif Onaylar

Sistemin içine yerleştirilmiş belirli bir onay biçimi vardır. Alıcı sürecin ne zaman bir RECEIVE yaptığına dair bilgi her zaman mevcuttur. Gönderen Ana Bilgisayar, RECEIVE çağrısı verildiğinde bir IN alacağından emin olur.

Onay ve doğrulamanın daha ileri biçimleri ilk kullanıcı düzeyinde uygulanabilir ve gelişmiş protokoller muhtemelen bu tür yordamların bir kitaplığını geliştirecektir.

MESAJ BAŞLIĞI

Aşağıdaki bölüm, Ana Bilgisayarlar arası (Host-to-Host) mesajların özel biçimini ve verilen bir mesaja uygun yanıtı tanımlayan algoritmaları ele almaktadır.

Her mesaj, aşağıdaki alanları içeren 144 bitlik bir başlıkla başlar:

  1. HOST-to-IMP lideri (32 bit), BBN Reports 1822’de belirtildiği gibi.
  2. Hedef port kimliği (yani mesajı alan portun kimliği) (24 bit).
  3. Mesaj türü (8 bit): IN, OUT, FLUSH vb.
  4. Kaynak port kimliği (yani mesajı gönderen portun kimliği) (24 bit).
  5. Başlatan Ana Bilgisayarın tablo konumu (8 bit).
  6. Bu mesajın kaynağı olan Ana Bilgisayar (8 bit).
  7. Rendezvous Ana Bilgisayarı (8 bit).
  8. Veri bit sayısı (16 bit).

Başlık biçimi, öğenin boyutu sözcük boyutundan büyük olmadığı sürece, 16, 32 ve 36 bitlik sözcüklere sahip makinelerde hiçbir veri öğesinin sözcük sınırını aşmaması için düzenlenmiştir. Sözcükler içindeki baytların gerçek yerleşimi, bu üç sözcük boyutu için aşağıdaki şekillerde gösterilmektedir.

36 bitlik Ana Bilgisayarların yararı için, 0’dan numaralandırıldığında 4. ve 13. baytlar kullanılmamaktadır. 2 ve 3 baytlık öğeler, 16 bitlik makinelerdeki port kimlikleri dışında, sözcük sınırlarını aşmaz. Paketleme ve açma kolaylığına gösterilen bu özen, hem genel kolaylık için hem de Ana Bilgisayarların mesajın geri kalanının nereye gideceğini belirlemek amacıyla başlığı kesme (interrupt) düzeyinde incelemek isteyebilmeleri nedeniyle verilmiştir.

16-bit Ana Bilgisayar Biçimi

   +-------------+-------------+
0  |  HOST/IMP   | DESTINATION |
   |   FLAGS     |             |
   +-------------+-------------+
1  |   LINK      | /////////// |
   |             | /////////// |
   +-------------+-------------+
2  | /////////// |             |
   | /////////// |             |
   +-------------+             |
3  |        TO PORT ID         |
   |                           |
   +-------------+-------------+
4  |  MESSAGE    |             |
   |   TYPE      |             |
   +-------------+             |
5  |        FROM PORT ID       |
   |                           |
   +-------------+-------------+
6  |  TABLE      | /////////// |
   |  POSITION   | /////////// |
   +-------------+-------------+
7  |  SOURCE     | RENDEZVOUS  |
   |   HOST      |   HOST      |
   +-------------+-------------+
8  |        BIT COUNT          |
   |                           |
   +-------------+-------------+
   |                           |
9  |           DATA            |
   //                         //
   |                           |
   +-------------+-------------+

36-bit Ana Bilgisayar Biçimi

   0             8            16            24            32     36
   +-------------+-------------+-------------+-------------+------+
0  | HOST/IMP    |   FOREIGN   |    LINK     | ////////////////// |
   |  FLAGS      |   HOST      |             | ////////////////// |
   +------+------+-------------+-------------+-------+-----+------+
1  | //// |        TO PORT ID                        |  MESSAGE   |
   | //// |                                          |   TYPE     |
   +------+------+-------------+-------------+-------------+------+
2  |               FROM PORT ID              |   TABLE     | //// |
   |                                         |   POSITION  | //// |
   +------+-------------+-------------+------+-------------+------+
3  | //// |   SOURCE    | RENDEZVOUS  |          BIT COUNT        |
   | //// |    HOST     |  HOST       |                           |
   +------+-------------+-------------+---------------------------+
   |                                                              |
4  |                                                              |
   //                          DATA                              //
   |                                                              |
   |                                                              |
   +-------------+-------------+-------------+-------------+------+

32-bit Ana Bilgisayar Biçimi

   +-------------+-------------+-------------+-------------+
0  | HOST/IMP    |   FOREIGN   |    LINK     | /////////// |
   |  FLAGS      |   HOST      |             | /////////// |
   +-------------+-------------+-------------+-------------+
1  | /////////// |             TO PORT ID                  |
   |             |                                         |
   +-------------+-------------+-------------+-------------+
2  |  MESSAGE    |             FROM PORT ID                |
   |   TYPE      |                                         |
   +-------------+-------------+-------------+-------------+
3  |  TABLE      | /////////// |  SOURCE     | RENDEZVOUS  |
   |  POSITION   | /////////// |   HOST      |   HOST      |
   +-------------+-------------+-------------+-------------+
   |        BIT COUNT          |                           |
   |                           |                           |
   +-------------+-------------+                           |
   |                                                       |
   //                   DATA                              //
   |                                                       |
   +-------------+-------------+-------------+-------------+

Host/IMP lideri içindeki alanlar NCP programcılarına zaten tanıdıktır; ancak bu alanlarla ilgili iki noktadan bahsetmeye değer. Birincisi, hedef alan başlangıçta rendezvous Ana Bilgisayarının numarasını içerir. Bir ara sitede rendezvous gerçekleştirildikten sonra, hedef alan mesajın rendezvous yaptığı kaynağı içerir.

İkincisi, MSP deneyi için bağlantı (link) alanı yalnızca 192–195 bağlantı numaralarını içerebilir. MSP kullanılarak gönderilebilecek tüm mesajlar arasında bu dört bağlantının mantıklı bir tahsisini belirlemek için zaman ayırmadık. Bir alternatif, herhangi iki Ana Bilgisayar arasındaki “boru”nun bant genişliğini artırmak için bağlantılar arasında döngü yapmaktır. Şimdilik, bu konuya daha fazla düşünce verilene kadar, bir sitedeki her Ana Bilgisayarın tüm iletişimi için tek ve benzersiz bir bağlantı kullanmasını öneriyoruz.

Mesaj türü alanında temsil etmemiz gereken mesaj türleri şu anda azdır: SEND veya OUT mesajları için mesaj türü 2’yi, RECEIVE veya IN mesajları için mesaj türü 3’ü öneriyoruz. FLUSH kullanılıyorsa, mesaj türü 4 FLUSH mesajıdır.

Rendezvous Ana Bilgisayarı alanı, rendezvous gerçekleştikten sonra alanın gereksiz olması ve o noktadan sonra başka bir amaç için kullanılabilmesi dışında, yoruma ihtiyaç duymaz.

Bit sayısı, bir OUT mesajındaki veri bitlerinin sayısı ya da bir IN mesajındaki giriş arabelleğinin boyutudur (başlık hariç). Böylece gönderen süreç, IN mesajını aldığında, IN mesajındaki bit sayısından OUT mesajındaki verinin ne kadarının alıcı süreç tarafından kabul edildiğini anlayabilir ve isterse mesajın geri kalanını yeniden iletmek için bu bilgiyi kullanabilir. Rendezvous sonrasında, OUT bit sayısı IN bit sayısından büyük olsa bile, mesajdaki tüm verinin IN mesajının kaynağı üzerinden gönderilmesini öneriyoruz. Böylece alıcı Ana Bilgisayarda izleyici, isterse, mesajı fazla uzun olduğu için atma, alıcı sürecin IN yaptığı bit sayısını alıcı sürece gönderip geri kalanını atma ya da geri kalan bitleri kuyruğa alıp alıcı sürece isteyebileceği daha fazla bit olduğunu bir şekilde bildirme seçeneklerine sahip olur.

Hedef ve kaynak port kimliği alanları 24 bitlik sayılardır. Bu boyut TIP’lere yardımcı olmak için seçilmiştir. Bir port kimliğinin ilk sekiz biti, bu port kimliğinin oluşturulduğu Ana Bilgisayarın numarası olmalıdır. Bunun, portun kullanıldığı Ana Bilgisayar olmak zorunda olmadığını özellikle not edin. Bu gereklidir; çünkü rendezvous’lar ara sitelerde gerçekleşir ve portlar siteden siteye taşınabilir. İlk sekiz biti tamamen sıfır olan tüm port kimliklerinin ağ genelinde kullanım için ayrılmasını öneriyoruz. Özellikle, tüm 24 biti sıfır olan bir port kimliği ANY anlamında kullanılacaktır. Bu bize şu seçenekleri verir:

Bu seçeneklerin kullanımına ilişkin örnekler aşağıda verilecektir.

Diğer seçeneklerin (ANY’e RECEIVE) ve (ANY’den SEND) bir ölçüde işe yaramaz olduğunu düşünüyoruz, ancak bunları yasaklamayız. Rendezvous Ana Bilgisayarının açıkça belirtilmediği durumlarda, kullanıcının sistem çağrısında ANY port kimliğinin kullanımının varsayılan rendezvous sitesini aşağıdaki gibi etkilemesi gerektiğine inanıyoruz:

Kimliğin daha az anlamlı 16 biti, bir Ana Bilgisayarın istediği şekilde kullanılabilir. Örneğin, sekiz bit bir süreç kimliği olarak ve sekiz bit de belirtilen süreç içindeki bir kanal tanımı olarak kullanılabilir. Her Ana Bilgisayarın, orta sekiz biti tamamen sıfır olan port kimliklerini iyi bilinen portlar olarak özel kullanımlar için ayırmasını öneriyoruz.

Tablo konumu alanı, kesme düzeyinde maliyetli tablo aramalarını önlemeye yardımcı olmak için eklenmiştir. IN ve OUT gönderen Ana Bilgisayarlar, IN veya OUT ile ilişkili SEND veya RECEIVE’in rendezvous tablo konumunu tablo konumu alanına koyar. Bir ara Ana Bilgisayarda rendezvous sırasında, eşleşen IN ve OUT’taki tablo konumu alanları, mesajlar karşı uca ulaştığında eşleşen SEND ve RECEIVE’in hızlıca bulunabilmesi için yer değiştirilir. MSP’nin rendezvous sırasında bu değiş tokuşu yapması gerekir; ancak elbette MSP’lerin bir IN veya OUT’u ilk iletirken tablo konumu alanını doldurması gerekmez; bu durumda bir IN veya OUT’ta gelen bilgi anlamsız olacaktır. Genel algoritma, bu alanda belirtilen tablo konumunu kontrol etmek ve bu başarısız olursa tüm tabloyu aramaktır.

Kaynak alanı, bu mesajları ilk gönderen MSP tarafından IN ve OUT’larda doldurulur. Rendezvous sırasında, her mesajın kaynağı, son Ana Bilgisayara iletilen mesajda korunur. Bir IN veya OUT bir sürece ulaştığında, süreç kaynak bilgisini, rendezvous Ana Bilgisayarı hakkındaki anlayışını güncellemek için kullanabilir (örneğin hedef Ana Bilgisayar ile rendezvous Ana Bilgisayarı farklı olduğunda).

Örnekler

Tipik Örnek

İletişimin normalde portlara ve portlardan yapılan tanımlamalar kullanılarak ve göndericide rendezvous yapılarak gerçekleştiğini öngörüyoruz. Örneğin, TIP muhtemelen diğer Ana Bilgisayarlara bu yöntemi kullanarak gönderim yapacak ve TIP isteyene kadar kesinlikle diğer Ana Bilgisayarlardan bu şekilde alım yapacaktır. Bu “normal” yöntemde, bir izleyici gelen IN mesajındaki bit sayısına bile bakabilir, bunu bir tahsis olarak kullanabilir ve ardından tam doğru uzunlukta bir OUT mesajını simüle edebilir.

Günlükleme Örneği

Rendezvous’nun alıcıda olduğu, SPECIFIC’e SEND ve ANY’den RECEIVE örneğini düşünün. Bu yöntem, iyi bilinen bir hedef porta sahip bazı günlükleme alıcı süreçleri tarafından kullanılabilir. Örneğin, ağ genelindeki birçok süreçten istatistiklerin gönderildiği bir ölçümler programı.

Program Kitaplığı Örneği

Belirli bir zaman paylaşımlı sistem içinde, ağdaki herhangi bir süreç tarafından kullanılabilen belirli bir kitaplık yordamı olduğunu varsayalım. Kitaplık sürecinin, iyi bilinen bir portta her zaman beklemede olan ANY’den bir RECEIVE’i vardır. Eninde sonunda, bir süreç kitaplık sürecinin iyi bilinen portuna bir mesaj gönderir. Bu mesaj, işlenecek verileri, yanıtı göndermek için kullanılacak bir portu ve parayı içerir. Kitaplık süreci paranın bir kısmını alır ve bunu, kendisi de ANY’den bir RECEIVE’i beklemede olan muhasebe sürecinin iyi bilinen portuna gönderir. Ardından kitaplık süreci verileri işler ve yanıtı, hedefte zaten SPECIFIC’ten bir RECEIVE beklemede olan bir SEND to SPECIFIC mesajı kullanarak hizmeti talep eden sürece geri gönderir. Elbette bu mesajda, yanıtın yanı sıra, talepte bulunan sürecin alacağı herhangi bir para üstü de geri gönderilir.

Bir Yorum

Örneklerimizden görülebileceği gibi, bir ara Ana Bilgisayarda rendezvous yapılmasının nadiren gerçekleştirileceğini düşünüyoruz; bunun başlıca yararı, bir portu taşımak istendiğinde ortaya çıkar. Tüm Ana Bilgisayarların bu amaçla bir miktar (az da olsa) arabelleğe alma sağlamasını görmek isteriz, ancak bunu zorunlu kılmayız. Özellikle bir Ana Bilgisayarın işleyemediği herhangi bir mesajı atabilmesi nedeniyle, bu türden az miktarda arabelleğe alma sağlamak çok da zahmetli olmamalıdır.

TELNET

Biri veri, diğeri kontrol için olmak üzere iki çift yönlü iletişim yolunu sürdüren bir çift Telnet programı varsayalım. Ayrıca, kolaylık olması açısından, port kimliklerinin aşağıdaki gibi olduğunu varsayalım:

Başlangıç durumu, sunucu Telnet’in ANY’den bir READ beklemede olmasıdır.

Kullanıcı Telnet şimdi, veri alanı sunucunun WRITE-CONTROL-ID’sinin port kimliğini içeren bir SEND-TO-SPECIFIC verir. Bu mesaj, kullanıcı Telnet’inin WRITE-CONTROL-ID’sinden gönderilir.

Böylece tüm port kimlikleri kullanıcı Telnet tarafından belirlenmiş olur; dolayısıyla isterse yalnızca tek bir numarayı hatırlaması ve geri kalanını bundan türetmesi yeterlidir. Benzersizlik korunur; çünkü kullanıcı Telnet tarafından sağlanan port kimlikleri, kendi Ana Bilgisayar kimliğini ve kimliği kendisine özgü yapan diğer bilgileri içerir.

Artık bu iletişim yolları kurulduğuna göre, iki süreç yerleşik Telnet protokollerine göre veri ve kontrol bilgisi alışverişi yapabilir.

Bilgi Operatörü

Mesaj Anahtarlama Protokolü (Message Switching Protocol) port kimliklerinin kullanımına ilişkin sabit gereksinimler dayatmaz ve süreç tanımlama problemi, iletişimi gerçekleştirmek için kullanılan araçlardan bir ölçüde ayrıdır. Bununla birlikte, bu konu süreçler arası iletişimin genel meselesinin önemli bir parçasıdır; bu nedenle burada süreç tanımlamanın ele alınması için bir olanak belirtmekteyiz: bilgi işletmeni.

Bir süreç tanımlama şemasındaki hedeflerden biri, süreçlerin kendi tanımlayıcılarını seçebilmelerini sağlayan, benzersizliği garanti edilebilen ve kullanıcı için anlamlı bilgiler içerebilen bir araç sağlamaktır. Verimlilikle ilgili sorunlar, port kimliklerinin bu amacı gerçekleştirecek kadar büyük yapılmasını engeller. Verimlilik sorularını bir kenara bırakırsak, süreçlerin kendilerini tanımlamak için keyfi uzunlukta karakter dizileri kullanmalarına izin vermek ideal görünebilir. Bu durumda benzersizlik, örneğin kullanıcıların süreç tanımlama dizgesine adlarını ekleme geleneğini izlemeleriyle kolayca sağlanabilir. Ayrıca adın geri kalan kısmı, kullanım amacıyla ilişkili bir anlam taşıyacak şekilde seçilebilir; bunun kullanıcılar için açık avantajları ve kolaylıkları vardır.

Bir çözüm, sembolik tanımlayıcıların yalnızca iletişimin bazı ilk aşamalarında kullanıldığı ve her mesajda kullanılmadığı bir geleneğin oluşturulmasıdır. Yani süreçler başlangıçta birbirlerini sembolik tanımlayıcılar kullanarak tanımlar, ancak aynı anda yerel port tanımlayıcılarını da değiş tokuş ederler ve bundan sonraki tüm mesajlarda bu tanımlayıcılar kullanılır.

Bu olanağı sağlamanın yolu, bir dizi Ana Makinede (örneğin tüm sunucu Ana Makinelerde) bilgi işletmeni adı verilen bir sürecin kurulmasıdır. Bu sürecin işlevi, sembolik tanımlama dizgeleri ile port kimliklerini ilişkilendirmektir. Bir süreç kendisini ve/veya yabancı bir süreci bilgi işletmenine tanıtabilir ve yabancı sürecin port kimliğini talep edebilir. Sembolik tanımlama dizgeleri süreçler tarafından seçilir ve anlamlı bilgi içerecek kadar uzundur; örneğin LOGGER, MURPHY-TESTPROG.

Bilgi işletmeniyle iletişim, ister yerel ister uzak süreçler tarafından olsun, normal MSP işlevleri aracılığıyla yapılır. Bilgi işletmeni, iyi bilinen bir portta her zaman beklemede bir RECEIVE ANY bulunduracaktır. Bu porta alınan bir mesaj aşağıdaki parametreleri içerir:

  1. İletişim kurulmak istenen yabancı süreci tanımlayan dizge.
  2. Çağıran süreci tanımlayan dizge.
  3. Çağıran sürecin port numarası.
  4. Bir gecikme belirtimi.

Bu parametrelerin biçimi Şekil 4’te gösterilmiştir. Bazı durumlarda, bağımsız değişkenlerden biri ya da birkaçı boş olabilir. Bir mesaj alındıktan sonra bilgi işletmeni, bazı durumlarda, çağıran sürecin port numarasına istenen bilgiyi ya da bir başarısızlık bildirimini sağlayan bir SEND SPECIFIC gönderir.

Aşağıdaki iki durum, bilgi işletmeninin tüm işlevlerini kapsıyor gibi görünmektedir. Bunlar MSP’nin SEND/RECEIVE SPECIFIC ANY durumlarına karşılık gelir.

  1. Karşılıklı Tanımlama

    Birbirlerinin özel kimliğini bilen iki süreç iletişim kurmak ister. Her biri bilgi işletmenine SEND SPECIFIC yapar ve parametreler 1–2’yi verir; bu durumda varsayılan gecikme belirtimi WAIT’tir. Bilgi işletmeni bu iki mesajdan ikincisini aldığında ve bir eşleşme olduğunu fark ettiğinde, her iki sürece de diğer sürecin port kimliğini gönderir ve her iki dizgeyi ve her iki port kimliğini tablolarından siler. Her biri yabancı port numarasını beklemek üzere bir RECEIVE SPECIFIC yapmış olan bu iki süreç, daha sonra yalnızca port numaralarını ve temel MSP işlevlerini kullanarak iletişim kurabilir.

  2. Hizmet Duyurusu

    Bir süreç, bir tür genel hizmet ya da bilgi sağlamak üzere kurulmuştur ve adı ile protokolü duyurulmuştur. Bu süreç, ilk (ve belki de tek) mesaj işlemi için beklemede bir SEND veya RECEIVE ANY bulundurmayı amaçlar; örneğin daha önce tartışılan kütüphane süreci gibi. Bu tür süreçlerin çoğu başlangıçta alıcı olacaktır, ancak bazı durumlarda bir SEND beklemede bırakılabilir ve zorlayıcı bir süreç gelip bilgiyi alabilir.

    Her iki durumda da hizmet süreci, bilgi işletmenine yerel sembolik kimliği ve yerel port kimliğini vererek SEND SPECIFIC yapar. Yabancı sembolik kimlik boş olur ve varsayılan gecikme belirtimi NO-WAIT’tir:

    • INFO (–, yerel kimlik, yerel port)

    Bilgi işletmeni bu bilgileri tablolarına girer ancak çağırana hiçbir şey döndürmez. Çağıran süreç, iş beklemek için SEND/RECEIVE ANY yapmaya devam eder.

    Başka bir süreç duyurulan hizmeti kullanmak istediğinde, bilgi işletmeninden hizmet sürecinin port kimliğini ister:

    • INFO (hizmet kimliği, –, yerel port)

    Yerel sembolik kimliğin belirtilmesi gerekmez ve varsayılan gecikme belirtimi NO-WAIT’tir. Bilgi işletmeni, hizmet sürecinin port kimliğini çağıranın yerel portuna SEND eder ve tablo girdisini gelecekteki çağıranlar için saklar. Yalnızca hizmet süreci, girdinin silinmesini talep edebilir. Bu çağrı sırasında hizmet kimliği bilgi işletmeni tarafından bilinmiyorsa, bilgi işletmeni derhal bir başarısızlık göstergesi, yani sıfır döndürür.

İletişim kuran süreçler normalde birinin ya da diğerinin yerel bilgi işletmenini kullanır ve MSP’deki randevu Ana Makinesi gibi, bu önceden kararlaştırılır. Hizmet süreçleri normalde kendi yerel sitelerindeki bilgi işletmenini kullanır; buna karşılık kullanıcı süreçleri, hizmet sürecinin mevcut olmasının beklendiği sitedeki bilgi işletmenini çağırır. Elbette başka bir sitedeki bilgi işletmeninin kullanılmasına dair bir kısıtlama yoktur ve bazı küçük ve/veya tembel sunucular hizmet süreçlerinin kimlikleri için farklı bir Ana Makine kullanabilir. İki ya da daha fazla bilgi işletmeninin aynı hizmet süreci için girdilere sahip olması sorun oluşturmaz; hatta ağ üzerinde yalnızca bir yerde bulunan ve zaman zaman yer değiştirebilen özel türdeki hizmet süreçleri için bu oldukça arzu edilir olabilir.

Süreçler kendi yerel port numaralarını belirtir ve her sistemin kullanıcı süreçlerinin bunu yapmasına yardımcı olacak bir yol sağlaması gerekir. Örneğin TENEX’te, büyük olasılıkla iş numarası, iş içinde atanan başka bir numarayla birleştirilerek kullanılırdı. Bilgi işletmeni port numaraları sağlayamaz; çünkü iletişim kuranlardan birinin ya da her ikisinin çalıştığı Ana Makineden farklı bir Ana Makinede çalışacaktır ve o Ana Makine için benzersiz bir numaranın ne olduğunu bilemez. Bazı durumlarda süreçler, yerel port kimlikleri için (aşağıda tanımlanan) “benzersiz numara süreci”nden ister ve bunu bilgi işletmeni aracılığıyla duyurur.

Gerçek uygulamada, dünyadaki tek “iyi bilinen” portun bilgi işletmeni olduğu kuralına birkaç istisna yapılır. Bu tür istisnalar, birçok Ana Makinede ortak olan süreçlerdir; örneğin LOGGER ya da özellikle çok sık kullanılanlar. Bu durumlarda benzersiz port numaraları idari kararla atanır ve tüm kullanıcılara kaydedilip yayımlanır.

Sembolik tanımlama dizgelerinin, sonu bir null (tümü sıfırlardan oluşan bir bayt) ile biten 1 ila 39 (keyfi bir üst sınır) ASCII karakterden oluştuğu belirtilmiştir. Karakterler, yüksek anlamlı bit sıfıra ayarlanmış 8 bitlik baytlarda 7 bitlik ASCII olacaktır. Hiçbir bağımsız değişken gerekmediğinde boş bir dizge (ilk bayt null) kullanılır.

Bilgi İşletmeni Mesajlarının Biçimi

Bilgi İşletmenine: 8 bitlik baytlardan oluşan bir akış.

+------+--//---+------+------+--//---+------+------+-------+-------+
|char 0| 1// n | null |char 0| 1// n | null | port | number| delay |
|      |  //   |      |      |  //   |      |      |       | spec  |
+------+--//---+------+------+--//---+------+------+-------+-------+
 \                   /\                     /\             /\      /
  \_________________/  \___________________/  \___________/  \____/
      PARAMETER 1         PARAMETER 2           PARAMETER 3   PARAMETER 4

Verilen parametreler:

  1. İletişim kurulmak istenen yabancı süreci tanımlayan dizge. (1 ila 39 karakter ya da boş)
  2. Çağıran süreci tanımlayan dizge. (1 ila 39 karakter ya da boş)
  3. Çağıran sürecin port numarası.
  4. Gecikme belirtimi:
    • 0 = varsayılan
    • 1 = eşleşme için bekle
    • 2 = eşleşme için bekleme

Bilgi İşletmeninden: 3 adet 8 bitlik bayt.

+--------+-------+-------+
| byte 0 |   1   |   2   |
+--------+-------+-------+

Başarılıysa istenen yabancı portun port numarası (24 bit), başarısızsa 0.

Benzersiz Port Numaraları

Benzersiz port numaralarının varlığı MSP’nin çalışması için gereklidir. Örneğin, iletişim kuran iki süreç bir ara sitede mesaj randevusu belirttiğinde, süreçler aynı sitede mesaj randevusu belirtmiş diğer süreçler tarafından kullanılmayan giriş ve çıkış portlarını belirtebilmelidir; aksi halde mesajlar yanlış hedeflere teslim edilebilir. Bu notun daha önceki bölümlerinde benzersiz port numaraları sağlamanın bir yöntemine değinmiştik. Bu yöntem, 24 bitlik port numarası alanını ayrık bölümlere ayırmak ve her Ana Makineye, benzersiz bir port kimliği oluşturmak üzere çağrıldığında dağıtması için bir bölüm vermektir.

Böylece her 24 bitlik Ana Makine numarası iki ana bölümden oluşacaktır. İlk 8 bit, port kimliğini oluşturan Ana Makinenin numarasıdır; sonraki 16 bit ise oluşturan Ana Makinenin dilediği şekilde kullanılabilir. Bu, her Ana Makineye dağıtması için 2^16 port numarası verir ve her Ana Makine, port numarası alanının kendi bölümünü benzersiz bir biçimde dağıtma yükünü taşır. Orta 8 bitin sıfıra eşit olduğu port numaralarının, oluşturan Ana Makinenin sistemindeki iyi bilinen portlar için ayrılmasını öneriyoruz. Daha önceki bir bölümde, ilk 8 bitin sıfıra eşit olduğu port numaralarının ağ genelinde kullanım için ayrılmasını ve özellikle tüm 24 bitin sıfıra eşit olduğu port numarasının ANY anlamında kullanılmasını zaten önermiştik.

Her Ana Makinenin dağıtacak yalnızca 2^16 port numarası olduğundan, genel olarak port numaraları süreçler tarafından uzun süreler (örneğin haftalar ve aylar) boyunca tutulup kullanılamayacaktır. Daha tipik olarak, Ana Makinenin sistemi her kapandığında, Ana Makine dağıttığı tüm port numaralarını örtük olarak “geri alacak” ve sistem tekrar ayağa kalktığında gerektikçe port numaralarını yeniden dağıtacaktır. Başka bir deyişle, port numaraları oluşturan Ana Makinelerin kapanıp açılması boyunca genel olarak benzersiz kalmayacaktır. Elbette belirli bir Ana Makine, her açılışında bazı standart süreçlere (örneğin FORTRAN derleyicisi gibi) aynı port numaralarını vermeyi sağlayabilir; bilgi işletmenine kaydedilen port numaraları sıklıkla sistem kapanışları ve açılışları boyunca sabit kalacaktır.

Her Ana Makinenin, uzun bir süre boyunca benzersiz kalması garanti edilebilecek port numaralarını keyfi kullanıcı süreçlerine dağıtamayacak olmasına rağmen, yine de uzun vadeli benzersiz port numaralarının sağlanmasına yönelik bir talep olacaktır. Bazılarına göre bilgi işletmeni üzerinden geçme yordamı, fazlasıyla bağlantı kurmaya benzemektedir. Bu kişiler, çeşitli nedenlerle süreçlerinin tanımlayıcıları uzun süreler boyunca sabit kalan portlar üzerinden iletişim kurmasına izin verilmesini isteyecektir.

Bu nedenle, ağda bir ya da iki yerde uzun vadeli benzersiz numara hizmetinin sağlanması iyi olurdu. Bu hizmeti sağlayan bir sürece Benzersiz Numara Süreci (Unique Number Process) diyelim. Benzersiz Numara Sürecine, benzersiz port numarası alanının bir bölümü atanacaktır—örneğin ilk 8 bitin 377₈ olduğu tüm port numaraları. Bu süreç, yerel randevu belirtilmiş iyi bilinen bir porttan ANY’e SEND beklemede bulunduracaktır. Herhangi bir süreç, tüm zamanlar boyunca ya da numara geri verilene kadar kullanılmayacağına güvenebileceği benzersiz bir numara istediğinde, Benzersiz Numara Sürecinin iyi bilinen portunu belirten bir RECEIVE-from-SPECIFIC gönderir ve Benzersiz Numara Sürecinin Ana Makinesinde randevu yapar. Benzersiz Numara Sürecinin beklemedeki SEND-to-ANY’i benzersiz bir numara içerecektir.

Ayrıca Benzersiz Numara Süreci, yerel randevu belirtilmiş başka bir iyi bilinen portta her zaman beklemede bir RECEIVE-from-ANY bulunduracaktır. Bu portta Benzersiz Numara Süreci, süreçlerin geri verdiği benzersiz numaraları alır. Benzersiz Numara Süreci, her bir benzersiz numarasının durumunu (boş ya da kullanımda) gösteren, 2^16 bit uzunluğunda bir bit tablosunu dosya sistemi gibi uzun vadeli bir depolama ortamında tutacaktır. Benzersiz Numara Süreci ayrıca, benzersiz numara verdiği her süreç hakkında bazı bilgiler de tutabilir; böylece benzersiz numara arzı tükendiğinde süreçlerden bunları geri vermeleri istenebilir.

Bilgi işletmeninde sembolik adlarıyla birlikte kaydedilen bazı süreç kimliklerinin, Benzersiz Numara Sürecinden alınmış uzun vadeli benzersiz numaralar olabileceği daha önce belirtilmişti. Ayrıca, önceki bölümde süreç kimliği olarak adlandırılan ve bir sürece birincil erişimin sağlandığı port numarasına ek olarak, keyfi port numaralarının sembolik tanımlayıcılarıyla birlikte bir bilgi işletmenine kaydedilememesi için, depolama alanı kıtlığı dışında, herhangi bir neden olmadığı da belirtilmelidir.

Örneğin BBN-FORTRAN adını ve tek bir port numarasını kaydetmek yerine, sembolik tanımlayıcıları aşağıdaki gibi olan port numaraları kaydedilebilir:

Bu, işletim sistemleri içindeki standart uygulamayla bir ölçüde çelişebilir; ancak iletişimin süreçlerle değil portlarla yapıldığı yönündeki 4 numaralı referansın felsefesiyle tutarlıdır.

Port Koruması

Şimdiye kadar göz ardı edilmiş ve yalnızca 4 numaralı referansta üstü kapalı biçimde değinilmiş bir konuyu, port koruması konusunu ele alalım. Bu konu üzerinde çok fazla düşünmedik; ancak port koruması için bir mekanizma oldukça yalın görünmektedir. Bu mekanizmanın özü, her Ana Makinede bulunan ve (aliteratif olarak) Port Koruma Süreci (Port Protection Process, PPP) adını vereceğimiz bir süreçtir.

PPP, Ana Makinede var olan tüm süreçlerin bir listesini tutar ve her süreç için, sürecin yasal olarak elde ettiği tüm portların numaralarını kaydeder. Bir süreç her SEND ya da RECEIVE yaptığında, izleyici (monitor) PPP ile denetim yaparak sürecin kullanma hakkına sahip olduğu, yani yasal olarak elde edilmiş port numaralarını belirtip belirtmediğini kontrol eder.

PPP, iyi bilinen portlarda her zaman beklemede olan bazı RECEIVE’lere sahiptir. Bir süreç bir portu başka bir sürece aktarmak istediğinde, ilk süreç PPP’ye gönderilecek portun numarasını, ikinci sürecin bulunduğu Host numarasını, ikinci sürecin portu almayı beklediği portu vb. belirten bir mesaj gönderir. PPP, tablolarında ilk sürecin göndermek istediği porta sahip olup olmadığını arar. Eğer sahipse, hedef sitedeki PPP’ye bir mesaj gönderir. Bu mesaj, aktarılacak portun numarasını ve hedef süreç için RECEIVE portunu içerir.

Hedefteki PPP, tablolarında sürecin RECEIVE portuna sahip olup olmadığını denetler ve eğer öyleyse yeni portu sürece iletir ve tablolarını sürecin artık yeni porta sahip olduğunu gösterecek şekilde günceller. Bir PPP’ye gönderilen mesajlar, isteğe bağlı olarak bir portun kopyasının gönderilmesini, bir portun silinmesini vb. de belirtebilecektir. PPP’lerin muhtemelen her süreç için bazı yerleşik yasal portları olacaktır; özellikle süreçlerin PPP ile iletişim kurmak için kullandıkları portlar.

Kesin belirtim geliştirme gerektirir, ancak bunun zor olmaması gerekir (bkz. referans 4’te (3), (6) ve (7)). Gördüğümüz temel zorluk, her RECEIVE veya SEND için izleyicinin (monitor) PPP tablolarını etkin biçimde denetlemesi, bunu yaparken izleyicinin mevcut koruma sistemini tamamen ortadan kaldırmamasıdır.

Akış Diyagramı

Aşağıdaki bölüm MSP’nin büyük bir kısmı için bir akış diyagramını açıklar. Yerel süreçler tarafından yapılan ve SEND ile RECEIVE olarak adlandırılan çağrılar ile NET üzerinden gelen ve IN ve OUT olarak adlandırılan mesajlar arasında bir ayrım yapılır. Ayrıca, yerel bir randevusu olan çağrılar (veya mesajlar) ile yabancı bir randevu Host’u olanlar arasında da bir ayrım yapılır.

Kod oldukça benzer olduğundan, bu ayrımın yapılması şart değildir, ancak açıklık sağlamak amacıyla dahil edilecektir.

MSP’nin aşağıdaki öğeler için tablo düzeneklerine sahip olduğu varsayılmaktadır:

Kullanıcı Bir SEND veya RECEIVE Yapar

A. Randevu Yabancı Bir Host’tadır

  1. Uygun tablo verilerini sakla.
  2. Randevu Host’una bir mesaj gönder:
    • SEND: OUT + DATA
    • RECEIVE: IN

B. Randevu Yereldir — Tabloda Giriş Ara

  1. Giriş bulunamazsa: uygun verilerle giriş oluştur.
  2. Tabloda eşleşen bir giriş varsa:
    • RECEIVE: veriyi kullanıcıya ver.
    • Diğer Host’a bir mesaj gönder (orijinal mesajın kaynak alanında belirtildiği gibi):
      1. SEND: OUT + DATA
      2. RECEIVE: IN
    • İşlemin tamamlandığı konusunda kullanıcıyı uyar.
    • Tablo girişini temizle.

NET Üzerinden Bir IN Alınır — Eşleşen Giriş İçin Tabloyu Ara

A. Eşleşen Giriş Yok

B. Bir Eşleşme Var

  1. Giriş yerel bir SEND nedeniyle oluşmuştur:

    • IN’in kaynağına OUT + DATA gönder.
    • Kullanıcıyı işlem hakkında bilgilendir.
    • Tablo girişini temizle.

  2. Giriş, NET üzerinden alınan bir OUT nedeniyle oluşmuştur — üçüncü bir Host olarak davranır:

    • IN’i tablo girişini oluşturan siteye gönder.
    • OUT + DATAyı (önceden arabelleğe alınmış) IN’i gönderen siteye gönder.
    • Tablo girişini temizle.

NET Üzerinden Bir OUT + DATA Alınır — Eşleşen Giriş İçin Tabloyu Ara

A. Eşleşme Bulunmaz

  1. Veriyi arabelleğe al.
  2. Uygun tablo bilgilerini oluştur.

B. Bir Eşleşme Bulunur

  1. Tablo girişi yerel olarak yürütülen bir RECEIVE nedeniyle oluşmuştur:

    • Veriyi kullanıcıya ver ve varlığı konusunda onu uyar.
    • OUT’un kaynağına eşleşen bir IN gönder.
    • Girişi tablodan kaldır.

  2. Tablo girişi NET üzerinden bir IN alınmasıyla oluşmuştur; dolayısıyla üçüncü taraf bir Host olarak davranır:

    • OUT + DATAyı tabloda saklanan Host’a gönder.
    • OUT’un az önce geldiği Host’a bir IN gönder.

MSP Varyasyonları

Mevcut olana ulaşırken değerlendirdiğimiz diğer MSP’lerden bazılarını bilmek okuyucunun ilgisini çekebilir.

Değerlendirdiğimiz en basit olanı, tüm randevuların hedef Host’ta yapılmasına dayanan bir MSP’dir. Gönderici süreç, OUT mesajını verilerle birlikte hedef Host’a gönderir. Alıcı süreç, alıcının Host’unda kalan bir IN yapar. OUT ve RECEIVE randevulaşır ve veri alıcı sürece aktarılır. İletim artık tamamlanmıştır; ancak bu MSP’nin bazı varyasyonlarında gönderici sürece bir onay gönderilir.

Bu MSP’nin birkaç dezavantajı vardır. En basit formülasyonda, OUT ve veriler geldiğinde RECEIVE’in beklemede olması gerekiyordu; aksi takdirde OUT verileri atılıyordu. Bu durum, özellikle gönderici ve alıcı süreçlerin kıtalarca uzakta olabildiği düşünülürse, SEND ve RECEIVE zamanlamasına çok sıkı bir kısıt getirir. Ancak IN’in önce gelmesine ve bir RECEIVE ile eşleşene kadar tutulmasına izin verilirse, izleyicinin normal durum da dahil olmak üzere her durumda belirsiz miktarda veriyi arabelleğe alması gerekir. Ayrıca her şeyi hedefte randevuya dayandırmak, bir portu taşıma sürecini zorlaştırır.

Değerlendirdiğimiz bir sonraki en basit MSP, referans 4’teki IPC’dir. Bu, yukarıda açıklanan MSP’nin tam tersine çalışır; neredeyse tüm randevuların kaynak Host’ta yapılmasına dayanır ve randevunun hedefte veya ara bir Host’ta yapılması gereken nispeten nadir durumları ele almak için iki özel mesaj içerir. Bu sistem, avantajları ve dezavantajları referansta çok ayrıntılı biçimde tartışılmaktadır.

RFC 333 — Message Switching Protocol Experiment (Mayıs 1972)

Crowther tarafından önerilen MSP’nin üçüncü bir varyasyonu, OUT ve IN’in süreç tarafından belirtilen bir randevu Host’ta randevulaşması ve OUT’un IN’in kaynağına, IN’in de OUT’un kaynağına gönderilmesi bakımından mevcut MSP ile aynıdır; ancak veriler OUT ile birlikte gönderilmez. Bunun yerine, OUT nihayet IN’in kaynağına ulaştığında, alıcı Host’tan kaynak Host’a verinin gönderilmesini isteyen başka bir mesaj gönderilir. Veri, bu veri isteği mesajına yanıt olarak sonunda hedefe iletilir.

Bu sisteme yönelik temel itirazımız simetri eksikliğidir; ancak bir sürecin bir giriş arabelleği kurmadığı veriler için herhangi bir Host’un arabelleğe alma yapmasını gerektirmediğini kabul ediyoruz ve belki de bu nedenle sunduğumuz MSP’den daha iyi bir sistemdir.

Değerlendirdiğimiz son MSP varyasyonunda, SEND veya RECEIVE ile OUT veya IN arasındaki fark ortadan kaldırılmıştır. Bu durumda yalnızca TRANSFER adını vereceğimiz tek bir mesaj kullanılır. Bir süreç bir TRANSFER yürüttüğünde, bir giriş arabelleği, bir çıkış arabelleği, her ikisini veya hiçbirini belirtebilir. İletişim kurmak isteyen iki süreç, aynı to- ve from-port ID’lerini ve aynı randevu Host’unu belirterek TRANSFER’ler yürütür. TRANSFER’ler, bir çıkış arabelleği belirtilmişse, verilerle birlikte TRANSFER mesajları üretir ve bunlar randevu Host’ta randevulaşır. Randevu gerçekleştiğinde, TRANSFER mesajları ve verileri karşılıklı geçiş yapar ve her biri diğerinin kaynağına gönderilir.

Bu sistem, süreçlerin SEND mi yoksa RECEIVE mi yapmaları gerektiğini bilmemelerine olanak tanır ve (belki de) bu notta sunulan MSP’nin hoş bir genellemesidir. Örneğin, iki süreç bu sistemi kullanarak veri alışverişi yapabilir ya da iki süreç verisiz TRANSFER’ler göndererek bir tür karşılıklı kesme gerçekleştirebilir. MSP’nin bu varyasyonu, Steve Crocker’ın bir önerisinin geliştirilmiş bir biçimidir.

Dezavantajları şunlardır:

  1. İstemeden gerçekleşen eşleşmelerin oluşma olasılığı daha yüksektir.
  2. Randevu seçim sitesi daha karmaşıktır.
  3. Üzerinde düşünmesi zordur.

Ek

Kaynak Paylaşımlı Bir Bilgisayar Ağında Süreçler Arası İletişim için Bir Sistem. Communications of the ACM, Nisan 1972.

Bu makalenin yeniden basımı için izin, Association for Computing Machinery’nin izniyle verilmiştir. (RFC 333’ün yeniden yayımlanan sürümünde çıkarılmıştır.)

Not: Aşağıdaki makalenin 4. bölümündeki fikirler, 3. bölümde geliştirilen fikirler açısından hiçbir şekilde kritik değildir — DCW.