Ağ Çalışma Grubu

Yorum Talebi: 304
NIC: 9077
Kategoriler: D3, D4, D7
Geçersiz Kıldığı: yok
Güncellediği: yok \

D. B. McKay
IBM
17 Şubat 1972

ARPA Ağı için Bir Veri Yönetim Sistemi Önerisi

Giriş

Bu öneri, ağ tabanlı bir Veri Yönetim Sistemi tasarımına ilişkin tartışmaları kolaylaştırmak amacıyla yazılmaktadır. Kullanıcıların verileri kolayca paylaşmasına olanak tanıyacak nihai protokol için eksiksiz ve kapsamlı bir tasarım sunmayı amaçlamamaktadır; bunun yerine, gerekli araçları birleşik bir biçimde tanımamıza ve geliştirmemize olanak sağlayacak, ağın kaynaklarını kullanıcı yararına en iyi şekilde yönetmesini mümkün kılacak bir çerçeve sunmaktadır.

Buradaki temel amaç, imkânsız bir problemi çözmeye çalışmak değil, kullanıcıya şimdiye kadar gerçekleştiremediği uygulamaları yapabilmesini sağlayacak gerekli bir hizmet yeteneğini sunmaktır. Amaç, ağda geliştirilmiş diğer tüm büyük işlevlerle tutarlı olmaktır; yani NCP – 2. seviye protokol, Telnet ve Form Machine. Veri Yönetim Hizmeti ya da Veri Denetim Tesisi (Data Control Facility - DCF), ağda halihazırda geliştirilmiş bu araçlar üzerine inşa edilerek, aynı işi daha yüksek bir uygulama düzeyinde yapacaktır.

Bu sistemde başvurulan ve iletilen veriler, ağ verisi olarak adlandırılan özel bir veri sınıfı olarak kabul edilecektir. Yani, bir ağ veri dili aracılığıyla adlandırılır ve tanımlanır; nerede bulunabileceğine ve yapısının ne olduğuna ilişkin tüm ilgili bilgiler bir ağ kataloğunda tutulur. Verinin fiili iletimi için erişim, Santa Barbara’daki SMFS’nin çalışma biçimine benzer şekilde, NCP soket adreslenebilir yordamları üzerinden yapılacaktır. SMFS’nin DCF tarafından kullanılan etkin bir kaynak hâline gelmesi mümkündür.

Sistem Genel Bakışı

Ağ Veri Hizmeti (Şekil 1) içinde işlevsel ve mantıksal olarak birbirinden ayrılabilen, alt işlevleri sınıflandırılıp tartışılabilen altı alan bulunmaktadır.

1. DCF’ye yönelik kullanıcı arayüzü. ARPA ağı gibi etkileşimli bir ortamda bu arayüz Telnet tarafından hizmet alır; yerel kullanıcı, terminalinden isteği DCF’ye yönlendirir. Bu durumda DCF, özelleştirilmiş bir sunucu görevi olacaktır.
2. DCF ya da Ağ Veri Hizmeti’nin tüm etkinliklerini koordine etmekten sorumlu işlevsel birim. Ayrıca diğer tüm işlevlere yönelik arayüzleri barındırır.
3. Ağ verileri hakkında tüm bilgileri içeren Ağ Kataloğu ya da Dizin.
4. Veri dönüştürme veya yeniden yapılandırma gerektiğinde çağrılacak olan Veri Yeniden Yapılandırma Hizmeti ya da Form Machine. Bu hizmet, mümkün olduğunda DCF tarafından otomatik olarak devreye alınacak ve bu sorumluluğu kullanıcıdan alacaktır. Ancak daha özelleşmiş dönüştürmeler için kullanıcı yine de Form Machine üzerinde programlar yazabilecek ve çalıştırabilecektir.
5. Uzak DCF ya da DCF′; DCF tarafından kendisine yöneltilen isteği tanıyabilecek yeterli işlevi içerir. DCF için bir sunucu görevi görür.
6. Dosya aktarım protokolü; ağda veri aktarımını denetleme aracı olarak DCF ve DCF′ tarafından başlatılacak bir işlevdir.

Bu alanların her birine ilişkin daha ayrıntılı bir tartışma aşağıdaki bölümlerde yer almaktadır.

Kullanıcı Arayüzü

RFC 146’da, DCF’nin tüm ağ kaynaklarını tek bir kaynak olarak ele alması ve bunu mümkün olan en iyi şekilde kullanması gerektiği ifade edilmiştir. Bu ifade, Veri Bilgisayarı ve Unicon depolamasının da bu kaynağın bir parçası olarak değerlendirilmesini kapsamak üzere tasarlanmıştır. Bunun ne ölçüde yapılabileceği açık bir sorudur; ancak CCA tarafından geliştirilen Veri Dili’nin kullanımı, bu ağ hizmetlerinden yararlanan kullanıcıya tutarlı bir arayüz sağlayacak ve muhtemelen Veri Derleyicisi’nin DCF tarafından kullanılmasını kolaylaştıracaktır.

Bu noktada DCF’nin, Veri Bilgisayarı dâhil olmak üzere herhangi bir yerde bulunabilen mantıksal bir işlev olduğu belirtilmelidir.

Kullanıcının tüm komutları ve güncellemeleri DCF’ye etkileşimli olarak girebilmesine izin verilmelidir. DCF, Telnet sunucu yordamıyla arayüz kuran bir kullanıcıya hizmet eden süreç olacaktır. Terminal iletimlerinin fiili verisi, kullanıcının DCF’ye ilettiği komutlar ve veriler olacaktır. Başlangıç kullanıcı arayüzü olarak Telnet protokolü benimsenerek, DCF’ye Telnet kullanan tüm kullanıcılar tarafından erişim sağlanabilir.

Gerçek kullanıcı komutları ve verilerinin kendisi, daha fazla inceleme gerektiren bir alandır. Aşağıdaki yorumlar, nihai bir veri dili ve veri işleme dilinin neler yapması gerektiğine ilişkin öneriler sunmaktadır.

Yerine getirilmesi gereken en az iki mantıksal olarak ayrı işlev vardır: verinin fiilen tanımlanması ve yeniden tanımlanması ile katalog girişi ve bilgi talebi gibi hizmet istekleri. Bu öneri, ağdaki her veritabanına erişim sağlamayı amaçlamamaktadır; bunun yerine, Veri Bilgisayarı’nın kendi veritabanına ilişkin bilgisine benzer bir biçimde, DCF tarafından kataloglanmış ve bilinen dosyaları hedeflemektedir.

CCA’nın veri dilinde ayrıntılı olarak açıklanan aşağıdaki veri tanımlama kavramları DCF için de yararlıdır. Öncelikle, veri kapsayıcıları iç içe geçmiş kutu gruplarıdır. Kutu, içinde tutulan veriyi veya diğer veri kapsayıcılarını temsil eder. Bir depolama ortamındaki adlandırılmış bir konum kümesini ifade eder. STRING, INT, REAL, PTR, ARRAY, LIST, STRUCT ve MIX gibi çeşitli veri kapsayıcı türleri de bulunmaktadır. Son olarak, bu kapsayıcıların her biri adlandırılabilir. Ad, kapsayıcıların mantıksal iç içe geçmişliğini yansıtmak üzere adların birleştirilmesiyle ilgi konusu öğeyi nitelendirebilir.

Depolama ve geri getirme mekanizmalarının DL’de önerilenlerle aynı olması gerekse de, başlangıçta veriyi süzen ve işleyen tüm işlevlerin uygulanması gerekli değildir. Örneğin, bir DCF’nin ilk uygulamasında kullanıcıya ilişkisel, mantıksal ve hesaplamalı operatörlerin sağlanması şart değildir. Bu tür hizmetlerle özellikle ilgilenen kullanıcılar, kendi inisiyatifleriyle ya da DCF’nin bir hizmeti olarak Veri Bilgisayarı’nı kullanmaya yönlendirilebilir.

Dilde belirtilen bazı operatörler önemlidir ve DCF’de dikkate alınmalıdır.

Aşağıdaki liste, bir DCF için temel operatörleri ve her bir işlevin ne olduğuna ilişkin kısa açıklamaları sunmaktadır. Her bir deyimin daha ayrıntılı bir tartışması için okuyucu CCA’nın veri dili raporunu incelemelidir.

• Atama işlemi: Değerleri kapsayıcılara yerleştirir; kapsayıcılar tekil öğeler olabilir ya da diğer kapsayıcılara başvurabilir.
• Alt indisleme: Öğe numarasına göre seçim yapılmasını sağlar. Büyük veri kapsayıcılarında yalnızca gerekli bölümlerin referans verilmesi ve iletilmesini belirtmek için güçlü bir araçtır. Dosyalar, alanlara ve kayıtlara başvuran kapsayıcılaştırma yoluyla alt kümelere ayrılabilir ve bunlar alt indisleme ile daha da sınıflandırılabilir. Bu alt indisleme işlevi, DL’nin sanal liste kavramını içerecek şekilde genişletilebilir.
• Bakım işlemleri: Dosyaların bakımı, kapsayıcıya başvurulan veriye uygulanan silme ve ekleme işlevleriyle sağlanmalıdır.

Bir katalogdaki ikinci bir husus, ağ dosyalarının yedek ya da çoğaltılmış kopyalarının tutulmasının ne ölçüde uygulanabilir olduğudur. Bu durum, doğal olarak çoklu kopya güncelleme protokolü sorusunu gündeme getirir. Önemli olmakla birlikte, bu protokolün tartışılması ve geliştirilmesinin, öncelikle salt-okunur dosyalar olan çoklu kopyaların tutulması lehine ertelenebileceğini düşünüyorum.

Deneysel nedenlerle DCF’nin, farklı konumlarda—muhtemelen NIC—tutulan ve diğer konumlardaki sistem arızaları durumunda bunlardan herhangi birine erişme yeteneğine sahip en az bir veritabanı bulunmalıdır. Bu önemli bir noktadır; bilgisayar ağının başlıca avantajlarından birini, yani daha güvenilir veri erişilebilirliğini kullanır.

Son olarak, ağ dizininin fiili konumu ilginç bir sorudur. Güvenilirlik açısından birden fazla konumda tutulmalıdır. Ağ dizini mantıksal olarak iki bölüme ayrılabilir: yerel dizin ve dağıtık dizin. Her iki bölüm de ağ verisine başvurur. Yerel bölüm, o sistemde bulunan ağ verilerine göre güncel tutulur. Ağ bölümü ise diğer dosya sistemlerinde çoğaltılmış dosyaların konumunu ve uzak tek-sistem dosyalarına yapılan başvurular için sistem işaretçilerini kaydeder.

Ağ bölümüne güncellemeler periyodik olarak yapılabilir. Bu güncellemeler, yerel bölümlerdeki değişiklikleri yansıtacaktır. Başlangıçta dağıtılan salt-okunur dosyaları ve yerel dosyalardaki değişiklikleri yansıtan yerel bölümleri dikkate alırsak, kataloğun çoklu kopyalarının ve ağ bölümlerinin eşzamanlı güncellenmesi gereksinimi çok daha az kritik hâle gelir. Ağ dizinine yönelik iki bölümlü yaklaşıma dayanarak, yerelleştirilmiş ağ verisi bulunan tüm sistemlerde kopyaların tutulmasının en uygun seçenek olduğu görülmektedir. Buna Veri Bilgisayarı üzerindeki bir katalog da dâhildir.

Veri Dönüştürme (Form Machine)

Form Machine, gerektiğinde DCF tarafından devreye alınabilen temel bir ağ işlevini temsil eder. Form Machine, başlangıçta amaçlandığı şekilde kullanılacaktır; ancak artık kullanıcı yerine DCF araya girecektir. Bu durum, kullanıcı için ağa yönelik ortak bir arayüz anlamına gelir. Kullanıcının dosya aktarımı ve dönüştürmeler için veri dilini kullanması, DCF’nin onun Form Machine hizmetlerini yönetmesi anlamına gelecektir.

Form Machine’in arkasındaki motivasyon, bir ağ veri paylaşım tesisinde sunulması gereken bir hizmetle tutarlıdır. Yani, uygulama programları programdan programa farklı biçimler gerektirir ve ağ, bireysel program gereksinimlerine uyum sağlamalıdır. Bu durum konsol yapılandırmaları ve makineye bağımlı veriler için de geçerlidir.

Hizmetin çalışma biçimi, uygulama programcısı tarafından sağlanan veri tanımlarının hizmet tarafından adlarıyla saklanmasıdır. Burada ele alınan durumda, DCF bu ağ veri akışı üzerinde veri dönüşümünü, formları adlarıyla çağırarak devreye alacaktır. Bunlar, DCF’nin genel bir uygulamasının parçası olarak yazılacak makineye bağımlı veriler için standart bir form kümesi olacak ve gerektiğinde DCF tarafından çağrılacaktır.

Veri Yeniden Yapılandırma Hizmeti (DRS) ile üç kavramsal bağlantı bulunmaktadır.

1. Kaynak kullanıcı ile DRS arasındaki kritik bağlantı. Bu durumda DCF olacaktır. Bu, kullanıcının Form Machine ile nasıl iletişim kuracağı sorusunu gündeme getirir. Kullanıcı, Telnet aracılığıyla normal yordamları ve DRS dizinini kullanabilir ya da tanımlı formları ağ kataloğunda kataloglanmış olarak DCF’nin onun adına otomatik biçimde bir bağlantı kurmasına izin verebilir.
2. Diğer iki bağlantı, DRS tarafından NCP üzerinden kurulan, kullanıcı süreci ile hizmet veren süreç arasındadır.

Form Machine ağ için son derece değerli bir hizmet sunduğundan, kullanıcı tarafından adlandırılmış formların her DRS konumunda erişilebilir olduğu şekilde birden fazla yerde bulunması zorunludur. Bu, ihtiyaç duyulduğunda hizmetin kullanılabilir olmasını sağlayacaktır. Ancak DRS’nin DCF tarafından çağrılması, iki ilginç inceleme alanını gündeme getirmektedir.

Birincisi, ağın kullanıcıya sunduğu ortak arayüz sorusudur. Veri dili ortak arayüz olacaksa, veri dili deyimlerini Form Machine için gerekli uygun parametreler ve deyimlere dönüştürecek bir eşleme hizmetinin DCF tarafından yapılması pratik ve uygulanabilir midir? Bu, tartışılması ve daha fazla araştırılması gereken bir alandır. Bu konuda herkesin bir RFC sunmasını teşvik ederim.

İkinci soru daha basittir ve dosya aktarım protokolünün, uzak bir konumdan Form Machine bağlantıları için gerekli gereksinimleri karşılamaya yeterli olup olmadığıyla ilgilidir.

Dosya Aktarım Protokolü (FTP)

FTP’nin amaçları; dosyaların paylaşımını teşvik etmek, bilgisayarların örtük (açık oturum açma olmadan) kullanımını özendirmek ve kullanıcıyı çeşitli ana bilgisayarların dosya ve depolama sistemlerindeki farklılıklardan yalıtmaktır. DCF tarafından FTP’deki bu ilgili işlemlerin kullanılması, bu fikirleri kullanıcı arayüzü bölümünde tartışılan yeniden yapılandırma ve alt dosya düzeyine genişletmemizi sağlar.

Buna ek olarak, herhangi bir sistemdeki herhangi bir DCF’ye bir dosyanın alınması ve başka bir sisteme aktarılması için istek yapılabilir. Bu, yalnızca sistemlerin örtük kullanımının teşvik edilmesi anlamına gelmez; aynı zamanda kullanıcı, dosyayı aktaran sistemle kendi sistemini açıkça bağlama yükünden kurtarılır. Örneğin, BBN’de—orada da bir DCF bulunabilir—bir analiz programı çalıştıran bir kişi, Santa Barbara 75’ten BBN’ye bir dosyanın gönderilmesi isteğini, 75 ile doğrudan iletişim kurmak zorunda kalmadan BBN’deki DCF’ye yapabilir.

Gönderme ve alma bağlantıları DCF tarafından başlatılacak, iki sistem arasındaki mantıksal bağlantı FTP’ye uyacaktır. FTP’de gerekli olabilecek tek değişiklik, DCF tarafından gönderme ve alma noktalarına gönderilen komutlara bir onay verilmesidir. Ayrıca, dosya sonu göstergesine ilişkin bir onay hem gönderen sisteme hem de DCF’ye gönderilecektir. Rename-from, rename-to, delete ve list istekleri doğrudan DCF tarafından iletilecek ve tüm onaylar kendisine geri dönecektir.

Daha önce belirtilen uzak DCF ve DCF′, tüm FTP iletilerini tanıyacak ve işleyecektir. Buna ek olarak, belirli bir kapsayıcı ya da verinin bir alt kümesi için yapılan istekleri de tanıyacaktır. Kendisine verilen bilgileri tanıyabilmeli, istenen veriye erişebilmeli ve talep edilen gerekli bilgileri ayıklayıp iletebilmelidir.

DCF′’nin karmaşıklığı, Veri Dili’nin ağ bölümüne dâhil edilen işlevsel yetenek miktarına bağlı olacaktır.

Sonuç

Bu makale, belirtilen tüm alanlarda fikirleri ve tartışmaları teşvik etmeyi amaçlamaktadır. Temel sonuç, ağda veri paylaşımını sağlamak üzere eşgüdümlü bir belirtim ve uygulama çabasını başlatmaktır.

⚠️ Uyarı: Orijinal metnin bu kısmı (2. parça) API filtresi veya bağlantı hatası nedeniyle çevrilememiştir.