Soket Numarası Ataması Üzerine Bir Not

GİRİŞ

Mevcut ve önerilen çeşitli protokollerde, ayrıca birkaç başka belgede, bir Telnet bağlantısının bir ucunu denetleyen bir kullanıcı sürecinin, Telnet soket numaralarıyla başlayan ya da onları çevreleyen bir grup soket numarasına serbestçe erişebildiği varsayımı yapılmaktadır (ya da ima edilmektedir).

Örneğin, Dosya Aktarım Protokolü (RFC 542, NIC #17759), varsayılan veri aktarım soketlerinin S+2, S+3, U+4 ve U+5 olduğunu belirtir; burada S ve U, ilk bağlantıda (ICP) yer alan sunucu ve kullanıcı soketleridir.

Benzer şekilde, önerilen Ağ Grafik Protokolü (NIC #19933), Telnet bağlantısına paralel olarak grafik verileri için ikinci bir bağlantı çifti öngörür ve (her iki uçta da) n+6 ve n+7 soketlerini kullanır; burada n, Telnet alma soketidir.

Protokol tasarımcılarının dikkatine sunmak isterim ki Ana Bilgisayar–Ana Bilgisayar Protokolü (NIC #8246), veri akış yönünü belirtmek için düşük anlamlı bitin kullanımı dışında, ana bilgisayarların soket numarası atamalarına ilişkin hiçbir yorum veya kısıtlama getirmemektedir. (Socket Number List belgesinin (RFC 503, NIC #15747) düşük anlamlı 8 bitin “kullanıcı tarafından belirlenen” olduğunu söyleyerek yaptığı gibi) daha ileri varsayımlar yapmaktan kaçınmalıyız; aksi halde bazı ana bilgisayar yazılım mimarilerini ya da protokol gerçekleştirimlerini istemeden dışlayabiliriz.

BİR ÖRNEK

Kaygımın kaynağını göstermek için, HARV-10, CMU-10A ve CMU-108’de hâlen kullanımda olan PDP-10 NCP gerçekleştiriminde ağ için kullanıcı yazılımı arayüzünü kısaca açıklayayım. Ardından, yukarıda andığım iki protokolün sabit soket numarası gereksinimlerinin, özellikle sunucu tarafında, neden gerçekleştirim zorlukları doğurduğunu göstereceğim.

Bu ana bilgisayarlardan birinde bir bağlantının açılması, bir “aygıt”ın oluşturulmasına yol açar (örneğin bir disk paketinin bağlanmasına yaklaşık olarak benzer bir biçimde). Bu nedenle, açık bir bağlantı, 10/50’de aygıtlar üzerinde yapılan birçok işlemin herhangi birine tabidir; bunlar arasında mantıksal adların atanması, veri aktarımı için açılması ve başka bir işe yeniden atanması yer alır.

NCP, (ayrıcalıksız) bir kullanıcı programının açtığı herhangi bir bağlantının soket numarasının düşük anlamlı 8 bitini belirtmesine ve diğer 24 bitin üç yoldan biriyle atanmasını istemesine izin verir:

İş numarasının bir fonksiyonu olarak, “işe göreli” bir soket oluşturacak şekilde.
Kullanıcı kimliğinin bir fonksiyonu olarak, “kullanıcıya göreli” bir soket oluşturacak şekilde.
“Garantili benzersiz” bir numara olarak; yani kullanımda olan başka hiçbir soket numarasıyla aynı yüksek anlamlı 24 bite sahip olmayacak biçimde NCP tarafından atanan bir numara.

Bir program, yerel bir soket numarasının tüm 32 bitini de belirtebilir; ancak yüksek anlamlı 24 bitin, aynı iş tarafından zaten sahip olunan başka bir soketteki karşılık gelen bitlerle aynı olması gerekir.

NCP, elbette, yukarıdaki yolların herhangi biriyle üretilen bir soketin atanmasına, yalnızca aynı ya da başka bir iş tarafından zaten kullanımda değilse izin verecektir.

FTP SUNUCU GERÇEKLEŞTİRİMİNDEKİ SORUNLAR

FTP sunucusu, bazı okuyuculara Padlipsky’nin Unified User Level Protocol’ünü (RFC 451, NIC #14135) anımsatabilecek bir biçimde gerçekleştirilmiştir. FTP işlevlerinin çoğunu (özellikle sistem erişimi ve dosya aktarımı işlevlerini) doğrudan yürütmek yerine, FTP komutlarını yerel komutlara eşler ve bunları bir alt işe bir sahte Teletype (PTY) üzerinden “yazar”; benzer şekilde yerel yanıtları da FTP yanıtlarına dönüştürür.

Bu düzenek, kullanıcı kimlik doğrulaması, muhasebe ve dosya erişimi için mevcut yazılımlardan ve mekanizmalardan azami ölçüde yararlanır ve (ayrıcalıklı) FTP sunucusunun bunları yorumlayıcı biçimde gerçekleştirmesi gereğini ortadan kaldırır. (Bu durum, RFC 501, NIC #15818’de açıklanan “en az ayrıcalık ilkesi” ile uyumludur.)

Bu gerçekleştirimde, FTP veri aktarımları, Telnet bağlantısının sunucu ucunu yöneten süreçten tamamen farklı bir süreç (farklı bir kullanıcı kimliğiyle) tarafından yürütülür. Dolayısıyla, sunucu soketleri S ve S+1 sunucu “denetim” işine aitken ve S+2 ile S+3 soketleri aynı 256 soket numarası aralığında bulunduğundan, son iki soket “veri aktarımı” alt işi tarafından erişilemez durumdadır.

Geçen bahardaki FTP toplantısına katılanlar, FTP sunucusunun Telnet soketlerine göre sabit bir veri soketi çifti kullanması gereğine, sunucunun veri soketlerini seçmede tam serbestliğe sahip olduğu eski düzenin aksine, şiddetle karşı çıktığımı hatırlayabilirler. Bunun başlıca nedeni, az önce açıkladığım “iki süreçli” düzeni dışlar gibi görünmesidir.

Aslında, bizim durumumuzda bu sorunun etrafından dolanmanın bir yolu vardır. FTP sunucusu denetim işi, veri bağlantılarını kendisi açabilir, ardından oluşturulan “aygıt”ı veri aktarımı alt işine “yeniden atayabilir”. En iyi ihtimalle yamalı bir çözüm; tercih etmek istemeyeceğim bir yaklaşım! İşler arası soket yeniden ataması, çoğu işletim sisteminde bulunması muhtemel bir işlem değildir.

GRAFİK PROTOKOLÜ İLE İLGİLİ GÜÇLÜKLER

Telnet bağlantısına paralel (sabit bir soket numarası mesafesinde) bir grafik bağlantısı sağlamak, potansiyel olarak FTP bağlantıları için yukarıda açıklananla aynı güçlüğü ortaya çıkarabilir.

Telnet iletişiminin en sık kullanılan modelinde ve birçok gerçekleştirimde, sunucu Telnet’i, denetimi altındaki “kullanıcı” sürecinden oldukça farklı bir süreçtir. Bu iki süreç genellikle işletim sisteminin uçbirim hizmeti aracılığıyla, “kullanıcı” sürecinin bir “ağ bağlantısı” yerine bir “uçbirim” algılayacağı biçimde bağlanır.

Örneğin Tenex’te, bir ağ uçbiriminden denetlenen bir işin, sunucu Telnet bağlantısı üzerinde hiçbir tutamacı yoktur; dolayısıyla grafik bağlantısı için n+6 ve n+7 soketlerinin denetimini elde etmesinin hiçbir yolu yoktur.

Harvard–Carnegie 10/50 gerçekleştiriminde ise, büyük ölçüde rastlantısal nedenlerle, ağdan giriş yapan bir işin sunucu Telnet soketleri üzerinde denetime sahip olduğu (yani sahibi sayıldığı) bir durum söz konusudur.

Bununla birlikte başka bir sorun daha vardır. Birçok işletim sistemi, uçbirimler ile işler arasındaki ilişkinin değiştirilebilmesine olanak tanır.

Alışılagelmiş terimleri kullanacak olursak, bir uçbirim bir işten “ayrılabilir” ve başka bir işe “bağlanabilir”; bu işlem, hiçbir işi ya da ağ bağlantısını yok etmeden yapılır.

Dolayısıyla, bir kullanıcının n+6 ve n+7 soketlerini kullanan bir program başlatması (burada n, sunucu Telnet alma soketidir), uçbirimini o işten ayırması, başka bir işe bağlaması, Grafik Protokolünü kullanan bir program çalıştırmayı denemesi ve veri bağlantısı girişiminin, n+6 ve n+7 soketleri zaten kullanımda olduğu için başarısız olması tamamen mümkündür (aynı n değeri için; çünkü aynı ağ uçbiriminden söz ediyoruz).

SONUÇ

Elbette, ilk bağlantının kurulması için ağ genelinde geçerli bazı soket numarası uzlaşımları gereklidir.

Standart ICP işlevleri için 0–255 soketlerinin ayrılması, bu tür uzlaşımlardan birine örnektir.

Ayrıca, basitlik amacıyla, herhangi bir sürecin, aynı anda talep etmesi koşuluyla, çift–tek bir çift gibi (ICP’de olduğu gibi) küçük bir “bitişik” soket bloğunun denetimini elde edebilmesinin makul olduğunu düşünüyorum.

Ancak yukarıdaki örneklerin gösterdiği gibi, daha ileri sabit soket numarası gereksinimleri dayatmak, tek tek ana bilgisayarlardaki protokol gerçekleştirimlerinin doğası, kullanıcı süreçlerinin yapısı vb. hakkında temelsiz varsayımlar yapma riskini beraberinde getirir.

İlk Telnet bağlantısı kurulduktan sonra, gerekli olabilecek diğer tüm bağlantılar Telnet bağlantısı üzerinden müzakere yoluyla kurulmalıdır (örneğin “Lütfen xxxxxx soketime bağlanın”, “Tamam, yyyyyy soketim üzerinden bağlanıyorum” biçimindeki iletilerle). Başlangıç bağlantısının (ICP) amaçları dışında, herhangi bir protokolün sabit soket numaraları belirtmesine kesinlikle gerek yoktur.