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

ARPANET Türü Bir Ağ için Bir Host/Host Protokolü

Yazar
Kurum
Tarih
Durum
Network Working Group Yorum Talebi
Kanal
protokol/

ARPANET Türü Bir Ağ için Bir Host/Host Protokolü

Yakın zamanda, uygulanması hâlinde ARPANET IMP’lerini değiştirmeden kullanacak, ancak Host/Host (ve daha üst seviye) Protokolünün yeniden tanımlanmasına olanak sağlayacak bir ağın planlanmasıyla ilgilenmiş bulunuyoruz. Bu belgenin geri kalanı, Host/Host protokolü için önerimizin hafifçe düzenlenmiş bir sürümüdür; bunun ARPANET Topluluğu için ilgi çekici olabileceğini düşündük.

I. GİRİŞ

ARPANET için Host/Host Protokolü, paket anahtarlamalı bir ağ üzerinde kullanılmak üzere tasarlanan bu türdeki ilk protokoldür. Mevcut sürüm 1972’nin başlarından beri varlığını sürdürmektedir ve on binlerce ya da yüz binlerce bağlantı üzerinden milyarlarca bitin taşınmasını sağlamıştır. Açıkça görülmektedir ki protokol bu iş için yeterlidir; ancak bu, ideal olduğu anlamına gelmez. Özellikle, ARPANET Host/Host protokolü aşağıdaki gerekçelerle (diğerlerinin yanı sıra) eleştirilmiştir:

  1. Simplex bir protokol olarak tanımlanmıştır. Kurulan her bağlantı bir simplex varlıktır; dolayısıyla bir mesaj alışverişi gerçekleştirmek için iki bağlantının (her yönde bir tane) kurulması gerekir. Bu büyük bir genellik sağlar, ancak muhtemelen kabul edilemez düzeyde bir karmaşıklık pahasına.

  2. Özellikle sağlam değildir; çünkü çeşitli mesaj kaybı türleri karşısında doğru biçimde çalışmaya devam edemez. ARPANET’in kendisinin nadiren mesaj kaybettiği doğru olsa da, hem ağ hem de Host’lar tarafından zaman zaman mesajlar kaybedilmektedir.

  3. Kısmen bağlantıların simplex doğası nedeniyle, ARPANET protokolünde tanımlanan akış kontrolü mekanizmaları, veri işlemenin büyük bir bölümünün işlemsel doğasından verimli biçimde yararlanmaz. Akış kontrolü bilgisini (izinler ya da daha fazla bilgi talebi biçiminde) ters yöndeki trafikte taşımak yerine, bu bilgiyi iletmek için ayrı bir kanal kurulur. Dolayısıyla, işlemsel sistemler için, yalnızca veri için gerekli olacak mesaj sayısının iki katına kadar (yarısı akış kontrolü bilgisi, yarısı veri için) mesaj alışverişi yapılır.

  4. Bir bağlantı sonlandırma noktasının çoklu kullanımına getirilen yasak, hizmet tesisleriyle iletişim kurulmasını son derece zahmetli hâle getirir.

Uluslararası Bilgi İşleme Federasyonu (IFIP) Çalışma Grubu 6.1 (Paket Anahtarlamalı Ağların Birbirine Bağlanması) yakın zamanda, ağlar arası uçtan uca bir protokol için bir öneriyi onaylamıştır. IFIP Protokolü, ARPANET, (Fransız) Cyclade Ağı ve (İngiliz) NPL Ağı deneyimlerine ve ayrıca diğer ağların planlarına dayanmaktadır. Dolayısıyla, bu ağlarda kullanılan ya da kullanılması planlanan protokollerin tüm güçlü yönlerine ve çok azına (ya da hiçbirine) sahip olmaması beklenir.

Gerçekte, IFIP Protokolü yukarıda belirtilen ARPANET protokolü eksikliklerinden kaçınmaktadır. Bağlantılar tam çift yönlü varlıklar olarak ele alınır ve bu karar, ters yönde doğal olarak trafik bulunan işlemsel sistemlerde akış kontrolü bilgisinin ters kanalda taşınmasına olanak tanır. Buna ek olarak, IFIP Protokolü belirli bir ölçüde kendi kendine eşzamanlayıcıdır; özellikle, protokolün zarif bir biçimde toparlanmaya izin vermediği hiçbir mesaj kaybı türü yoktur.

IFIP Protokolü, üzerinde çalışacağı ağ hakkında asgari sayıda varsayım yapar. Bir mesajın bir ağdan diğerine geçerken, ağ içi yeniden birleştirme olmaksızın parçalanmasına izin verecek şekilde tasarlanmıştır. Mesajların ya da mesaj parçalarının çoğaltılmasını veya iletilmemesini öngörür ve bu durumlardan kurtulmak için yöntemler sağlar. Son olarak, mesajların hedef Host’ta, kaynak Host tarafından girildikleri sıradan tamamen farklı bir sırada teslim edilmesine izin verir. Ne yazık ki, bu avantajları, aktarılan bitler açısından nispeten yüksek bir ek yük maliyetiyle elde eder. Kaynak ve hedef süreç adreslerinin tamamı her mesajda taşınır, her parça ile birlikte 24 bitlik parça tanımlama bilgisi taşınır ve her mesajda ayrıca 16 bitlik onay bilgisi bulunur.

Yüzlerce kilobit (ya da daha fazla) kanal kapasitesi düşünüldüğünde, birkaç yüz bitlik mesaj ek yükü, büyük esneklik ve genellik elde etmek için ödenecek makul bir bedeldir. Ancak, ele alınan türde tek başına bir ağ için ve özellikle 10 kbs kapasiteli birçok devrenin öngörülen kullanımı göz önüne alındığında, IFIP Protokolü ihtiyaç duyulandan çok daha fazla genellik sunmakta ve bunun karşılığında oldukça ağır bir ek yük bedeli ödenmektedir.

Uluslararası Telgraf ve Telefon Danışma Komitesi (CCITT) bünyesinde hâlen tartışılmakta olan sanal devre protokolleri, bunun ters yönünde bir adımdır. Sanal devre protokolleri, hata ya da gecikme özellikleri dışında, paket anahtarlamalı bir ağı (müşteri bakış açısından) devre anahtarlamalı bir ağdan ayırt edilemez hâle getirmeyi amaçlar. Dolayısıyla, sanal devre protokolleri genellikle uçtan uca iletişim denetimi sorumluluğunu Host’lar yerine ağın içine yerleştirir. Örneğin, bir alıcı Host ağdan kabul ettiği veri hızını sınırladığında, ağ da bu veri akışını ileten Host’tan gelen giriş hızını sınırlar. Sanal devre ağları için tasarlanan Host protokolleri, bir miktar esnek olmamakla birlikte, oldukça basit olabilir. Örneğin, Host ağa bir “bağlantı numarası” ya da “indeks” verebilir ve bu numarayla ilişkilendirilecek şekilde başka bir Host’a sanal bir devre kurulmasını isteyebilir ve devre kurulursa ya da ne zaman kurulursa geri bildirim alabilir. Ancak, ARPANET IMP yazılımına sanal devre yeteneği eklemek önemli bir geliştirme gerektirecektir; gerekli değişiklikler, değeceklerinden daha pahalı ve daha büyük belirsizlik taşıyor gibi görünmektedir.

Yukarıdakilerin ışığında, önerilen bu protokolü tanımlarken yaklaşımımız, ARPANET Host/Host Protokolü ile başlamak ve onun başlıca eksikliklerini gidermek amacıyla IFIP Protokolünün bazı kavramlarına göre onu değiştirmek olmuştur. Bu belgenin geri kalanı, bu amaçla tasarladığımız protokolü tanımlar.

II. İLETİŞİM KAVRAMLARI

IMP alt ağı, Host’lar arasındaki iletişime bir dizi fiziksel kısıtlama getirir. Bu kısıtlamalar BBN Raporu No. 1822’de sunulmaktadır. Özellikle, liderler, mesajlar, doldurma (padding), mesaj kimlikleri ve mesaj türleri kavramları Host/Host Protokolünün tasarımı açısından ilgi çekicidir. Aşağıdaki tartışma, okuyucunun bu kavramlara aşina olduğunu varsayar.

IMP alt ağı yalnızca Host’ları dikkate alır; ancak genel olarak ağa bağlı bir Host, birden fazla kullanıcıyı, birden fazla terminali ya da birden fazla bağımsız süreci destekleyebilir. Bu kullanıcıların, terminallerin ya da süreçlerin çoğunun veya tamamının ağı eşzamanlı olarak kullanması gerekeceğinden, Host/Host Protokolünün temel bir gereksinimi, ağ üzerinden süreçten sürece iletişim sağlamaktır. Dolayısıyla, Host/Host Protokolünün, IMP alt ağının gerektirdiğinden daha zengin bir adresleme yapısı sunması gerekir.

Bir Host içindeki süreçlerin, ağın geri kalanıyla, o Host’ta yerleşik ve Host/Host protokolünü uygulayan bir ağ denetim programı (NCP) aracılığıyla iletişim kurduğu öngörülmektedir. Bir NCP’nin temel işlevleri bağlantıları kurmak, bağlantıları sonlandırmak ve bağlantılar üzerindeki veri akışını denetlemektir. Bir bağlantı, iki süreci birbirine bağlar; öyle ki bir sürecin çıktısı diğerinin girdisi olur ve tersi de geçerlidir. NCP, Host’un işletim sisteminin bir parçası olarak ya da ayrı bir kullanıcı süreci olarak uygulanabilir; ancak ağı kullanmaya çalışan tüm süreçler ya da yordamlarla iletişim kurabilme yeteneğine sahip olmalıdır.

Görevlerini yerine getirebilmek için, bir Host’un NCP’sinin diğer Host’ların NCP’leriyle iletişim kurması gerekir. Bu amaçla, her Host çifti arasında belirli bir iletişim yolu denetim bağlantısı olarak belirlenmiştir. Denetim bağlantısı üzerinden iletilen mesajlara denetim mesajları denir ve her zaman bir NCP tarafından bir veya daha fazla denetim komutundan oluşan bir dizi olarak yorumlanmalıdır. Örneğin, bir tür denetim komutu bir bağlantıyı başlatmak için kullanılırken, başka bir tür bir bağlantının sonlandırıldığına dair bildirim taşır.

Not: BBN Raporu No. 1822’de, sıfırdan farklı türdeki mesajlara denetim mesajları denir ve bir Host ile onun IMP’si arasındaki bilgi akışını denetlemek için kullanılır. Bu belgede ise “denetim mesajı” terimi, denetim bağlantısı üzerinden iletilen sıfır türünde bir mesaj için kullanılmaktadır. IMP’ler bu mesajlara özel bir önem atfetmez.

Bir mesajın azami boyutu, IMP alt ağı tarafından yaklaşık 1000 adet 8 bitlik bayt ile sınırlandırılmıştır ve aslında, daha sonra açıklanacağı üzere, alıcı Host tarafından akış kontrolü nedenleriyle daha da sınırlandırılabilir.

Buna göre, ileten süreç ya da onun Ağ Denetim Programı, uzun süreçler arası mesajları Host/Host ve Host/IMP protokollerine uygun boyutta mesajlara parçalama sorumluluğunu üstlenmelidir. Bu nedenle, gönderen bir Host’un, alıcı süreçler tarafından mesaj sınırlarına herhangi bir anlam yüklenmesini garanti etmesi imkânsızdır. Bununla birlikte, mesaj sınırları doğal olarak ortaya çıkacaktır ve mümkün olan her yerde makul bir biçimde kullanılmalıdır; yani, gönderen bir süreç ya da onun NCP’si, mesajları parçalamaya karar verirken keyfi davranmamalıdır. Örneğin, bu protokol her denetim mesajının tam sayıda denetim komutu içermesini ve hiçbir tekil denetim komutunun ağ içinde ayrı mesajlar aracılığıyla taşınacak şekilde iki parçaya bölünmemesini belirtir.

Host/Host Protokolünün başlıca kaygılarından biri, diğer Host’lardaki süreçlere başvuru yönteminin tanımlanmasıdır. Bunu kolaylaştırmak için, her Host’a ad alanının ayrı bir bölümünün tahsis edildiği standart bir ad alanı kullanılır. Dolayısıyla, her Host içsel süreç tanımlayıcılarını ad alanının kendisine ayrılmış bölümüne eşlemelidir. Ad alanının öğelerine soket adı verilir. Bir soket, bir bağlantının bir ucunu oluşturur ve bir bağlantı, her Host’ta birer tane olmak üzere bir çift soket ile tam olarak tanımlanır. Bir soket, bir Host numarası ve 16 bitlik bir soket numarası ile tanımlanır. Farklı Host’larda aynı 16 bitlik soket numarası farklı soketleri temsil eder. Bu soketler arasındaki her mesajda 16 bitlik iki soket numarasının bir çiftinin iletilmesini önlemek amacıyla, bağlantı kurulması süreci, her Host’un, kurulmakta olan bağlantının ömrü boyunca geçerli olacak şekilde, soket çiftini tanımlayan 32 bitten 8 bitlik bir sayıya bir eşleme tanımlamasına izin verir.

Soket numaralarının atanmasına herhangi bir kısıtlama getirilmez; ancak bir soket numarası çifti benzersiz bir bağlantıyı tanımladığından, soket numaraları atanırken bir Host’un her yeni bağlantı için soket numaralarından en az birinin benzersiz olmasını sağlaması gerektiği açıktır. Örneğin, çok sayıda terminali destekleyen bir Host, bir terminalin fiziksel arayüz numarasını, o terminal adına kurulan herhangi bir bağlantıda yer alan soket numarasının bir parçası olarak kullanmayı seçebilir. Bu, terminal ucunda benzersizliği güvence altına alır. Böylece, birden fazla terminal ortak bir kaynağa (kendine özgü bir soket numarasıyla tanımlanan) erişmeye çalışsa bile herhangi bir çakışma oluşmaz.

Yukarıdakilerden, Host/Host protokolünün tek bir soketin aynı anda birden fazla bağlantıya katılmasına izin verdiği açıkça görülmelidir. Bu durum, telefon sisteminde olanlara oldukça benzer; burada bir şirketin de bir bireyin de bir telefon numarasıyla tanımlanabilmesi mümkündür. Dışarıdan bakıldığında, bir şirketin telefon numarası paylaşılabilirdir; çünkü aynı anda birden fazla görüşme sürdürülebilir ve arayan kişinin mevcut görüşmeler hakkında endişelenmesi gerekmez. Buna karşılık, bir bireyin telefon numarası paylaşılabilir değildir; çünkü aynı anda yalnızca tek bir görüşmeyi yürütebilir; bu durum, ağı kullanıyor olabilecek bir terminale olan bağlantı için de genellikle geçerlidir.

Açıklanması gereken son önemli kavram, akış kontrolü için kullanılan “pencereleme” kavramıdır. Bu kavram, IFIP protokolünden alınmış olup, ARPANET türü bir ağda kullanılmak üzere bazı uygun değişikliklerle uyarlanmıştır. Bir bağlantı kurulduğunda, bir sıra numarası belirli bir başlangıç noktasına ayarlanır ve alıcı, göndericiye belirli sayıda kredi tahsis eder. Her kredi, göndericiye bir mesaj iletme hakkı tanır; yani alıcı, verilen kredi sayısı kadar mesaj için arabelleğe alma sağlamayı kabul eder. Sıra numaralarının soldan sağa doğru ilerlediği düşünülürse, başlangıç sıra numarası tüm sıra numarası uzayı içinde bir pencerenin sol kenarını tanımlar ve kredi, başlangıç sıra numarasına eklendiğinde pencerenin sağ kenarını tanımlar. Gönderen süreç, pencereyi dolduracak kadar mesaj göndermeye yetkilidir, ancak bundan fazlasını gönderemez.

Bir alıcı, sıra numarası pencerenin sol kenarında olan bir mesajı (ya da sol pencere kenarından sağa doğru uzanan birkaç ardışık mesajı) aldığında, en sağdaki bu mesaj için bir onay döndürür; buna ek olarak yeni bir kredi iletir ve kendi penceresini ilerletir. Yeni sol kenar, onaylanan son mesajın hemen ardından gelir ve yeni sağ kenar, yeni sol pencere kenarına yeni kredinin eklenmesiyle tanımlanan konumdadır. Benzer şekilde, bir gönderici bir onay aldığında, kendi sol pencere kenarını onayda belirtilen sıra numarası uzayındaki konuma ve kendi sağ pencere kenarını da yeni kredi tahsisinin sol pencere kenarına eklenmesiyle belirtilen konuma ilerletir. Her veri mesajında, ters yönde akan trafik için bir onay ve bir kredi taşımaya ayrılmış alanlar bulunur. Böylece, etkileşimli ya da işlemsel alışverişler durumunda, herhangi bir denetim mesajı gönderilmesine gerek kalmaz.

Bir gönderici, daha önce iletilmiş mesajlar için belirli bir zaman aşımı süresi içinde onay almazsa, mesajlar daha önce atanan aynı sıra numarası kullanılarak yeniden iletilir. Bu, kaybolan mesajlar durumundan basit bir şekilde toparlanmaya olanak tanır. Öte yandan, kaybolan geri dönen onay ise, yeniden iletilen mesajın aynı sıra numarasını taşıması, alıcının onu atmasına olanak verir. Ancak alıcı, yeniden iletim sırasında göndericinin bir onay almamış olduğunu fark etmelidir; dolayısıyla alıcı, bu mesajı (ve sonrasında alınan tüm mesajları) mevcut sol pencere kenarını taşıyan bir onay göndererek yeniden onaylamalıdır. Böylece, hem veri mesajlarının kaybolması hem de onayların kaybolması durumunda protokol eşzamanlı kalır.

Bu protokol ile IFIP Protokolü arasındaki temel fark, sıra numarası alanının boyutundadır. IFIP Protokolü, gecikmelerde çok büyük değişkenliklerin bulunduğu ve iletilerin kaynak tarafından gönderildikleri sırayla hedefe ulaştırılmama olasılığının yüksek olduğu çok sayıda ağın birbirine bağlanması için tasarlanmıştır. Bu nedenle IFIP Protokolü, megabit/saniye hızlarında bile birkaç saatten daha kısa sürede tamamen döngüden geçirilemeyen 16 bitlik bir sıra numarası alanı kullanır. Buna karşılık, önerilen ARPANET-tipi ağ; gecikmelerin genellikle kısa olduğu, iletilerin nadiren kaybolduğu ve iletildikleri takdirde her zaman gönderildikleri sırayla teslim edildikleri özelliğine sahiptir. Bu nedenle bu Host/Host Protokolü yalnızca 4 bitlik bir sıra numarası alanı kullanır; bu alan doğal olarak her 16 iletide bir döngüden geçirilir. Bu durum, bir pencerenin asla sekiz iletiden daha büyük olamayacağı kısıtını getirir. Sıra numarası 4 bitlik bir alanda yer aldığından, kredi ve onay alanlarının her biri için de yalnızca dört bit kullanmak mümkündür; dolayısıyla bu protokol, IFIP Protokolü altında kullanılan 40 bit yerine her ileti başlığında yalnızca 12 bit kullanır.

III. NCP İŞLEVLERİ

NCP’nin işlevleri; bağlantılar kurmak, bağlantıları sonlandırmak, akış kontrolünü sağlamak, kesmeleri iletmek ve test sorgularına yanıt vermektir. Bu işlevler bu bölümde açıklanmakta ve gerekli oldukça kontrol komutları tanıtılmaktadır. Bölüm IV’te tüm kontrol komutlarının biçimleri birlikte sunulmaktadır.

Bağlantı Kurulması

Bağlantıyı kurmak için kullanılan komut RFC’dir (request for connection).

    8*       16           16           8        16       8
----------------------------------------------------------------
!  RFC  ! my-socket ! your-socket !  Index  !  size  ! credit  !
----------------------------------------------------------------

Her bir kontrol komutu alanının üzerinde gösterilen sayı, o alanın bit cinsinden uzunluğudur.

RFC komutu, bir soket çifti arasında bir bağlantının kurulmasını ister ya da daha önce alınmış bir bağlantı isteğini kabul eder. RFC komutu hem bağlantı kurulmasını istemek hem de kabul etmek için kullanıldığından, işbirliği yapan iki süreçten herhangi biri bağlantı kurulmasını başlatabilir. Her iki süreç de eşzamanlı olarak bağlantı kurulmasını isterse bile, her biri diğerinin gönderdiği RFC’yi kendi RFC’sinin kabulü olarak yorumlayacak ve böylece bağlantı herhangi bir güçlük olmaksızın kurulacaktır.

RFC’deki my-socket ve your-socket alanları, her bir Host’ta bağlantının uçlarını sonlandıran soketleri tanımlar. RFC’nin index alanı, bu bağlantı üzerinden “my-socket” ucundan “your-socket” ucuna gönderilecek her veri iletiminde yer alacak bir indeks numarasını belirtir. RFC’nin size alanı, bağlantının “your-socket” ucundan “my-socket” ucuna tek bir iletide gönderilmesine izin verilen 8 bitlik baytların azami sayısını belirtir. RFC’nin credit alanı ise bağlantının “your-socket”tan “my-socket”a doğru yönünde pencerenin başlangıç boyutunu (0–7 aralığında) belirtir.

İki Host arasında değiş tokuş edilen bir RFC çifti, birinin my-socket alanı diğerinin your-socket alanına eşit olduğunda ve tersi de sağlandığında eşleşir. Eşleşen bir RFC çifti değiş tokuş edildiğinde bağlantı kurulmuş olur.

Bağlantılar, bağlantıyı sonlandıran soketler tarafından benzersiz olarak belirlenir; dolayısıyla bir soket numarası çifti aynı anda iki farklı bağlantıyı tanımlamak için kullanılamaz. Benzer şekilde, bir veri iletisinin hangi bağlantıya ait olduğunu belirtmek için indeks kullanılır; bu nedenle bir indeks değeri, ilk atandığı bağlantı hâlâ etkin durumdayken ya da kurulma sürecindeyken yeniden kullanılamaz.

Örneğin, Host A’dan Host B’ye gönderilen bir RFC düşünelim; bu RFC’de my-socket alanı X değerini, your-socket alanı Y değerini ve index alanı Z değerini içersin. İstenen bağlantı kapatılana (hiçbir zaman kurulmasa bile) ya da yeniden başlatılana kadar, Host A’nın my-socket ve your-socket alanları X ve Y olan ya da index alanı Z olan farklı bir RFC’yi Host B’ye göndermesi yasaktır. X ve Y değerlerinin yeniden kullanımına ilişkin yasağın bunları bir çift olarak ele aldığını unutmayın; yani my-socket alanı X değerini içeren başka bir RFC, your-socket alanı Y’den farklı bir değer içerdiği sürece Host A’dan Host B’ye gönderilebilir.

Genel olarak bir RFC için önceden belirlenmiş bir yaşam süresi yoktur. Bir Host, gelen RFC’leri kuyruğa alabilir ve yanıtı keyfi olarak uzun bir süre geciktirebilir ya da alternatif olarak, daha önce eşleşen bir RFC göndermemişse istekleri derhal reddedebilir. Elbette RFC’yi ilk gönderen Host, keyfi olarak uzun süre beklemek istemeyebilir; bu durumda isteği iptal edebilir.

Gelen RFC’lerin kuyruğa alınıp alınmaması kararı, göz ardı edilmemesi gereken önemli sonuçlar doğurur. Kuyruğa alınan her RFC, doğal olarak, kuyruğa alma işlemini yapan Host’ta az da olsa bellek gerektirir. Gelen RFC, yerel bir süreç yerel soketin denetimini alıp RFC’yi kabul edene (ya da reddedene) kadar kuyruğa alınırsa, ancak hiçbir yerel süreç soketin denetimini hiç almazsa, RFC sonsuza kadar kuyrukta kalmak zorundadır. Öte yandan, hiç kuyruklama yapılmazsa, iletişim kurmaya çalışan işbirlikçi süreçler bu iletişimi ancak tesadüfen kurabilirler.

Yukarıda ortaya konan sorunlara en makul çözüm, her NCP’nin kendi Host’unda çalışan süreçlere bağlantı başlatmaya çalışmak için iki seçenek sunmasıdır. Birinci seçenek, bir sürecin belirli bir uzak sokete bir RFC gönderilmesini sağlamasına ve NCP’nin bu RFC’nin uzak Host tarafından kabul edilip edilmediği ya da reddedilip edilmediği konusunda süreci bilgilendirmesine olanak tanır. İkinci seçenek ise bir sürecin kendi NCP’sine, belirli bir yerel sokete bir uzak soketten bir RFC’yi dinlemesini (süreç ayrıca iletişim kurmak istediği belirli uzak soketi ve/veya Host’u da belirtebilir) ve RFC geldiğinde kabul etmesini (yani eşleşen bir RFC döndürmesini) söylemesine olanak tanır. Bunun da kuyruklama içerdiğini ("dinleme" isteklerinin kuyruklanması) ancak bunun yerel Host tarafından makul biçimde yönetilebilen içsel bir kuyruklama olduğunu unutmayın.

Bağlantının Sonlandırılması

Bir bağlantıyı sonlandırmak için kullanılan komut CLS’dir (close).

        8         16          16
-----------------------------------
!  CLS  ! my-socket ! your-socket !
-----------------------------------

CLS komutundaki my-socket ve your-socket alanları, kapatılmakta olan bağlantıyı sonlandıran soketleri tanımlar. Bağlantının sonlandırılması tamamlanmadan ve soket çifti ile indeks değerinin yeniden kullanımına ilişkin yasaklar kaldırılmadan önce, her iki taraf da bir CLS komutu göndermeli ve almalıdır.

Bağlantının sonlandırılmasının başlaması için bağlantının kurulmuş olması (yani her iki RFC’nin de değiş tokuş edilmiş olması) gerekmez. Örneğin, bir Host bir bağlantı isteğini reddetmek isterse, eşleşen bir RFC yerine bir CLS geri gönderir. Reddeden Host daha sonra, başlatan Host’un reddi bir CLS geri göndererek onaylamasını bekler. Benzer şekilde, bir Host beklemede olan bağlantı isteğini iptal etmek isterse bir CLS komutu gönderir. Yabancı Host, CLS’yi kendi CLS’si ile onaylamakla yükümlüdür.

Bağlantı hiçbir zaman kurulmamış olsa bile, soket çifti ya da indeksin yeniden kullanımına ilişkin yasağın tamamen sona ermesi için CLS komutlarının değiş tokuş edilmesi gerektiğine dikkat edin. Normal koşullar altında bir Host, üzerinde henüz onaylanmamış veriler bulunan bir bağlantı için CLS komutu göndermemelidir. Elbette diğer Host henüz veri iletmiş olabilir; bu nedenle CLS komutunu gönderen taraf, diğer Host’tan ek veriler almayı bekleyebilir.

Yabancı Host’un tablolarını temizleyebilmesi için, Host gelen bir CLS’yi hızla onaylamalıdır. Özellikle, beklemede onaylanmamış veri yoksa, bir Host gelen bir kapatmayı 60 saniye içinde onaylamak zorundadır. 60 saniyelik sürenin ardından, CLS ileten Host soket çiftini ve indeksi kullanılmıyor olarak kabul edebilir ve etkin bağlantıları tanımlayan tablolardan bu değerleri silebilir. Elbette, yabancı Host CLS’nin 60 saniyeden daha uzun süre boyunca yok sayılmasına yol açacak biçimde arızalanırsa, sonraki bağlantı kurma ya da veri iletme girişimleri belirsiz sonuçlara yol açabilir. Bu olasılıkla başa çıkmak için, bir Host genellikle CLS komutlarına yanıt vermemiş herhangi bir Host’a yeni bir bağlantı kurmaya çalışmadan önce bağlantı parametrelerinin kullanımını yeniden başlatmalıdır. Bağlantı parametre tablolarının yeniden başlatılmasına yönelik yöntemler aşağıda açıklanmaktadır.

Onaylama

Önceki bölümde açıklandığı gibi, akış kontrolü sıra numaralarına dayalı bir pencereleme şeması ile ele alınır. Krediler ve onaylar, ters kanal üzerinden giden verilerle birlikte taşınabilir. Bu nedenle genel olarak, iletilerin alındığının onaylanması kontrol bağlantısı yerine veri bağlantısı üzerinden gerçekleşir. Ancak bazı durumlarda onayların kontrol bağlantısı üzerinden iletilmesi istenebilir (örneğin, ters yönde geri gönderilecek veri olmadığında).

Buna ek olarak, teslim edilmediği bilinen veri iletimlerini zaman aşımı ve yeniden iletim mekanizmasının bu iletilerin yeniden gönderilmesine yol açmasını beklemek yerine olumsuz olarak onaylamak, verimlilik açısından arzu edilebilir olabilir. (Bu tür olumsuz onaylamanın gerekli olmadığını, çünkü zaman aşımı ve yeniden iletim mekanizmasının her zaman tüm verilerin sonunda teslim edilmesini garanti ettiğini, ancak iletişimin verimliliğini artırmak için kullanılabileceğini unutmayın.) ARPANET-tipi bir ağ üzerinde olumsuz onaylama sisteminin kullanım sıklığı son derece düşük olacağından, her veri iletisi başlığında olumsuz onaylamalar için alan ayırmak istenmez. Bu nedenle olumsuz onaylama en uygun biçimde kontrol iletileriyle ele alınabilir.

Onaylamayla ilgili iki komut vardır.

        8       8       4       4
---------------------------------
!  ACK  ! index !  seq  !  crd  !
---------------------------------

ACK (acknowledgement) komutu üç veri alanı taşır. Index değeri, onayı gönderen tarafından bağlantıyı tanımlamak için kullanılan indekstir. Sıra ("seq") alanı, bağlantı üzerinden doğru biçimde alınmış olan ardışık veri iletileri arasında en yüksek numaralı olanın sıra numarasını içerir.

Yeni kurulmuş bir bağlantı üzerinden iletilecek ilk veri iletisi sıra numarası bir olacaktır; bu veri iletisi doğru biçimde alınana kadar, bu bağlantı için iletilen tüm onay komutlarında (örneğin kredi değerini değiştirmek için) sıra alanı sıfır olarak ayarlanacaktır. Bu durum, onayın bir ACK komutu ile taşınması ya da bağlantı üzerinden yabancı Host’a gönderilen veri iletilerinin içinde yer alması fark etmeksizin geçerlidir.

Kredi ("crd") alanı 0–7 aralığında bir sayı içerir.

Bu sayı, alma penceresinin boyutunu verir. Bu sayı, "seq" ile toplandığında, yabancı Host tarafından iletilmesine izin verilen en yüksek numaralı iletinin sıra numarasını verir. Dolayısıyla, sıfır kredi, ACK komutunu ileten Host’un bağlantı üzerinden şu anda hiçbir ileti kabul etmeye hazır olmadığını söyler; 7 kredi ise Host’un bağlantı üzerinden en fazla 7 ileti kabul etmeye hazır olduğunu belirtir. Elbette, sıra numarası 4 bitlik bir alanda yer aldığından, sıra numarası ile kredi değerinin toplanması mod 16 olarak yapılmalıdır (sıra numarası 0, sıra numarası 15’in hemen ardından gelir).

Yukarıda belirtildiği gibi, ACK komutu bir yönde veri akışı olmayan veri bağlantılarında kullanılmak üzere tasarlanmıştır; örneğin, bir dosyanın bir satır yazıcısına iletilmesi. Aslında, kontrol iletilerinin iletiminin veri iletilerinin iletimiyle (ağda ya da daha da önemlisi, ileten NCP içinde) senkronize olmadığı dikkate alındığında, veri akışının aynı yönde olduğu herhangi bir bağlantı için ACK komutlarının gönderilmemesi gerektiği açık olmalıdır. Bu nedenle, bir ACK komutu üretilirse, onu ileten NCP, onu içeren kontrol iletisinin aynı bağlantı için yeni veri iletilerinin iletiminden önce gönderildiğinden emin olmalıdır.

        8        8       8
    --------------------------
    !  NACK  ! index !  seq  !
    --------------------------

NACK (negative acknowledgement) komutu iki veri alanı içerir. Yukarıda açıklanan olumlu onay komutunda olduğu gibi, ilk alan NACK’i gönderen tarafından bu bağlantıya atanmış indeks numarasıdır. Ancak ikinci alan, söz konusu bağlantı için olumsuz olarak onaylanan veri iletisinin 4 bitlik sıra numarasını, 8 bitlik bir alan içinde sağa yaslanmış olarak içerir.

Daha önce belirtildiği gibi, NACK protokolde hayati bir işlev görmez ancak zaman zaman daha verimli iletişime olanak tanıyabilir. NACK, pencere genişliğinin birden büyük olduğu, pencerenin sol kenarındaki iletinin doğru biçimde alınmadığı ve pencerenin sağ tarafına doğru olan iletilerin doğru biçimde alındığı durumlarda kullanılmak üzere tasarlanmıştır. Bir zaman aşımı sonunda eksik iletinin yeniden iletilmesi gerçekleşecek ve bu noktada pencerenin sol kenarı birkaç ileti ileri taşınabilecektir. Ancak NACK kullanımı, eksik iletinin derhal yeniden iletilmesini tetikleyebilir ve böylece gecikmeyi azaltabilir. Elbette, birden fazla ileti eksikse, tek bir kontrol iletisi içinde bir indeks için birden fazla NACK göndermek arzu edilebilir; protokol buna izin verir, ancak bunun gerçekleşmesi son derece düşük bir olasılıktır.

Yeniden Başlatma

Zaman zaman, kaybolan kontrol iletileri, sistem çökmeleri, NCP hataları ya da diğer etkenler nedeniyle iki NCP arasındaki iletişim kesintiye uğrayabilir. Bu tür bir kesintinin olası etkilerinden biri, ilgili NCP’lerin hiçbirinin, diğer Host ile olan bağlantılara ilişkin olarak sakladığı bilgilerin karşı Host’taki NCP’nin sakladığı bilgilerle eşleştiğinden emin olamaması olabilir. Bu durumda bir NCP, tablolarını yeniden başlatmak ve diğer Host’un da aynı şeyi yapmasını istemek isteyebilir.

Bu yeniden başlatma, belirli bir indeks ve/veya soket çifti için ya da diğer Host ile olası olarak kurulmuş tüm bağlantılar için küresel olarak istenebilir. Bu amaçlarla protokol, aşağıda açıklandığı üzere üç kontrol komutu sağlar:

        8        16           16          8
    -------------------------------------------
    !  RCP  ! my-socket ! your-socket ! index !
    -------------------------------------------

RCP (bağlantı parametrelerini yeniden başlatma) komutu üç veri alanı içerir. my-socket ve your-socket alanları, bir bağlantıyı tanımlayan bir soket numarası çifti içerir; index alanı ise bir bağlantı üzerindeki veri iletilerini tanımlayacak bir değeri içerir.

Bu komut bir NCP tarafından alındığında, soket çifti tarafından tanımlanan bir bağlantıya yapılan herhangi bir referansı ya da alınan verilerin belirtilen index değeriyle tanımlanacağı bir bağlantıya yapılan herhangi bir referansı tablolarından temizlemelidir; elbette yalnızca RCP’yi gönderen Host ile bu değerleri kullanan bağlantılar temizlenecektir.

Özünde, RCP komutunu gönderen Host şunu söylemektedir:

"Bu soket çifti ve bu index ile bir veri bağlantısını tanımlamak üzere size bir RFC göndermek üzereyim ve umarım kurulması konusunda anlaşabiliriz. Bu soket çifti ya da bu index’in önceki herhangi bir kullanımla çakıştığına inanmıyorum; ancak siz çakıştığını düşünüyorsanız, lütfen bu durumu (daha sonra incelenmek üzere) bir hata olarak kaydedin ve ardından bağlantıyı kurmaya devam edebilmemiz için tablolarınızdaki çakışan bilgileri silin."

Daha genel sorunlar ya da durum bilgisinin kaybından şüphelenildiğinde, protokol RST (reset) ve RRP (reset reply) kontrol komutları çiftini sağlar.

        8
    ---------
    !  RST  !
    ---------

        8
    ---------
    !  RRP  !
    ---------

RST komutu, onu alan Host tarafından, RST’yi gönderen Host ile yapılan iletişimden kaynaklanan tüm girişlerin tablolarından temizlenmesi gerektiğine dair bir sinyal olarak yorumlanmalıdır. RST’yi gönderen Host da benzer şekilde, RST’nin gönderildiği Host ile yapılan iletişimden kaynaklanan tüm girişleri tablolarından temizlemelidir. RST’yi alan Host, alındığını RRP döndürerek onaylamalıdır.

Birinci Host ikinci Host’a bir RST gönderdikten sonra, ikinci Host bir RRP döndürünceye kadar birinci Host ikinci Host ile (RST’lere yanıt vermek dışında) iletişim kurmamalıdır. Her iki NCP yaklaşık olarak aynı anda RST göndermeye karar verirse, her Host bir RST alır ve her biri, kendi RST’si henüz yanıtlanmamış olsa bile bir RRP ile yanıt vermek zorundadır.

Bir Host, bir RST almamışken RRP göndermemelidir. Ayrıca, bir Host tek bir kontrol iletisi içinde yalnızca bir RST (ve başka hiçbir komut) göndermeli ve aynı Host’a, ya 60 saniye geçene kadar ya da o Host’tan RST veya RRP olmayan bir komut alana kadar başka bir RST göndermemelidir. Bu koşullar altında, tek bir RRP, o Host’a gönderilmiş tüm RST’lere yanıt teşkil eder ve o Host’tan gelen diğer tüm RRP’ler göz ardı edilmelidir.

Kesintiler

Bir iletişim sisteminde, ciddi hatalar ya da diğer önemli durumlar algılandığında akış kontrolü mekanizmalarının etrafından dolaşmak bazen gerekli olabilir. Örneğin, hatalı bir sonsuz döngü içeren bir programı oluşturan ve çalıştırmaya başlayan bir zaman paylaşımlı terminal kullanıcısının, işletim sisteminin dikkatini çekerek programının yürütülmesini iptal etmesini istemesi gerekebilir; oysa işletim sistemi normalde terminali yalnızca çalışmakta olan program girdi istediğinde “dinler”.

Benzer şekilde, akış kontrolünün bir süreçten diğerine veri iletimini engelleyebildiği bir bilgisayar iletişim ağında, bazı olağanüstü koşullar altında bir süreçten diğerine bir sinyal iletmek gerekli olabilir. İki Host’un NCP’leri arasındaki kanal, veri bağlantılarına uygulanan akış kontrolü mekanizmalarına tabi olmadığından, böyle bir “bant dışı” sinyali kontrol bağlantısı üzerinden iletmek mümkündür ve bu amaçla INT (interrupt) komutu sağlanmıştır.

        8       8       8
    -------------------------
    !  INT  ! index !  seq  !
    -------------------------

INT komutu iki veri alanı içerir. index alanı, “kesinti”nin ilgili olduğu veri bağlantısını tanımlar; sekans numarası ("seq"), sekiz bitlik bir alanda sağa yaslanmış dört bit olup, kesintiden sonra “gelmesi gereken” ilk veri iletisinin sekans numarasını verir.

Başka bir deyişle, INT komutu alıcı NCP’ye veri akışıyla senkronize edilmesi gereken bir istisna durumunu bildirir ve sekans numarası gerekli senkronizasyonu sağlar. Belirtilen sekans numarasının solundaki sekans numaralarına sahip tüm veri iletileri, istisna durumu ortaya çıkmadan önce üretilmiştir.

Bir INT komutu alan NCP, belirtilen veri bağlantısının sağ pencere kenarını, pencerenin kesinti komutunda belirtilen sekans numarasını en azından içerecek şekilde ilerletmelidir. (Pencereyi bu noktaya ilerletebilmek için doğru alınmamış ya da arabelleğe alınmamış veri iletilerinin onaylanması gerekebilir; bunun gerekçesi, INT’nin yalnızca akış kontrolü mekanizmalarının önemli bilgilerin iletimini engellediği varsayımıyla gönderilmiş olmasıdır.)

Elbette, kesinti ya da istisna sinyalinin kendisi, sinyali alan Host’un yorumuna tabidir; ancak aşağıdakine eşdeğer bir anlama sahip olmalıdır:

"Yürütülmekte olan süreci ya da o sürecin üstünü, olağanüstü bir şeyin gerçekleştiği ve şu anda arabelleğe alınmış verinin önemli bir ileti olduğu konusunda bilgilendir."

Test Sorgusu

Bazen bir Host’un başka bir Host’un ağ konuşmaları yürütüp yürütmediğini belirlemesi yararlı olabilir. Bu amaçla kullanılacak kontrol komutu ECO (echo)’dur.

        8       8
    ------------------
    !  ECO  !  data  !
    ------------------

ECO komutunun data alanı, ECO’yu gönderen Host tarafından seçilen herhangi bir bit düzenini içerebilir. Bir ECO komutu alındığında, bir NCP, veriyi bir ERP (echo reply) komutunda göndericiye geri döndürerek yanıt vermelidir.

        8       8
    ------------------
    !  ERP  !  data  !
    ------------------

Bir Host, gelen bir ECO komutuna (bir ERP komutuyla) makul bir süre içinde, burada altmış saniye ya da daha az olarak tanımlanan süre içinde yanıt vermelidir. Bir Host, hiçbir ECO alınmamışken ERP göndermemelidir.

IV. Bildirime Dayalı Teknik Özellikler

İleti Biçimi

Bu protokole uyan tüm Host’tan Host’a iletiler aşağıdaki şekilde oluşturulacaktır:

Bitler 1–96: Leader — Bu alan, aşağıdaki ek teknik özelliklerle birlikte, BBN Raporu No. 1822’de belirtildiği şekildedir.

Bitler 38–40: Azami İleti Boyutu — Bu alan tüm kontrol iletileri için sıfır olmalıdır. Veri bağlantıları üzerinden gönderilen iletiler için, bu alanın değeri, bağlantıyı kuran RFC’de alınan boyuttan hesaplanmalıdır.

Bitler 65–76: Message-id — Bu alan, iletinin parçası olduğu bağlantının index’ini veren sekiz bit ve iletinin sekans numarasını veren dört bit olmak üzere alt bölümlere ayrılır. Index bitler 65–72’de, sekans numarası ise bitler 73–76’dadır.

Bitler 97–100: Onay (Acknowledgement) — Bu alan, bu bağlantı için pencerenin solunda kalan en yüksek numaralı veri iletisinin dört bitlik sekans numarasını içerir; yani bu bağlantı üzerinden doğru şekilde alınmış, ardışık olarak numaralandırılmış (hiçbiri eksik olmayan) veri iletileri dizisinin en yüksek numaralısının sekans numarasını tanımlar. Bağlantı kurulduğundan beri hiçbir veri iletisi alınmamışsa, bu alan sıfır değerini içermelidir. Bu alan kontrol iletilerinde kullanılmaz (yani herhangi bir değere sahip olabilir).

Bitler 101–104: Kredi (Credit) — Bu alan 0–7 aralığında bir sayı içerir. Bu sayı (modulo 16) olarak onay alanındaki (bitler 97–100) sekans numarasına eklendiğinde, yabancı Host’un bu veri bağlantısı üzerinden göndermesine izin verilen en yüksek sekans numarası elde edilir. Dolayısıyla bu alandaki sıfır değeri, yeni veri iletilerinin gönderilmemesi gerektiğini; yedi değeri ise yabancı Host’un, sekans numarası onay bitlerinde belirtilen iletinin ötesinde en fazla yedi ileti gönderebileceğini gösterir. Akış kontrolü kontrol bağlantısı üzerinden gönderilen iletilere uygulanmadığından, bu alan kontrol iletilerinde herhangi bir değere sahip olabilir.

Bitler 105–…: Metin ve dolgu — BBN Raporu No. 1822’de belirtildiği şekilde, metinden oluşan 8 bitlik baytlar dizisi ve ardından dolgu.

Index Ataması

Index değerleri (bitler 65–72’de) aşağıdaki şekilde atanmalıdır:

Numara Atama
0 Bir kontrol bağlantısını tanımlar
1 Bu protokolde yapılacak revizyonlar için ayrılmıştır
2–191 Veri bağlantılarını tanımlar
192–255 Genişleme ya da diğer protokoller için ayrılmıştır

Sekans Numarası Ataması

Her veri iletisi, bitler 73–76’da bir sekans numarası içerir. Sekans numarası, alıcı tarafından iletilmiş bir iletinin kaybolduğunu saptamak, daha önce kaybolmuş (ve dolayısıyla büyük olasılıkla sırası bozulmuş) yeniden iletilmiş bir iletinin veri akışındaki doğru konumunu belirlemek (ya da yeniden iletilmiş iletinin bir kopya olduğunu saptamak) ve onaylanan iletileri (ya da ileti dizilerini) göndericiye bildirmek için kullanılır. Sekans numarası ayrıca akış kontrolü mekanizması tarafından da kullanılır. IMP alt ağı, bu aynı hedeflere ulaşmak için kendi içinde ayrıntılı mekanizmalar içerdiğinden, sekans numaralarına dayalı hata giderme mekanizmalarının sıkça devreye girmesi beklenmemektedir ve bu nedenle verimlilikleri birincil önem taşımaz.

Sekans numaraları, bir bağlantının iki yönü için bağımsız olarak atanır. Bir bağlantının belirli bir yönü için, bağlantı kurulduktan sonra iletilen ilk veri iletisi bir numaralı sekans numarasına sahip olmalıdır. Sonraki iletiler, artan (modulo 16) sekans numaralarıyla ardışık olarak atanır; yani 15 numaralı iletiden sonra gelen iletiye sıfır sekans numarası atanır.

Sekans numaraları kontrol iletilerine atanmaz; çünkü protokol bu iletilerin sıradan bağımsız olarak, olumsuz bir etki olmaksızın teslim edilebilmesine izin verecek şekilde tasarlanmıştır ve akış kontrolü kontrol bağlantısına uygulanamaz.

Kontrol İletileri

Kontrol bağlantısı üzerinden gönderilen iletiler, yukarıda belirtilen istisnalar dışında, diğer Host’tan Host’a iletilerle aynı biçime sahiptir. Ancak, kontrol iletileri 120 adet 8 bitlik bayttan fazla metin içeremez. Ayrıca, kontrol iletileri tam sayıda kontrol komutu içermelidir; tek bir kontrol komutu, farklı kontrol iletilerinde gönderilecek parçalara bölünmemelidir.

İleti Gönderimi ve Yeniden Gönderim

Kontrol iletileri, gerekli oldukları her zaman gönderilebilir. Ancak veri iletileri yalnızca akış kontrolü mekanizmasının izin verdiği durumlarda gönderilebilir; yani iletinin atanan sekans numarası, verilen bağlantının uygun yönü için “pencere” içinde olduğunda.

Sol pencere kenarı (LWE), onaylanmış en yüksek sekans numarası (modulo 16) ile tanımlanır (ya da hiçbir ileti onaylanmamışsa sıfır). Sağ pencere kenarı (RWE) ise, sol pencere kenarına en son alınan kredinin (modulo 16) eklenmesiyle tanımlanır. En son alınan kredi sıfır ise LWE = RWE olduğuna dikkat edin.

Sekans numarası SEQ olan bir ileti, SEQ ve/veya RWE’nin (olası) modulo 16 indirgenmesinden önce aşağıdaki koşul doğruysa gönderilebilir:

LWE < SEQ ≤ RWE

Aşağıdaki koşullardan herhangi biri gerçekleştiğinde iletiler yeniden gönderilmelidir:

İletilerin zaman zaman yeniden gönderilmesi gerekebileceğinden, gönderici NCP tarafından onaylanana kadar atılmamaları gerektiği açıktır. Bir ileti, sekans numarası ya da verilen bağlantının aynı yönünde onun sağındaki herhangi bir iletinin sekans numarası, bu bağlantı üzerinden diğer yönde gönderilen bir veri iletisinin onay alanında döndürüldüğünde ya da yabancı Host’tan bu bağlantı için bir ACK komutunda döndürüldüğünde onaylanmış kabul edilir.

Kontrol Komutları

Kontrol komutları 8 bitlik baytlar cinsinden biçimlendirilir. Her komut tek baytlık bir işlem kodu (opcode) ile başlar. İşlem kodları, alım sırasında tablo araması yapılmasına olanak vermek için 0, 1, 2, ... şeklinde ardışık değerler alır. Kontrol komutlarının tasarımının altında yatan koşullar ve öngörülen kullanımı Bölüm III’te açıklanmıştır.

NOP — İşlem Yok

  8
-----
|NOP|
-----

NOP komutu herhangi bir zamanda gönderilebilir ve alıcı tarafından atılmalıdır. Kontrol iletilerinin biçimlendirilmesinde yararlı olabilir.

RST — Sıfırlama

  8
-----
|RST|
-----

RST komutu, bir Host tarafından, iki Host arasında daha önce var olmuş tüm bağlantılarla ilgili bilgilerin, RST’yi alan Host’un NCP tablolarından temizlenmesi gerektiğini başka bir Host’a bildirmek için kullanılır. RST’lere yanıt vermek dışında, RST’yi gönderen Host, yanıt olarak bir RRP alınana kadar diğer Host ile daha fazla iletişim kurmamalıdır.

Bir Host, hiçbir açık bağlantısı olmayan başka bir Host ile iletişime başlamadan (örneğin bir RFC komutu göndermeden) önce bir RST komutu göndermesi ve bir RRP komutu beklemesi iyi bir uygulamadır.

RRP — Sıfırlama Yanıtı

  8
-----
|RRP|
-----

RRP komutu, bir RST komutuna yanıt olarak gönderilmelidir.

RFC — Bağlantı Talebi

 8        16           16          8      16      8
----------------------------------------------------
| RFC | my-socket | your-socket | index | size | credit |
----------------------------------------------------

RFC komutu bir bağlantı kurmak için kullanılır.

CLS — Kapatma

 8        16           16
----------------------------
| CLS | my-socket | your-socket |
----------------------------

CLS komutu bir bağlantıyı sonlandırmak için kullanılır. CLS gönderilmeden önce bağlantının tamamen kurulmuş olması gerekmez.

RCP — Bağlantı Parametrelerini Yeniden Başlatma

 8        16           16          8
-------------------------------------
| RCP | benim-socket | senin-socket | indeks |
-------------------------------------

RCP komutu, bir Host tarafından başka bir Host’a, benim-socket ile senin-socket arasında muhtemelen daha önce var olmuş bir bağlantıya ilişkin tüm bilgilerin ve indeks tarafından tanımlanan (bu Host’lar arasındaki) muhtemelen daha önce var olmuş bir bağlantıya ilişkin tüm bilgilerin, RCP’yi alan Host’un tablolarından temizlenmesi gerektiğini bildirmek için kullanılır. benim-socket, senin-socket ve indeks alanları RFC komutunda tanımlandığı şekildedir.

ACK — Onaylama

 8       8       4       4
----------------------------
| ACK | indeks | seq | crd |
----------------------------

ACK komutu, bir veri iletisi göndermeden alınan veriyi onaylamak veya kredi atamak için kullanılabilir. indeks alanındaki değer, aynı indeks değerini kullanan veri bağlantısını tanımlar (ACK’i gönderen taraftan ACK’i alan tarafa doğru yönde). indeks alanını izleyen sekiz bit (seq ve crd alanları), indeks değeriyle tanımlanan veri iletisinin 97–104. bitleriyle aynı anlama sahiptir.

NACK — Olumsuz Onaylama

 8        8       8
---------------------
| NACK | indeks | seq |
---------------------

NACK komutu, NACK’i alan tarafa, kalan alanlar tarafından tanımlanan veri iletisini derhal yeniden iletmesi gerektiğini bildirir. indeks alanı, ACK komutu için tanımlandığı şeklin aynısıdır. seq alanı, derhal yeniden iletilmesi gereken 4 bitlik sıra numarasını (sağa yaslanmış) verir.

Yeniden iletilecek veri iletisinin indeks değeri indeks’e eşit değildir; bunun yerine, NACK’i gönderen Host’un indeks ile tanımladığı veri bağlantısının diğer yönü üzerinden iletilir. Hiçbir Host’un bir NACK komutunu iletmesi veya buna göre işlem yapması zorunlu değildir; ancak NACK’in kullanımı, zaman zaman yeniden iletim gecikmesinde bir azalmaya izin verebilir.

INT — Kesme

 8       8       8
--------------------
| INT | indeks | seq |
--------------------

INT komutu, indeks alanı tarafından belirtilen veri bağlantısı için bant dışı (ve dolayısıyla akış denetimine tabi olmayan) bir sinyal sağlamak üzere kontrol bağlantısı üzerinden gönderilir. indeks değeri, INT komutunu gönderen taraftan INT komutunu alan tarafa gönderilen bir veri iletisinin 65–72. bitlerinde görünecek olan değerdir. Bu sinyalin veri bağlantısı üzerinden iletilen veriyle eşzamanlanmasının yolu, seq alanına 4 bitlik bir sıra numarasının (sağa yaslanmış) dahil edilmesidir. Bu alan tarafından belirtilen numara, bant dışı sinyali izleyen ilk veri iletisini gösterir.

ECO — Yankı İsteği

 8       8
-------------
| ECO | veri |
-------------

ECO komutu yalnızca test amaçları için kullanılır. veri alanı, ECO komutunu gönderen Host için uygun olan herhangi bir bit düzeni olabilir.

ERP — Yankı Yanıtı

 8       8
-------------
| ERP | veri |
-------------

ERP komutu, bir ECO komutuna yanıt olarak gönderilmelidir. veri alanı, gelen ECO komutundaki veri alanıyla birebir aynı olmalıdır.

Opcode Ataması

Opcode’lar 8 bitlik işaretsiz ikili sayılar olarak tanımlanır. Opcode’lara atanan değerler şunlardır:

Bu RFC, BBN Corp. ve haleflerinin desteğiyle Alex McKenzie tarafından çevrimiçi RFC arşivlerine giriş için makine tarafından okunabilir biçime dönüştürülmüştür. 7/2000.