Mesaj Veri Türleri

İçindekiler

• Genel Bakış
• Öneri
• Gerekçe
• Faydalar
• Uygulama Yaklaşımı
• Geriye Dönük Uyumluluk
• Gelecekte Standartlaştırma
• Önemi

Genel Bakış

MIT Lincoln Laboratory'den E.I. Ancona, normal ARPANET mesajlarının ilk sekiz bitinin bir mesaj veri türü alanı için ayrılmasını önermektedir. Bu öneri, tek bir veri biçimi dayatmadan farklı HOST uygulamaları arasında mesaj yorumlamasını standartlaştırma sorununu ele almaktadır.

Öneri

Temel Tavsiye

Normal bir mesajın ilk sekiz bitinin bir mesaj veri türü alanı için ayrılmasını öneriyoruz.

Bunun Anlamı

• Ayrılmış bitler - Her mesajın ilk okteti (8 bit) tür bilgisine ayrılır
• Kullanıcı verisi için mevcut değildir - Bu alan uygulama düzeyindeki veri yükü için kullanılamaz
• Açık bir kural - Mesaj içeriğini tanımlamak için açık bir protokol kuralı oluşturur

Önemli Uyarı

Bu kuralın benimsenmesi kullanılacak gerçek veri türleri konusunda herhangi bir şekilde anlaşmaya varıldığı anlamına gelmez. Öneri, ilk sekiz bitin mesaj türü için ayrıldığını belirleyen bir kural oluşturur; gerçek tür değerleri ve anlamlarının ayrı olarak tanımlanmasını açık bırakır.

Gerekçe

Sorun

Mesajların içeriğine ilişkin kuralların ARPANET geliştirme sürecinin erken aşamalarında belirlenmesi birkaç nedenle önemlidir:

1. Çoğalmanın önlenmesi - Her program çifti arasında çok sayıda farklı mesaj biçimi kuralının ortaya çıkmasını engellemek
2. Standartlaştırma - Ağ genelinde çalışabilecek ortak yaklaşımlar belirlemek
3. Verimlilik - Mesaj türü tanımlarını paylaşarak tekrarlanan çalışmayı azaltmak

Standartlaşma Eksikliği

ARPANET sitelerinde kullanılan HOST mimarilerinin ve programlama dillerinin çeşitliliği, evrensel mesaj biçimi standartlaştırmasını pratik olmaktan çıkarır. Farklı HOST'larda:

• Farklı bayt sıralamaları (big-endian ve little-endian)
• Farklı kayan nokta gösterimleri
• Farklı karakter kodlamaları
• Farklı veri yapısı düzenleri

Evrensel ikili uyumluluğu zorlamak yerine, bir mesaj türü alanı her uygulamanın tür göstergesine bakarak mesaj biçimini anlamasını sağlar.

Faydalar

Üst Düzey Protokol Geliştirmeyi Sağlama

Ağ kullanımı arttıkça, mesajların hem sözdizimini hem de anlamsal içeriğini belirtmek için ağ dilleri gelişebilir. Ancak bu kadar kapsamlı kurallar geliştirilmeden önce bile, basit bir mesaj türü göstergesi temel yorumlamayı mümkün kılar.

Örnek Fayda: Tür Tabanlı Ayrıştırma

Uygulama yazılımı mesaj türünü kullanarak şunları yapabilir:

• Hangi ayrıştırma yordamının çağrılacağını belirlemek
• Veri temsilini anlamak (ikili ya da ASCII)
• Beklenen mesaj yapısını ve boyutunu bilmek
• Genişletilmiş veya varyant mesaj türlerini ele almak

Tür Alanı

8 bitlik tür alanı 256 olası mesaj türü sağlar ve mantıksal olarak şu şekilde bölünebilir:

Uygulama Yaklaşımı

Hâlihazırda Çalışan Programlar

Hâlihazırda çalışan programların bu kuralla birlikte çalışmaya devam etmesi önemlidir. Geriye dönük uyumluluk korunmalıdır.

Sistem Programları Çözümü

Şunları gerçekleştiren iki sistem programı yazılmasını öneriyoruz:

1. Ekleme - Tür alanından haberdar olmayan programlar tarafından gönderilen mesajlara otomatik olarak tür bilgisi eklemek
2. Kaldırma - Tür alanını beklemeyen programlara gelen mesajlardan tür alanını çıkarmak
3. Test etme - Tür bilgisinin doğru şekilde bulunup bulunmadığını doğrulamak

Bu uyarlayıcı programlar geriye dönük uyumluluğu şu şekilde sağlar:

• Tür bilgisini kullanan yeni programların eski programlarla iletişim kurabilmesine olanak tanır
• Eski programların tür bilgisi kullanan ağ hizmetlerinden yararlanmasına olanak tanır
• Eski ve yeni mesaj biçimleri arasında köprü kurar

Ağ Geçidi İşlevi

Bu sistem programları pratikte şu işlevleri yerine getirir:

• Ara katman - Ara çeviri katmanı
• Protokol uyarlayıcısı - Türlü ve türsüz mesaj biçimleri arasında dönüşüm yapar
• Geliştirme aracı - Tür farkındalığına sahip sistemlere kademeli geçişi mümkün kılar

Geriye Dönük Uyumluluk

Birlikte Çalışabilirlik Sorunu

Dikkatli bir tasarım yapılmazsa, tür alanının eklenmesi onu beklemeyen veya anlamayan mevcut programlarla uyumluluğu bozar.

Kademeli Geçiş

Sistem programı yaklaşımı kademeli geçişi mümkün kılar:

Aşama 1: Mevcut programlar değişmeden çalışır; sistem programları tür alanlarını ekler veya kaldırır
Aşama 2: Yeni programlar tür farkındalığına sahip tasarımı benimser; sistem programları gerektiğinde köprü görevi görür
Aşama 3: Tam geçiş; sistem programlarına artık gerek kalmaz

Bu aşamalı yaklaşım, tüm uygulamaların aynı anda güncellenmesini gerektirmeden ağın evrimleşmesine olanak tanır.

Gelecekte Standartlaştırma

Uzun Vadeli Vizyon

Anlık öneri yalnızca ilk sekiz bitin mesaj türü için ayrılması olsa da, daha uzun vadeli vizyon şunları içerir:

1. Standart mesaj türlerini tanımlamak - Yaygın mesaj türlerinden oluşan bir kayıt sistemi oluşturmak
2. Şartnameleri yayımlamak - Her tür için resmi bir teknik tanım sağlamak
3. Referans uygulama - Tür işleme için kod kütüphaneleri sağlamak
4. Birlikte çalışabilirlik - Farklı sitelerden uygulamaların birlikte kullanılabilmesini sağlamak

Tür Kaydı

Bir tür kaydı şu bilgileri belirtebilir:

Önemi

RFC 42, heterojen ağlarda temel bir sorunu ele alır: Programlar farklı uygulamalardan gelen mesajların biçimini nasıl anlar?

Başlıca katkılar:

1. Tür temelli yorumlama - Mesaj türü, alıcının mesajı doğru şekilde ayrıştırmasını sağlar
2. Erken standartlaştırma - Uyumsuz sistemler çoğalmadan önce bir kural oluşturur
3. Geriye dönük uyumluluk - Uyarlayıcı programlar aracılığıyla kademeli geçiş sağlar
4. Genişletilebilirlik - Tür alanı gelecekteki eklemelere izin verir

RFC 42'deki kavramlar daha sonraki gelişmeleri önceden haber verir:

• TCP/IP içindeki protokol numaraları (TCP, UDP ve ICMP'nin protokol alanıyla tanımlanması)
• E-postadaki MIME türleri (Content-Type alanı)
• Genel olarak ağ protokolleri (Ethernet içindeki EtherType alanı)

Ancona'nın "içeriği standartlaştırmaktan" ziyade "kuralı standartlaştırmanın" daha pratik olduğu yönündeki önerisi, protokol tasarımında hâlâ merkezi öneme sahip bir ilkeyi öngörmüştür: üst düzey tanımlama (türlerin nasıl tanımlanacağını belirlemek) çoğu zaman belirli türlerin kendisinden daha önemlidir.

Network Working Group

MIT Lincoln Laboratory

31 Mart 1970