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

Resmi Protokol Hakkında Bazı Yorumlar

Yazar
Steve Crocker, Jon Postel
Kurum
UCLA
Tarih
27 Ağustos 1969
Durum
Network Working Group Yorum Talebi
Kanal
protokol/

Genel Bakış

Konu: Resmi ARPANET HOST-HOST protokolü (RFC 1) hakkında yorum.

Amaç: Mevcut protokol spesifikasyonundaki sorunları, tutarsızlıkları ve belirsiz noktaları vurgulamak.

Yaklaşım: Tartışmaları sonuçlandırmak yerine, RFC 17 dikkat gerektiren sorunları belgeler ve çözüm davet eder.

İçindekiler

  1. Önsöz
  2. Protokol Sorunları
  3. Belirsizlikler ve Boşluklar
  4. Önerilen Açıklamalar
  5. Açık Sorular
  6. Önerilen Çözümler
  7. Süreç Önerileri
  8. Önem

Önsöz

Bağlam

RFC 1 (HOST Yazılımı) ve ilgili RFC'ler ARPANET protokolünü açıklar.

Şimdiye kadar: Ağ operasyonel; çoğu bileşen iyi çalışıyor.

Ama: Uygulamalar ilerledikçe, sorunlar ortaya çıkıyor:

RFC 17'nin Amacı

Hedef: RFC 1'i veya önceki çalışmaları eleştirmek DEĞİL

Daha ziyade: Yapıcı tartışma ve çözüm için uygulama sırasında keşfedilen sorunları belgelemek

Protokol Sorunları

Sorun 1: Bağlantı Numaralandırma ve Benzersizlik

Problem

Farklı siteler bağlantı numaralarını farklı yorumluyor:

Site A: Bağlantı numaraları ağ genelinde global olarak benzersizdir
Site B: Bağlantı numaraları yalnızca her IMP'de benzersizdir
Site C: Bağlantı numaralarının yüksek bitleri özel anlama sahiptir

Sonuç: Site A'daki host Site B'deki host'a bağlandığında, bağlantı ID yorumlaması konusunda karışıklık.

Karışıklık Örneği

Host A gönderir: "1024 bağlantısına bağlan"
Hedef alır: "1024 bağlantısına bağlan"
Problem: Bunlar aynı bağlantı mı? Farklı mı?
Cevap: RFC 1 belirtmiyor!

Önerilen Çözüm

Öneri 1: Global benzersizlik

Öneri 2: Yerel benzersizlik

Soru: Hangi yaklaşım amaçlanıyor?

Sorun 2: Bayt vs. Bit İletimi

Problem

RFC 1 bazen "bit"lere ve bazen de "bayt"lara tutarsız şekilde atıfta bulunuyor.

Örnek:
"Mesajlar 0 ile 8192 bit arasında değişir"
"Sağlama toplamı 16 bit"
"Metin uzunluğu alanı 16 bit"
Soru: Mesaj uzunluğu bit cinsinden mi? Bayt mı? Her ikisi mi?

Sonuç: Uygulama sırasında belirsiz

Gerçek Dünya Sonucu

Host A 1024-bayt mesaj gönderir
"Uzunluk: 8192" der (bit: 1024 * 8)
Host B alır ve 8192'yi bayt olarak yorumlar
65.536 bit (8192 bayt) okumaya çalışır
Kilitlenme veya hata
Neden karışıklık? RFC 1 birimlerde belirsiz

Önerilen Çözüm

Öneri: Tüm boyunca bayt kullanımında tutarlılık

Gereken Eylem: RFC 1, münhasıran bayt kullanmak üzere netleştirilmeli (veya açıkça bit belirtmeli)

Sorun 3: Kontrol Mesajları vs. Veri Mesajları

Problem

RFC 1 "kontrol" ve "veri" mesajlarını ayırır ancak spesifikasyon belirsizdir.

Örnek belirsizlikler:
- Kontrol mesajları yardımcı bağlantılarda gönderilebilir mi?
- Veri mesajları kontrol ile aynı formatı takip eder mi?
- Protokolde bunları nasıl ayırt ederiz?

Örnek Karışıklık

Host kontrol mesajı gönderir (örn., "bağlantıyı kapat")
Yardımcı bağlantıda
IMP onu kontrol olarak tanımıyor
Veri olarak işliyor
Bağlantı asla kapanmıyor
Neden? RFC 1 bunu açıkça belirtmiyor

Talep Edilen Açıklama

Sorular:

  1. Bir "kontrol" mesajını ne oluşturur?
  2. Her iki bağlantı türünde de gönderilebilirler mi?
  3. Ayırt edici özellik nedir?
  4. Alıcı mesaj türünü nasıl tanımlar?

RFC 1 Belirtmeli:

Sorun 4: Hata Kurtarma Prosedürleri

Problem

RFC 1 hataları tartışır ancak kurtarma prosedürlerini belirsiz bırakır.

Örnek: Sağlama toplamı başarısız olursa ne olur?
RFC 1 der: "Hata tespit edilirse yeniden ilet"
Ama sorular:
- Kim yeniden iletir? (Host? IMP?)
- Kaç kez?
- Ne kadar beklemeli?
- Ne zaman vazgeçmeli?

Sonuç

Farklı siteler farklı kurtarma stratejileri uygular:

Site A: Host 3 kez yeniden dener, sonra vazgeçer
Site B: IMP süresiz yeniden dener
Site C: Karmaşık üstel geri çekilme
Sonuç: Ağ genelinde güvenilmez davranış

Önerilen Açıklama

RFC 1 Belirtmeli:

Sorun 5: Mesaj Parçalama

Problem

RFC 1, 8192 bite kadar mesajlara izin verir, ancak parçalamayı açıkça ele almaz.

Soru: Host 16.384-bit mesaj göndermek isterse ne olur?
Seçenekler:
A) İki 8192-bit mesaja böl
B) Tüm 16.384 biti tek mesaj olarak gönder
C) İzin verilmez
RFC 1: Hangisinin doğru olduğu belirsiz

Sonuç

Host A büyük dosyayı tek 12.000-bit mesaj olarak gönderir
IMP yönlendirmeden önce iki mesaja dönüştürür
Host B parçaları beklenmedik sırada alır
Dosya bozuk veya eksik gelir

Gerekli Açıklama

RFC 1 Belirtmeli:

Belirsizlikler ve Boşluklar

Boşluk 1: Bağlantı Yaşam Döngüsü Dokümantasyonu

Eksik: Geçerli geçişleri gösteren net durum makinesi

İstenen: 
KAPALI → (Açma talep edildi)
AÇILIYOR → (Bağlantı kabul edildi)
AÇIK → (Mesaj gönder/al)
KAPANIYOR → (Nazikçe kapanma)  
KAPALI
RFC 1'de Gerçek: Örtük; örneklerden çıkarılmalı

Eylem: RFC 1 açık durum diyagramı içermeli

Boşluk 2: Zamanlama Spesifikasyonları

Eksik: Açık zamanlama değerleri

RFC 1'in cevaplamadığı sorular:
- RFNM için ne kadar beklemeli?
- Ne sıklıkla canlı tutma gönderilmeli?
- İnaktif bağlantı için zaman aşımı?
- Yeniden iletim zaman aşımı aralığı?

Eylem: RFC 1 zamanlama parametreleri tablosu içermeli

Boşluk 3: Karakter Kodlaması

Eksik: Karakter kodlama spesifikasyonu

Soru: Metin mesajları için hangi karakter seti?
RFC 1: Bu konuda sessiz
Problem: IBM EBCDIC kullanır; diğerleri ASCII
Farklı sitelerde farklı karakter kodlaması
İletimde metin mesajları bozulur

Not: RFC 20 (henüz yayınlanmadı) bunu ele alıyor

Eylem: RFC 1 karakter kodlama standardına atıfta bulunmalı

Boşluk 4: Hata Kodları

Eksik: Hata türlerinin tam sayımı

RFC 1 bahseder:
- Sağlama toplamı hatası
- Bağlantı reddedildi
- Zaman aşımı
Ama belirtmiyor:
- Diğer hata türleri
- Hata kodu değerleri
- Hatalar host'a nasıl bildiriliyor

Eylem: RFC 1'in tam hata kodu tablosuna ihtiyacı var

Önerilen Açıklamalar

Açıklama 1: Kesin Mesaj Formatı

Mevcut RFC 1:

Mesaj şunlardan oluşur:
- 32-bit başlık
- Sağlama toplamı
- Değişken veri

Önerilen İyileştirme:

|31-24|23-16|15-8|7-0|
+-----+-----+----+---+
|  Bağlantı Numarası  |
+-----+-----+----+---+
|  Mesaj Türü         |
+-----+-----+----+---+
|  Metin Uzunluğu     |  ← Bit mi bayt mı?
+-----+-----+----+---+
|  Metin/Veri         |  ← Değişken uzunluk
+-----+-----+----+---+

Alanları, boyutları, bit sıralamasını açıkça göster

Açıklama 2: Bağlantı Numaralandırma Kuralı

Önerilen:

Bağlantı Numarası Formatı (24 bit):
+---+-------+-------+
| S | Kaynak| Hedef |
+---+-------+-------+
1   8       15
S: Kaynak (0) veya Hedef (1) tarafından kurulan bağlantı
Kaynak: Başlatan host'un tanımlayıcısı
Hedef: Hedef host'un tanımlayıcısı

Bu, benzersizlik konusundaki belirsizliği kaldırır

Açıklama 3: Yeniden İletim Politikası

Önerilen Spesifikasyon:

Yeniden İletim Prosedürü:
1. Host mesaj gönderir
2. 10 saniyelik zamanlayıcı başlatır
3. RFNM alınırsa: Zamanlayıcıyı iptal et, devam et
4. Zaman aşımı olursa: Yeniden ilet (2-3 adımlarını tekrarla)
5. 3 yeniden iletimden sonra: Başarısızlığı bildir
6. Host'a hatayı bildir

Net, test edilebilir, uygulanabilir spesifikasyon

Açık Sorular

Soru 1: BİRİNCİL Bağlantının Tam Rolü Nedir?

Şu Anda Varsayılan:

Ama: RFC 1 bunu açıkça belirtmiyor

Önerilen: RFC 1'de veya ayrı RFC'de netleştir

Soru 2: Farklı VERİ BAĞLANTILARI Aynı Birincili Kullanabilir mi?

Örnek:

Host A, Host B'ye birincil açar
Sonra aynı birincil üzerinden 10 yardımcı bağlantı açar
Yardımcı #1, #2, #3, vb. üzerinden veri gönderir
Soru: Bir birincil birden fazla yardımcıyı destekleyebilir mi?
Cevap: RFC 1 açıkça söylemiyor

Gerekli Çözüm: Çoğullama modelini netleştir

Soru 3: HOST-HOST vs. IMP-IMP Farkları Ne Olacak?

Fark Et:

Soru: Bir HOST-HOST mesajı IMP'lerden tam olarak nasıl geçer?

Gerekli Cevap: Bu çevirinin açık spesifikasyonu

Soru 4: Öncelikler Nasıl İşlenir?

Gözlem: Farklı mesajların farklı aciliyeti olabilir

Kontrol mesajları: Yüksek öncelik
Veri mesajları: Daha düşük öncelik
Acil veri: Daha yüksek öncelik
Ama RFC 1: Öncelik alanından bahsedilmiyor

Soru: Protokol öncelikleri desteklemeli mi?

Önerilen Çözümler

Çözüm 1: RFC 1 Açıklama Güncellemesi

Öneri: Açıklama belgesi yayınla

İçerik: Yukarıdaki 1-5 soruları yanıtla; 1-4 belirsizliklerini netleştir

Süreç:

  1. Editörler açıklama RFC'si hazırlar
  2. NWG inceler ve yorum yapar
  3. Nihai sürüm yayınlanır
  4. Tüm siteler uygulamaları günceller

Zaman Çizelgesi: Eylül 1969

Çözüm 2: Detaylar İçin RFC Serisine Referans

Öneri: RFC 1, diğer RFC'lere atıfta bulunursa daha kısa olabilir

RFC 1: HOST Yazılımı (ana protokol)
RFC 12: IMP-HOST Protokolü (arayüz detayları)
RFC 20: ASCII Karakter Kodlaması (metin standardı)
RFC 16: Zaman Damgası Formatı (zamanlama)
Yeni RFC: Hata Kodları ve Prosedürler
Yeni RFC: Durum Makinesi Spesifikasyonu

Avantaj: Modüler, net endişe ayrımı

Dezavantaj: Tam anlamak için birden fazla RFC'yi takip etmek gerekir

Süreç Önerileri

Öneri 1: Daha Resmi Spesifikasyon Dili

Mevcut: RFC 1 İngilizce düzyazı kullanır

Önerilen: Yapılandırılmış spesifikasyon ekle

Örnek:
MESSAGE ::= SEQUENCE {
connectionID [0] INTEGER,
messageType [1] MESSAGE-TYPE,
textLength [2] INTEGER,
data [3] OCTET STRING
}

Netliği artırır ve test üretimini sağlar

Öneri 2: Örnek İzler

Önerilen: Mesaj dizilerini dahil et

Örnek: Normal dosya transferi
Host A → IMP A: OPEN conn=1024, dest=Host B
IMP A → IMP B: (ilet)
IMP B → Host B: OPEN conn=1024, source=Host A
Host B → IMP B: OPEN-ACK conn=1024
IMP B → IMP A: (ilet)
IMP A → Host A: OPEN-ACK conn=1024
Host A → IMP A: SEND conn=1024, length=1024 [dosya verisi]
... (tüm bloklar için tekrarlanan RFNM ve SEND)
Host A → IMP A: CLOSE conn=1024

İz, beklenen davranışı netleştirir

Öneri 3: Resmi İnceleme Süreci

Önerilen: Nihai RFC'den önce yapılandırılmış inceleme

RFC Kalite Kapılarını Tanımla:
- 2+ bağımsız incelemeci tarafından teknik inceleme
- Uygulama incelemesi (gerçek sistemlerde test edildi)
- Netlik incelemesi (farklı biri okur ve anlamayı test eder)
- NWG tarafından kabul için resmi oylama

Önem

RFC 17, olgun bir süreci örnekler: sorunları bulma, belgeleme, çözümler önerme.

Tarihsel Önem

  1. Kalite İyileştirmesi: Geri bildirim daha iyi spesifikasyonlarla sonuçlanır
  2. Topluluk Tartışması: Sorunlar özel değil, kamuya açık olarak yayınlanır
  3. Yinelemeli Süreç: İlk versiyonun mükemmel olmayacağının kabulü
  4. Şeffaflık: Okuyucular neyin belirsiz olduğunu anlar

Standartlar İçin Ders

RFC 17, iyi standartların birden fazla yineleme gerektirdiğini gösterir:

Bu kalıp modern standartlar için hala geçerlidir.

Sonuç

RFC 17 eleştiri değil, yapıcı geri bildirimdir: RFC 1'deki sorunları tanımlama ve çözümler önerme.

RFC 17'nin yayınlanabilmesi gerçeği, ağ topluluğunun kalite ve şeffaflığa olan bağlılığını gösterir.

Sorunların erken tanımlanması ve tartışılması, ARPANET'in büyümesine ve başarılı olmasına izin veren sağlam, iyi belirtilmiş protokollere yol açtı.

University of California, Los Angeles (UCLA)

Network Working Group

Ağustos 1969