Network Çalışma Grubu

Yorum İsteği: 468
NIC: 14742
Yazar: R. Braden, UCLA/CCN
Tarih: 8 Mart 1973

FTP Veri Sıkıştırma

I. GİRİŞ

APOLOJİ

Önerilen Dosya Aktarım Protokolü’nün (FTP) başlıca tasarım hedefleri, büyük dosyaların iletiminde güvenilirlik ve verimliliktir. Verimliliğin iki yüzü vardır: ana makine CPU’larının verimliliği ve Ağ bant genişliğinin verimli kullanımı. Blok modu, bant genişliği verimliliği için CPU ek yükünü en aza indirmeyi amaçlar; RFC 454’te "HASP" adı verilen bir kip vardır. FTP’nin "HASP" kipi gerçekte veri sıkıştırmalı iletimdir; yani iletilerdeki bilgi fazlalığını azaltan bir kodlama düzenidir.

RFC 454, "HASP" ya da sıkıştırılmış kipin açık bir tanımını içermez; bunun yerine, tarafımdan ileride yayımlanacak bir RFC’nin bu kipi tanımlayacağını belirtir. FTP öğrencileri bunu pek inandırıcı bulmayabilir; ancak şu anda söz verilen RFC’yi okuyorsunuz. Bu, hepimizin beklediğinden çok daha ileride bir tarihte gerçekleşti. Mea Culpa.

GENEL DEĞERLENDİRMELER

Ağın ilk yıllarında başlıca kullanımları uzak terminal etkileşimleri ve uzak iş girişi için tipik olan küçük ve orta ölçekli dosya iletimleriydi. Illiac IV ve Data Machine gibi olanaklar Ağ üzerinde faaliyete geçtikçe ve Ağ topluluğu yoğun veri iletim gereksinimleri olan kullanıcıları içermeye başladıkça, büyük dosya iletimi Ağ kullanımının başlıca bir kipi haline gelecektir. Örneğin, CCN’nin bir kullanıcısı her gün Ağ üzerinden 2 × 10**8 bit veri göndermeyi beklemektedir.

Burada önerilen türden yerel bayt sıkıştırması, özellikle Ağ RJE protokolü altında iletilen "yazıcı" dosyaları gibi dosyaların boyutunu azaltmada etkilidir. CCN’nin RJS hizmetiyle edinilen deneyimler, yazdırma dosyalarında tipik olarak iki ile üç arasında bir çarpanla sıkıştırma sağlandığını göstermiştir. FTP’nin, Ağ RJE protokolünün veri aktarım bölümünü bir alt küme olarak içermesi amaçlandığından, FTP’ye bir yazdırma dosyası sıkıştırma mekanizmasının eklenmesi uygundur. Bu değerlendirmeler, FTP komitesini FTP içinde bir sıkıştırılmış kip eklemeye yöneltti.

Veri sıkıştırmanın iki ana gerekçesi ekonomi ve kullanım kolaylığıdır (kullanılabilirlik). Önce ekonomiyi ele alalım; bu, esasen CPU zamanı ile iletim maliyetleri arasındaki bir değiş tokuştur. Elbette, Ağ kullanımı ücretsiz bir kaynak olduğu sürece, veri sıkıştırmanın ekonomik yönü bütünüyle olumsuzdur. Ancak bu mutlu durum sonsuza dek sürmeyecektir. Veri sıkıştırmanın maliyeti nedir?

Burada yalnızca, burada önerilen gibi basit doğrusal sıkıştırma düzenlerini ele alalım. Doğrusal derken, bir kaynak kaydını incelemek için gereken CPU zamanının kayıttaki bayt sayısıyla orantılı olmasını kastediyorum. Basit bir doğrusal düzen, örneğin yinelenen tek karakterleri saptayabilir. Yinelenen alt dizeleri saptayan karesel düzenler de düşünülebilir; ancak, kaynak dizelerin sıkıştırma algoritmasının bildiği bir yapıya sahip olduğu olası özel durumlar dışında, CPU ekonomisi karesel sıkıştırmayı desteklemez.

CCN’nin 360/91 neslindeki büyük ölçekli CPU maliyetleri için makul bir değer varsayarak, toplam sıkıştırma ve açma işlemleri için CPU maliyetlerinin megabit başına 5 sentlik bir üst sınırı olduğu sonucuna vardık; bu, basit bir doğrusal algoritmanın oldukça gevşek kodlanmasına dayanmaktadır. Bu değer, megabit başına 30 sentin üzerinde (muhtemelen çok daha üzerinde) öngörülen Ağ iletim maliyetleriyle karşılaştırılabilir.

Dolayısıyla, bant genişliğini korumak için harcanan CPU zamanı, sağlanan bant genişliği tasarrufundan belirgin biçimde daha az maliyetlidir. Hem CPU maliyetleri hem de bant genişliği maliyetleri düşüş eğilimindedir; ancak doğrusal sıkıştırma için CPU maliyeti ile bant genişliği maliyeti oranının önümüzdeki birkaç yıl içinde tersine dönmesi son derece düşük bir olasılıktır. Öte yandan, bu hesaplama karesel sıkıştırmanın kullanılmasını açıkça caydırmaktadır.

NEDEN HASP

CCN’nin toplu uzak iş girişi protokolü NETRJS (bkz. RFC 189, 15 Temmuz 1971), kesilmiş ve sıkıştırılmış olmak üzere iki veri aktarım kipini içerecek şekilde tasarlanmıştır. NETRJS kesilmiş kipi, esasen mevcut FTP blok modu kayıt yapısıyla özdeştir (küçük bit biçimi farklılıkları dışında). NETRJS’nin sıkıştırılmış kipi, IBM’in HASP sistemindeki ikili eşzamanlı RJE desteğinin "Multileaving protokolü" içinde yer alan belirli sıkıştırma düzeninin bir uyarlamasını kullanır.

FTP’de bir sıkıştırma düzeni tanımlama amacı için gerçekten gerekli olmamasına rağmen, HASP’nin ve onun RJE paketinin doğasını çok kısa biçimde özetleyen bir ek ekledim. Bu ek, IBM müşterisi olma ayrıcalığından mahrum bırakılmış Ağ Topluluğu üyeleri için kültürel bir zenginleştirme olarak görülebilir. Sonuçta, TENEX’i hiç duymamış pek çok HASP uzmanı tanıyorum! Daha ciddi olarak, HASP IBM makinelerinde yaygın biçimde kullanıldığından, HASP sıkıştırma düzeni de yaygın biçimde kullanılmaktadır. NETRJS’yi tasarlarken, yaygınlığı ve makullüğü nedeniyle HASP sıkıştırma düzenini seçtik.

Bununla birlikte, HASP bit biçimlerinin bazı ayrıntıları FTP için uygun değildir ya da optimal değildir. Bu nedenle, FTP’nin sıkıştırılmış kipi için önerimiz, HASP sıkıştırma düzeninin yalnızca bir uyarlamasıdır.

Ek A’dan da açıkça görüleceği üzere, HASP’nin sıkıştırma düzeni, birebir kullanılsa bile, o sistemin çok küçük ve tali bir parçasıdır. FTP’nin sıkıştırılmış kipinin entelektüel kökenine hakkıyla atıfta bulunmamız gerekse de, FTP’deki sıkıştırılmış kipi "HASP kipi" olarak adlandırmak biraz garip görünmektedir. Bunun yaklaşan FTP toplantısında düzeltileceğine inanıyorum.

II. ÖNERİLEN FTP SIKIŞTIRILMIŞ VERİ KİPİ

Bayt boyutu B bittir. Kutuların üzerindeki sayılar alan uzunluklarını bit cinsinden gösterir.

Bayt Dizisi

1    B-1        B              B
+---+------+  +--------+ ... +--------+
| 0 |  n   |  |  d1    |     |  dn    |
+---+------+  +--------+ ... +--------+

n adet veri baytı d(1), ..., d(n)’den oluşan dizi. Sayı n pozitif olmalıdır.

Çoğaltılmış Bayt

2     B-2            B
+----+------+    +---------+
| 1 0|   n  |    |    d    |
+----+------+    +---------+

Veri baytı d’nin n kez tekrarlanmasından oluşan dizi.

Dolgu Dizisi

2     B-2
+----+------+
| 1 1|   n  |
+----+------+

n adet dolgu baytından oluşan dizi. Dolgu baytı, ASCII veya EBCDIC türü için bir boşluk karakteri ya da Image veya Local Byte Type için ikili sıfır baytıdır.

Kontrol Kaçış Dizisi

B            B
+----------+ +----------+
| 0......0 | |    C     |
+----------+ +----------+

Bir kontrol kaçış dizisinin ikinci baytı olan kontrol baytı C, Blok Modundaki tanımlayıcı bayt ile aynı kodlamaya sahip olacaktır. Buna dosya sonu ve kayıt sonu göstergeleri dahildir. Blok Modu tanımlayıcı baytının kesin kodlaması hakkında şu anda bazı belirsizlikler bulunduğundan, bunu daha fazla belirtmeyeceğim.

APL* örneğini izleyerek, dolgunun (boşluk veya 0) anlamının türe göre belirlenmesine izin verdik: karakter (ASCII | EBCDIC) ile ikili (Image | Local Byte). Bayt boyutu gönderen ana makinenin sözcük boyutuna eşitse, sıkıştırılmış kip seyrek bildirimlerin makul bir verimlilikle gönderilmesine olanak tanır.

* 1 (take) 0 1\A'ile1 (take) 0 1\2` karşılaştırınız.

EK A: HASP MULTILEAVING

HASP (Houston Automatic Spooling Program), esasen OS/360 içinde bir iş olarak çalışan ancak toplu işlem yönetimi işlevlerini işletim sisteminden devralan bir alt sistemdir. Yani HASP, kart girişinin ve yazıcı ile delici çıkışının kuyruklanmasını, iş yürütmenin sıralanmasını ve zamanlanmasını ve operatör kontrol arayüzünü yönetir. Büyük ölçekli bir makinede geniş ve çeşitli bir iş yükünü çalıştırmak için sıkı yazılmış ve verimli bir sistemdir. Adı, HASP’nin başlangıçta belirli bir müşteri olan NASA Houston için yerel bir IBM grubu tarafından geliştirilmiş olması tarihsel gerçeğinden gelmektedir.

HASP, IBM dünyasında her zaman bir istisna olmuştur. Sistem yaklaşık 1965 yılında iki programcı tarafından yazılmıştır; HASP grubunun, ömrünün büyük bölümünde ortalama üç programcıdan oluştuğu tahmin edilmektedir. Grubun lideri "Bay HASP" olarak bilinen Tom Simpson’dır. HASP sistemi, (az ya da çok) yeraltı kanalları aracılığıyla birçok orta ve büyük ölçekli 360’a hızla yayılmıştır. En az bir kez, yalnızca yoğun müşteri baskısı IBM’in HASP çabasını sonlandırmasını engellemiştir. HASP, kullanıcıları arasında şaşırtıcı bir duygusal gizem üretmiştir. SHARE Toplantılarındaki HASP oturumları, canlanma toplantılarını andırırdı. Yıllar boyunca her SHARE Toplantısı, gece açık bar sırasında piyano etrafında HASP şarkı oturumlarını içermiştir. HASP, IBM’in büyük makine işinin tarihinde büyüleyici bir bölüm oluşturmaktadır.

HASP’deki temel kavramlar yalancı aygıtlar ve işletim sisteminin kendisini değiştirmeden işletim sistemi işlevlerini genişletmek için denetleyici çağrılarını yakalama genel tekniğidir. Bir nesil OS/360 sistem programcısı bu teknikleri HASP’den öğrenmiştir. (Bu önemli teknikler literatürde neredeyse hiç anlatılmaz ve "pratik" programcılar da zaten literatürü okumaz.)

HASP başlatıldığında (denetleyici durumda), G/Ç Denetleyicisindeki bir komutu kendi koduna dallanan bir komutla üst üste yazar. Bir kullanıcı programı, kart okuyuculara ve yazıcılara gerçek G/Ç yapıyormuş gibi yazılır. HASP, bu G/Ç işlemlerini yakalar ve yorumlayarak, iş G/Ç’sunu OS/360 için saydam bir biçimde yönetir. Benzer şekilde operatör konsolu G/Ç’sunu da yakalar ve yorumlar.

HASP, ikili eşzamanlı iletişim kullanan toplu uzak iş girişini içerir. HASP iletişim protokolü ve ileti biçimleri, Simpson’ın grubu tarafından geliştirilen "Multileaving Protokolü" adı verilen bir düzeni kullanır. IBM’in şimdiye kadar ürettiği açık ara en iyi RJE paketi olan HASP RJE sistemi, sonunda iki rakip IBM paketinin yerini almış ve fiilen IBM’in RJE standardı haline gelmiştir. CCN’nin RJS sistemi yalnızca Multileaving Protokolünü benimsemekle kalmamış, aynı zamanda ikili eşzamanlı iletişim hat işleyicisini doğrudan HASP’den neredeyse kopyalamıştır.

Multileaving Protokolü, HASP el kitabında "ikili eşzamanlı iletişim olanaklarını kullanarak iki veya daha fazla bilgisayar arasında değişken sayıda veri akışının tam eşzamanlı, sözde eşzamanlı, çift yönlü iletimi" olarak tanımlanır. Uzak bir toplu iş terminalinin, tek bir iletişim hattı üzerinden farklı hızlarda değişken sayıda kart okuyucu ve yazıcıyı eşzamanlı olarak çalıştırmasına olanak tanır. HASP Multileaving’in, IMP-IMP Protokolünün ve biraz da ana makine–ana makine protokolünün birçok özelliğini küçük ölçekte içermesi şaşırtıcı değildir. Özellikle Multileaving aşağıdaki genel özellikleri içerir:

1. Saydamlık kullanan "konuşmalı" iletim hattı protokolü (DLE STX vb.).
2. 16 bitlik bir CRC ve modulo-16 blok sıra numarası kullanan "güçlü" hata denetimi ve yeniden iletim.
3. Her iki yönde çoklu akışlar için akış denetimi. Buna, bir akışı açmak için eşleşen kontrol kayıtlarının ("RFC’ler") değiş tokuşu ve her blokta bir dizi akış denetim biti dahildir. Her akış denetim biti, belirli bir akış için bir ileti (tampon) başına bir ALLOcate komutuna mantıksal olarak eşdeğerdir.
4. Uzak aygıtlar için isteğe bağlı Özel Kontrol Bilgisi. Buna yazıcı satır başı denetimi, kart okuyucu haznelerinin değiştirilmesi vb. dahildir.
5. Birden çok akışın iletim için tek bir blok içinde çoklanması ("multileaving").
6. Her akış içinde dosya sonunun ve kayıt sonlarının işaretlenmesi.
7. Yinelenen boşlukları ve yinelenen tek karakterleri kodlayarak iletilen metnin sıkıştırılması.

Son olarak, HASP’nin FTP ile ilgili olan (tek) yönüne geldik: sıkıştırma düzeni. HASP aşağıdaki kodlamayı kullanır:

HASP Sıkıştırma Kodlaması

Kayıt Sonu

8
+---------+
| 0 ... 0 |
+---------+

Veri Dizisi

2   6           8           8
+---+------+ +-------+ ... +-------+
|1 1|  N   | |  d1   |     |  dN   |
+---+------+ +-------+ ... +-------+

N Adet Yinelenen Boşluk

3   5
+---+------+
|100|  N   |
+---+------+

N Adet Çoğaltılmış D Karakteri

3   5        8
+---+------+ +---------+
|101|  N   | |    D    |
+---+------+ +---------+

HASP yalnızca 8 bitlik baytlarla ilgilenir. Ancak Multileaving Protokolünde, N sayımlarının birimini 1 bayt, 2 bayt veya 4 bayt olarak ayarlamaya yönelik bir hüküm vardır (hiçbir zaman uygulanmamıştır).

Kaynakça

1. HASP II System Manual, IBM Corporation (26 Şubat 1971)

Bu RFC, çevrimiçi RFC arşivlerine girilmek üzere Nisan 2000’de Via Genie tarafından makine tarafından okunabilir biçime dönüştürülmüştür.