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

Host-Host Protokolünde Önerilen Değişiklik

Yazar
Kurum
Tarih
20 Şubat 1973
Durum
Network Working Group Yorum Talebi
Kanal
protokol/

Host-Host Protokolünde Önerilen Değişiklik

Bağlantı Durumunun Yeniden Eşzamanlanması

Network Working Group — J. Burchfiel
Request for Comments: 467 — R. Tomlinson
NIC: 14741 — Bolt Beranek and Newman
Tarih: 20 Şubat 1973

I. Giriş

Mevcut Host-Host protokolü (NIC #8246), her bağlantının iki ucunda tutulan durum bilgisinin yeniden eşzamanlanmasına yönelik herhangi bir düzenleme içermemektedir. Özellikle, ana makinelerden biri bir hizmet kesintisi yaşarsa ya da bir denetim iletisi bir arabirimde veya alt ağda kaybolur ya da bozulursa, bağlantının iki ucundaki durum bilgileri tutarsız hale gelir.

Mevcut protokol bu durumu düzeltmek için hiçbir yol sağlamadığından, iki uçtaki NCP’ler sonsuza kadar “şaşkın” durumda kalır. Bu etkinin sık rastlanan ve can sıkıcı bir belirtisi, alıcı NCP’nin bekleyen bit ve ileti tahsisleri olduğuna inanırken, gönderici NCP’nin herhangi bir tahsis olmadığını düşündüğü “kayıp tahsis” olgusudur. Bunun sonucu olarak, bu bağlantı üzerinden bilgi akışı hiçbir zaman yeniden başlatılamaz.

Host-Host RST (reset) komutunun kullanılması burada uygun değildir, çünkü iki ana makine arasındaki tüm bağlantıları yok eder. Gerekli olan, diğer bağlantıları etkilemeden yalnızca sorunlu bağlantıyı sıfırlamanın bir yoludur.

Durum bilgisindeki tutarsızlığın ikinci bir sorunlu belirtisi “yarı kapalı” bağlantıdır: bir hizmet kesintisi ya da ağın bölünmesinden sonra, bir NCP bağlantının hâlâ açık olduğuna inanırken diğeri bağlantının kapalı olduğuna (mevcut olmadığına) inanabilir. Böyle bir tutarsızlık fark edildiğinde, bağlantının “açık” olan ucu kapatılmalıdır.

II. RCR ve RCS Komutları

Tahsislerin yeniden eşzamanlanmasını sağlamak için, host-host protokolüne aşağıdaki iki komutun eklenmesini öneriyoruz.

     8           8
+-----------+-----------+
|    RCS    |   link    |   Gönderici tarafından bağlantıyı sıfırla
+-----------+-----------+

     8           8
+-----------+-----------+
|    RCR    |   link    |   Alıcı tarafından bağlantıyı sıfırla
+-----------+-----------+

RCS komutu, “link” üzerinde gönderim yapan ana makineden, “link” üzerinde alım yapan ana makineye gönderilir. Bu komut, gönderici ana makinenin bağlantıyla ilişkili durum bilgisini yeniden eşzamanlamak istediği herhangi bir zamanda gönderilebilir. Gönderici ana makinenin bunu yapmayı seçebileceği bazı durumlar şunlardır:

  1. Taşınacak trafik varken ancak tahsis yokken oluşan bir zaman aşımından sonra (bir tahsisin kaybolduğu varsayılır).
  2. Bu bağlantıyla ilişkili tutarsız bir olay meydana geldiğinde (örneğin, 2^32 bitten veya 2^16 iletiden fazla bekleyen bir tahsis).

Tahsislerin yeniden eşzamanlanmasının işleyişi basitçe şöyledir:

  1. “Boru hattı”ndaki tüm iletileri ve tahsisleri boşaltmak.
  2. Bit ve ileti tahsisini gösteren değişkenleri her iki uçta da sıfırlamak.
  3. Tahsis/ileti değişimlerini normal şekilde yeniden başlatmak.

Bu yeniden eşzamanlama düzeni, RCS ve RCR komutları olumlu bir onay çifti olarak kullanıldığı için yarış koşullarına karşı güvenlidir.

III. Gönderici Tarafından Yeniden Eşzamanlama

Yeniden eşzamanlamayı başlatmak için, gönderici NCP şunları yapmalıdır:

  1. Bağlantıyı “RCR-yanıtı-bekleniyor” durumuna almak. RCR yanıtı alınana kadar bu bağlantı üzerinden artık normal iletiler gönderilemez.
  2. İleti boru hattı boşalana kadar beklemek; yani bu bağlantı üzerinden gönderilen her normal ileti için bir RFNM alınana kadar beklemek. Bu, denetim ve veri etkinliğini eşzamanlar ve ayrıca denetim yeniden eşzamanlama değişimi sırasında veri akışının bozulmayacağını garanti eder.
  3. RCS komutunu göndermek.
  4. Bit ve ileti tahsislerinin bekleyen durumunu gösteren değişkenleri güncelleyerek tahsisleri normal şekilde işlemeye devam etmek.

Alıcı NCP RCS’yi aldığında şunları yapmalıdır:

  1. Bekleyen bit ve ileti tahsisini gösteren değişkenleri sıfırlamak.
  2. Bağlantıyı bir ileti kabul etmeye hazır olduğunu gösteren duruma sıfırlamak.
  3. Yeniden eşzamanlamayı doğrulamak için RCR yanıtını göndermek.
  4. Bit ve ileti tahsisini yeniden değerlendirmek ve yapmak istediği her tahsis için bir ALL komutu göndermek.

Gönderici ana makine RCR yanıtını aldığında şunları yapmalıdır:

  1. Bekleyen bit ve ileti tahsisini gösteren değişkenleri sıfırlamak.
  2. Gelebilecek ALL komutlarına hazırlık olarak bağlantıyı “ileti-göndermeye-hazır” durumuna almak.

Bu noktada boru hattında ne ileti ne de tahsis vardır ve her iki uçtaki bekleyen tahsis değişkenleri (sıfır değerinde) birbiriyle uyumludur.

IV. Alıcı Tarafından Yeniden Eşzamanlama

Yeniden eşzamanlama dizisi alıcı NCP tarafından tetiklenebilir. Böyle bir yeniden eşzamanlama, çıktı bekleyen ancak hiçbir şey almayan TIP ve TELNET kullanıcıları tarafından elle başlatılabilir. Yine bir tahsisin kaybolduğu varsayılarak, uygun eylem RCR komutu göndererek bağlantıyı sıfırlamaktır. Bu eylem, bağlantıyla ilgili tutarsız bir olay meydana geldiğinde de uygundur (örneğin, tahsisi aşan bir iletinin gelmesi).

Yeniden eşzamanlamayı başlatmak için, alıcı NCP şunları yapmalıdır:

  1. Bağlantıyı “RCS-yanıtı-bekleniyor” durumuna almak. RCS yanıtı alınana kadar bu bağlantı için artık tahsis gönderilemez.
  2. RCR komutunu göndermek.
  3. Bit ve ileti tahsislerinin bekleyen durumunu gösteren değişkenleri güncelleyerek normal iletileri işlemeye devam etmek.

Gönderici NCP RCR komutunu aldığında şunları yapmalıdır:

  1. İleti boru hattı boşalana kadar beklemek; yani bağlantı üzerinden gönderilen her normal ileti için RFNM alınana kadar beklemek. Bu, denetim ve veri etkinliğini eşzamanlar ve ayrıca denetim yeniden eşzamanlama değişimi sırasında veri akışının bozulmayacağını garanti eder.
  2. Bekleyen bit ve ileti tahsisini gösteren değişkenleri sıfırlamak.
  3. Gelebilecek ALL komutlarına hazırlık olarak bağlantıyı “ileti-göndermeye-hazır” durumuna almak.
  4. Yeniden eşzamanlamayı doğrulamak için RCS yanıtını göndermek.

Alıcı ana makine RCS yanıtını aldığında şunları yapmalıdır:

  1. Bekleyen bit ve ileti tahsisini gösteren değişkenleri sıfırlamak.
  2. Bağlantıyı bir ileti kabul etmeye hazır olduğunu gösteren duruma sıfırlamak.
  3. Bit ve ileti tahsisini yeniden değerlendirmek ve yapmak istediği her tahsis için bir ALL komutu göndermek.

V. Eşzamanlı Yeniden Eşzamanlama

Yeniden eşzamanlama değişimi için bu belirtim, iki uçtaki tahsis bilgisini tutarlı bir duruma geri getirmeyi garanti eder. Bu, yeniden eşzamanlama gönderici, alıcı ya da her ikisi tarafından aynı anda tetiklense bile doğru şekilde gerçekleşir. Her iki uç da aynı anda bir komut başlattığında (RCS ve RCR komutları boru hattında birbirini geçtiğinde), her biri karşı tarafın komutunu bir onay yanıtı olarak yorumlar; böylece yeniden eşzamanlama, göreli zamanlamadan bağımsız olarak doğru şekilde gerçekleşir.

Buradaki temel etken, uçlardan biri sıfırlama isteğini aldığında, diğer ucun tahsis değişkenlerini etkileyebilecek başka hiçbir eylemde bulunmayacağından emin olmasıdır. Her iki uç tarafından eşzamanlı yeniden eşzamanlama sırasında gerçekleşen etkinlik aşağıdaki gibidir:

Gönderici NCP:

  1. Bağlantıyı “RCR-yanıtı-bekleniyor” durumuna alır. RCR yanıtı alınana kadar bu bağlantı üzerinden artık normal iletiler gönderilemez.
  2. İleti boru hattı boşalana kadar bekler; yani bu bağlantı üzerinden gönderilen her normal ileti için RFNM alınana kadar bekler. Bu, denetim ve veri etkinliğini eşzamanlar ve ayrıca denetim yeniden eşzamanlama değişimi sırasında veri akışının bozulmayacağını garanti eder.
  3. RCS komutunu gönderir.
  4. Bit ve ileti tahsislerinin bekleyen durumunu gösteren değişkenleri güncelleyerek tahsisleri normal şekilde işlemeye devam eder.

Eşzamanlı olarak, alıcı NCP:

  1. Bağlantıyı “RCS-yanıtı-bekleniyor” durumuna alır. RCS yanıtı alınana kadar bu bağlantı için artık tahsis gönderilemez.
  2. RCR komutunu gönderir.
  3. Normal iletileri işlemeye devam eder.

RCS ve RCR komutları boru hattında bir yerde birbirini geçer. Gönderici RCR komutunu aldığında, bunu kendi RCS komutuna bir yanıt olarak yorumlar. Ardından şunları yapar:

  1. Bekleyen bit ve ileti tahsisini gösteren değişkenleri sıfırlar.
  2. Gelebilecek ALL komutlarına hazırlık olarak bağlantıyı “ileti-göndermeye-hazır” durumuna alır.

Eşzamanlı olarak, alıcı NCP RCS komutunu alır. Bunu kendi RCR komutuna bir yanıt olarak yorumlar. Ardından şunları yapar:

  1. Bekleyen bit ve ileti tahsisini gösteren değişkenleri sıfırlar.
  2. Bağlantıyı bir ileti kabul etmeye hazır olduğunu gösteren duruma sıfırlar.
  3. Bit ve ileti tahsisini yeniden değerlendirir ve yapmak istediği her tahsis için bir ALL komutu gönderir.

VI. Yarı Kapalı Bağlantılar Sorunu

Yukarıdaki yordamlar, açık bir bağlantı için iletilerin ya da tahsislerin kaybolmasına yol açan, iletişim bileşenlerindeki kısa süreli bir aksaklıktan sonra bir bağlantıyı yeniden eşzamanlamanın bir yolunu sağlar.

İletişimde daha uzun ve daha ciddi bir kesinti, alt ağın bölünmesi ya da iletişim kuran ana makinelerden birindeki hizmet kesintisi sonucu ortaya çıkabilir. Bu gibi durumlarda kaynakların süresiz olarak bağlı tutulması istenmez; bu nedenle kullanıcıya bu kaynakları (kendisi de dahil olmak üzere) tek taraflı olarak serbest bırakma seçeneği sunulur. Burada “tek taraflı” ifadesi, CLS komutunu gönderip CLS onayını almadan bağlantıyı kapatmak anlamına gelir. Bunun yalnızca alt ağın hedefin ölü olduğunu gösterdiği durumlarda yasal olduğuna dikkat edilmelidir.

Böyle bir kesintiden sonra hizmet yeniden sağlandığında, bağlantının iki ucundaki durum bilgileri eşzamanlı değildir. Bir uç bağlantının açık olduğuna inanır ve bağlantıyı kullanmaya devam edebilir. Bağlantıyı koparan uç ise bağlantının kapalı (mevcut olmayan) olduğuna inanır ve aynı yerel soketi kullanarak yeni bir bağlantı açmak (RTS veya STR komutu) suretiyle iletişimi yeniden başlatabilir.

Burada gerekli olan yeniden eşzamanlama, tutarsızlık tespit edildiğinde bağlantının açık olan ucunun düzgün biçimde kapatılmasıdır. Bunu, mevcut üç host-host protokol komutunun anlamlarını değiştirerek gerçekleştirmeyi öneriyoruz.

Yukarıda açıklanan “eksik CLS” durumu iki şekilde ortaya çıkabilir. Birinci yol, bağlantının “açık” ucundaki NCP tarafından yapılan eylemleri içerir. Bu NCP, yarı kapalı bağlantının link’i üzerinde normal iletiler göndermeye ya da kendi link’ine atıfta bulunan denetim iletileri göndermeye devam edebilir. “Kapalı” uçtaki NCP, link’in bilinmediğini belirten bir ERR iletisiyle yanıt vermelidir (hata kodu = 5 açık bir bağlantıya karşılık gelmez). Böyle bir ERR iletisini aldığında, “açık” uçtaki NCP, herhangi bir CLS komutu göndermeden bağlantıyı tablolarını değiştirerek kapatmalı ve böylece her iki ucu da uyumlu hale getirmelidir.

Bu tutarsızlığın ortaya çıkabileceği ikinci yol, “kapalı” uçtaki NCP tarafından başlatılan eylemleri içerir. Bu NCP (bağlantının kapalı olduğunu düşünerek) bağlantıyı yeniden açmak için bir STR veya RTS gönderebilir. “Açık” uçtaki NCP, böyle bir RTS veya STR komutu aldığında, bunun mevcut açık bir bağlantıyla aynı yabancı soketi belirttiğini fark ederek bir tutarsızlık tespit eder. Bu durumda, “açık” uçtaki NCP, RTS veya STR’ye yanıt vermeden önce her iki ucu da uyumlu hale getirmek için bağlantıyı (herhangi bir CLS komutu göndermeden) kapatmalıdır.

VIII. Sonuçlar

Bölüm II’de sunulan tahsisleri yeniden eşzamanlama düzeni çok önemli bir özelliğe sahiptir: veri akışı değişim boyunca korunur. Hiçbir veri kaybolmadığı için, yeniden eşzamanlamayı herhangi bir zamanda her iki uçtan birinden başlatmak güvenlidir. Şüphe durumunda, yeniden eşzamanlayın.

RTS, STR ve ERR (kod 5) komutlarının anlamlarındaki değişiklikler, yarı kapalı bağlantıların kapatılmasını tamamlamak için gereken eşzamanlamayı sağlar.

Yukarıdaki protokol değişiklikleri, iletişim bileşenlerindeki aksaklıklara rağmen yararlı işlerin devam edebilmesini sağlayarak host-host protokolünü çok daha sağlam hale getirecektir.

Bu RFC, çevrimiçi RFC arşivlerine girmek üzere Via Genie tarafından 08/00 tarihinde makine tarafından okunabilir biçime dönüştürülmüştür.