NAMA LAYANAN

DISTRIBUTED SYSTEMS Concept and Design – Fifth Edition
George Coulouris
Cambridge University
Jean Dollimore
formerly of Queen Mary, University of London
Tim Kindberg
matter 2 media
Gordon Blair
Lancaster University

Bab ini memperkenalkan layanan nama sebagai layanan yang berbeda yang digunakan oleh klien proses untuk mendapatkan atribut seperti alamat sumber atau objek ketika diberikan nama mereka. Entitas bernama dapat dari berbagai jenis, dan mereka dapat dikelola oleh layanan yang berbeda. Misalnya, layanan nama yang sering digunakan untuk menahan alamat dan rincian lain dari pengguna, komputer, domain jaringan, layanan dan objek remote. Demikian juga sebagai layanan nama, kita menggambarkan layanan direktori, yang mencari layanan ketika diberikan beberapa atribut mereka. masalah desain dasar untuk layanan nama, seperti struktur dan manajemen ruang nama yang diakui oleh layanan dan operasi yang layanan nama mendukung, diuraikan dan diilustrasikan dalam konteks Nama Domain Internet System (DNS).


Kami juga memeriksa bagaimana layanan nama diimplementasikan, yang meliputi aspek-aspek seperti navigasi melalui koleksi server nama ketika menyelesaikan nama, caching penamaan. Data penamaan mereplikasi data dan untuk meningkatkan kinerja dan ketersediaan. Dua studi kasus lebih lanjut termasuk: Global Name Service (GNS), dan X.500 layanan direktori, termasuk LDAP.



13.1 Pendahuluan

Dalam sistem terdistribusi, nama yang digunakan untuk merujuk kepada berbagai sumber daya seperti komputer, jasa, objek remote dan file, serta pengguna. Penamaan merupakan masalah yang mudah diabaikan tapi tetap mendasar dalam desain sistem terdistribusi. Nama memfasilitasi komunikasi dan berbagi sumber daya. Sebuah nama diperlukan untuk meminta komputer sistem untuk bertindak atas sumber daya tertentu yang dipilih dari banyak; misalnya, nama di bentuk URL diperlukan untuk mengakses halaman web tertentu. Proses tidak dapat berbagi tertentu sumber daya yang dikelola oleh sistem komputer kecuali mereka bisa menyebutkan nama mereka secara konsisten. Pengguna tidak dapat berkomunikasi satu sama lain melalui sistem terdistribusi kecuali mereka bisa menyebutkan satu lain, misalnya, dengan alamat email.

Nama bukan satu-satunya alat yang berguna identifikasi: atribut deskriptif adalah lain. Kadang-kadang klien tidak tahu nama entitas tertentu yang mereka cari, tetapi mereka memiliki beberapa informasi yang menjelaskan hal itu. Atau mereka mungkin memerlukan layanan dan tahu beberapa karakteristik tetapi tidak apa entitas mengimplementasikannya.

Bab ini memperkenalkan layanan nama, yang menyediakan klien dengan data tentang bernama objek dalam sistem terdistribusi, dan konsep terkait layanan direktori, yang menyediakan data tentang objek yang memenuhi deskripsi yang diberikan. Kami menggambarkan pendekatan yang akan diambil dalam desain dan implementasi layanan ini, menggunakan Domain Name Service (DNS), Global Name Service (GNS) dan X500 sebagai kasus studi. Kita mulai dengan memeriksa konsep dasar dari nama dan atribut.



 13.1.1 Nama, Alamat dan Atribut Lainnya

Setiap proses yang membutuhkan akses ke sumber daya tertentu harus memiliki nama atau identifier untuk itu. Contoh nama terbaca-manusia adalah nama-nama file seperti / etc / password, URL seperti http://www.cdk5.net/ dan domain Internet nama seperti www.cdk5.net. Identifier istilah kadang-kadang digunakan untuk merujuk kepada nama-nama yang ditafsirkan hanya dengan program. referensi objek remote dan menangani file NFS adalah contoh dari pengenal. Pengidentifikasi dipilih untuk efisiensi yang mereka dapat melihat ke atas dan disimpan oleh perangkat lunak.

Needham [1993] membuat perbedaan antara nama murni dan nama lainnya.Nama murni hanya uninterpreted pola bit. nama-nama non-murni berisi informasi tentang objek yang mereka beri nama; khususnya, mereka mungkin berisi informasi tentang lokasi objek. Nama murni selalu harus mendongak sebelum mereka dapat dari setiap penggunaan. Pada ekstrem yang lain dari nama murni adalah alamat obyek, nilai yang mengidentifikasi lokasi objek dan bukan pada obyek itu sendiri. Alamat efisien untuk mengakses objek, tetapi objek kadang-kadang dapat direlokasi, sehingga alamat tidak memadai sebagai sarana identifikasi. Misalnya, alamat email pengguna biasanya harus mengubah ketika mereka bergerak di antara organisasi atau penyedia layanan Internet, mereka tidak sendiri dijamin untuk merujuk kepada individu tertentu dari waktu ke waktu.

Kami mengatakan bahwa nama diselesaikan bila diterjemahkan ke dalam data tentang nama sumber daya atau objek, sering untuk memanggil tindakan atasnya. Hubungan antara nama dan objek disebut mengikat. Secara umum, nama terikat untuk atribut bernama objek, bukan pelaksanaan obyek itu sendiri.











Gambar 13.1 Terdiri domain penamaan digunakan untuk mengakses sumber daya dari URL.

Atribut adalah nilai properti yang berhubungan dengan objek. Sebuah atribut kunci dari sebuah entitas yang biasanya yang relevan dalam sistem terdistribusi adalah alamatnya. Sebagai contoh:

DNS memetakan nama domain untuk atribut dari komputer host: alamat IP-nya, jenis entri (misalnya, referensi ke server mail atau host lain) dan, misalnya, lamanya waktu entri host akan tetap berlaku.
Layanan direktori X500 dapat digunakan untuk memetakan nama seseorang ke atribut
termasuk alamat email dan nomor telepon.
The CORBA Layanan dan Layanan Trading Penamaan disajikan dalam Bab 8. Layanan Penamaan memetakan nama objek remote ke objek remote-nya referensi, sedangkan Layanan Trading memetakan nama objek remote ke nya referensi objek remote, bersama-sama dengan jumlah sewenang-wenang atribut menggambarkan objek dalam hal dimengerti oleh pengguna manusia.
Perhatikan bahwa 'alamat' dapat dianggap hanya nama lain yang harus mendongak, atau

mungkin berisi nama seperti itu. Sebuah alamat IP harus mendongak untuk mendapatkan jaringan

alamat seperti alamat Ethernet. Demikian pula, web browser dan klien email menggunakan DNS untuk menafsirkan nama-nama domain di URL dan alamat email. Gambar 13.1 menunjukkan bagian nama domain dari URL diselesaikan pertama melalui DNS ke alamat IP dan kemudian, pada hop akhir routing Internet, melalui ARP untuk alamat Ethernet untuk web Server. Bagian terakhir dari URL teratasi oleh sistem file di web server untuk mencari file yang relevan.

Nama dan jasa • Banyak nama-nama yang digunakan dalam sistem terdistribusi yang  khusus untuk beberapa layanan tertentu. Misalnya, pengguna dari situs web jejaring sosial twitter.com, memiliki nama seperti magmapoetry bahwa tidak ada layanan lain menyelesaikan.  Juga sebuah klien dapat menggunakan nama layanan khusus ketika meminta layanan untuk melakukan operasi pada nama obyek atau sumber daya yang dikelolanya. Misalnya, nama file diberikan kepada layanan file ketika meminta bahwa file tersebut dihapus, dan pengenal proses disajikan ke layanan manajemen proses ketika meminta bahwa itu akan dikirim sinyal. Nama-nama ini digunakan hanya dalam konteks layanan yang mengelola objek bernama, kecuali jika klien berkomunikasi tentang obyek bersama.

Nama juga kadang-kadang diperlukan untuk merujuk kepada entitas dalam sistem terdistribusi yang berada di luar ruang lingkup layanan tunggal. Contoh utama dari badan ini adalah pengguna (dengan nama yang tepat dan alamat email), komputer (dengan hostname seperti www.cdk5.net) dan layanan sendiri (seperti layanan file atau layanan printer). Di objek berbasis middleware, nama mengacu pada objek remote yang menyediakan layanan atau aplikasi. Perhatikan bahwa banyak dari nama-nama ini harus dibaca oleh dan bermakna untuk manusia,  karena  pengguna dan administrator sistem harus mengacu pada komponen utama dan konfigurasi sistem terdistribusi, programmer perlu merujuk ke layanan di program, dan pengguna harus berkomunikasi satu sama lain melalui sistem terdistribusi dan mendiskusikan layanan apa yang tersedia di berbagai belahan itu. Mengingat konektivitas disediakan oleh Internet, persyaratan penamaan ini berpotensi di seluruh dunia dicakupan.

Uniform Resource Identifier (URI) [Berners-Lee et al. 2005] muncul dari kebutuhan untuk mengidentifikasi sumber daya di Web, dan Internet lainnya sumber daya seperti kotak surat elektronik. Tujuan penting adalah untuk mengidentifikasi sumber daya di cara yang  koheren, sehingga mereka semua bisa diproses oleh perangkat lunak umum seperti browser. URI adalah 'seragam' dalam sintaks mereka menggabungkan bahwa tanpa batas waktu banyak jenis individu pengidentifikasi sumber daya (yaitu, skema URI), dan ada prosedur untuk mengelola name space global skema. Keuntungan dari keseragaman adalah bahwa hal itu memudahkan proses memperkenalkan jenis baru dari identifier, serta menggunakan jenis yang ada pengenal dalam konteks baru, tanpa mengganggu penggunaan yang ada.

Misalnya, jika seseorang adalah untuk menciptakan jenis baru 'widget' URI, maka URI

mulai widget: harus mematuhi sintaks URI global, serta aturan lokal ditetapkan untuk skema widget identifier. URI ini akan mengidentifikasi sumber widget dengan cara yang didefinisikan dengan baik. Tetapi bahkan perangkat lunak yang ada yang tidak mengakses sumber daya widget masih bisa memproses URI widget - misalnya, dengan mengelola direktori yang berisi mereka. Beralih ke contoh menggabungkan pengenal yang ada, yang telah dilakukan untuk nomor telepon dengan awalan mereka dengan nama skema tel dan standarisasi mereka representasi, seperti di tel: + 1-816-555-1212. URI tel ini dimaksudkan untuk penggunaan seperti web link yang menyebabkan panggilan telepon yang harus dibuat ketika dipanggil.

Uniform Resource Locator: Beberapa URI berisi informasi yang dapat digunakan untuk mencari dan mengakses sumber daya,  lain adalah nama-nama sumber daya murni. Akrab Uniform jangka Resource Locator (URL) sering digunakan untuk URI yang memberikan informasi lokasi dan menentukan metode untuk mengakses sumber daya, termasuk URL 'http' diperkenalkan di Bagian 1.6. Misalnya, http://www.cdk5.net/ mengidentifikasi halaman web di jalan yang diberikan ( '/') Pada www.cdk5.net tuan rumah, dan menentukan bahwa protokol HTTP digunakan untuk akses saya. Contoh lain adalah URL 'mailto', seperti mailto: fred@flintstone.org, yang mengidentifikasi kotak surat di alamat yang diberikan.

URL adalah pengidentifikasi efisien untuk mengakses sumber daya. Tapi mereka menderita kerugian bahwa jika sumber daya dihapus atau jika bergerak, mengatakan dari satu situs web yang lain, mungkin ada menjuntai link ke sumber daya yang mengandung URL lama. Jika pengguna mengklik link menggantung ke sumber daya web, maka web server akan baik merespon bahwa sumber daya tidak ditemukan atau - lebih buruk, mungkin - menyediakan sumber daya yang berbeda yang sekarang menempati lokasi yang sama.

Uniform Nama Sumber: Uniform Nama Sumberdaya (guci) adalah URI yang digunakan sebagai nama-nama sumber daya murni dari pada pencari. Misalnya, URI:  mid: 0E4FC272-5C02-11D9-B115-000A95B55BC8@hpl.hp.com adalah URN yang mengidentifikasi pesan email yang berisi itu di lapangan 'Pesan-Id' nya. Itu URI membedakan pesan dari pesan email lainnya. Tapi itu tidak memberikan alamat pesan di setiap toko, sehingga operasi pencarian diperlukan untuk menemukannya.

Sebuah subtree khusus URI dimulai dengan urn: telah disediakan untuk guci-meskipun, seperti pertengahan: contoh menunjukkan, tidak semua guci adalah urn: URI. Yang terakhir urn-URI diawali adalah semua bentuk urn: namespace: namespace-SPECIFICNAME. Untuk Misalnya, urn: ISBN: 0-201-62433-8 mengidentifikasi buku yang menanggung nama 0-201-62433-8 di skema penamaan standar ISBN. Misalnya lain, (diciptakan) nama urn: doi: 10,555 / musik-pop-1234 mengacu pada publikasi yang disebut musik-pop-1234 di skema penamaan dari penerbit  yang  dikenal sebagai 10,555 dalam Object Identifier Digital (DOI) Skema [www.doi.org].

Ada layanan resolusi (layanan nama, dalam terminologi bab ini) seperti Handle Sistem [www.handle.net] untuk menyelesaikan guci seperti DOI untuk atribut sumber daya, tetapi tidak ada yang digunakan secara luas. Memang, ada terus menjadi perdebatan di Web dan Internet komunitas penelitian tentang sejauh mana terpisah kategori guci diperlukan. Salah satu sekolah pemikiran adalah bahwa 'URL dingin tidak berubah'- Dengan kata lain, bahwa setiap orang harus menetapkan URL untuk sumber daya dengan jaminan tentang kelangsungan mereka acuan. Terhadap sudut pandang adalah observasi yang tidak semua orang berada dalam posisi untuk membuat jaminan seperti itu, yang membutuhkan sarana untuk mempertahankan kontrol dari nama domain dan mengelola sumber daya dengan hati-hati.



13.2 Layanan Nama dan Sistem Nama Domain

Sebuah layanan nama menyimpan informasi tentang kumpulan nama tekstual, dalam bentuk binding antara nama dan atribut dari entitas mereka menunjukkan, seperti pengguna, komputer,  jasa dan objek. Koleksi ini sering dibagi menjadi satu atau lebih konteks penamaan: himpunan bagian individu dari binding yang dikelola sebagai satu unit. Itu operasi besar bahwa layanan nama mendukung adalah untuk menyelesaikan nama - yaitu, untuk mencari atribut dari nama yang diberikan. Kami menjelaskan pelaksanaan resolusi nama di Bagian 13.2.2. Operasi juga diperlukan untuk menciptakan binding baru, menghapus binding dan daftar nama terikat, dan menambah dan menghapus konteks.

Nama manajemen dipisahkan dari jasa lainnya sebagian besar karena keterbukaan sistem terdistribusi, yang membawa motivasi berikut:

Unifikasi: Hal ini sering nyaman untuk sumber daya yang dikelola oleh layanan yang berbeda untuk digunakan skema penamaan yang sama. URI adalah contoh yang baik dari ini. Integrasi: Hal ini tidak selalu mungkin untuk memprediksi lingkup berbagi dalam terdistribusi sistem. Ini mungkin menjadi perlu untuk berbagi dan karena itu nama sumber yang dibuat dalam domain administrasi yang berbeda. Tanpa layanan nama umum, yang domain administrasi dapat menggunakan konvensi penamaan yang sama sekali berbeda.

Persyaratan nama layanan umum • layanan Nama awalnya cukup sederhana,  karena mereka dirancang hanya untuk memenuhi kebutuhan untuk mengikat nama ke alamat dalam satu domain manajemen, sesuai dengan LAN tunggal atau WAN. Interkoneksi jaringan dan skala peningkatan sistem terdistribusi telah menghasilkan jauh lebih besar Masalah nama-mapping.

Grapevine [Birrell et al. 1982] adalah salah satu yang paling awal extensible, multi-domain nama layanan. Ini dirancang untuk menjadi scalable dalam jumlah nama dan beban meminta agar hal itu bisa menangani.

Global Name Service, dikembangkan di Digital Equipment Corporation Sistem Research Center [Lampson 1986], adalah keturunan dari Grapevine dengan ambisius tujuan, termasuk. Untuk menangani sejumlah dasarnya sewenang-wenang nama dan untuk melayani jumlah sewenang-wenang organisasi administrasi: Misalnya, sistem harus mampu penanganan nama-nama semua dokumen di dunia. Seumur hidup panjang: Banyak perubahan akan terjadi dalam organisasi set nama dan dalam komponen yang menerapkan layanan selama masa pakai baterai. ketersediaan tinggi: Kebanyakan sistem lainnya tergantung pada layanan nama; mereka tidak bisa bekerja ketika rusak. Kesalahan isolasi: kegagalan lokal tidak harus menyebabkan seluruh layanan untuk gagal. Toleransi ketidak percayaan: Sebuah sistem terbuka yang besar tidak dapat memiliki komponen yang dipercaya oleh semua klien dalam sistem. Dua contoh layanan nama yang telah berkonsentrasi pada tujuan skalabilitas untuk besar jumlah benda seperti dokumen adalah layanan nama Globe [van Steen et al. 1998] dan Handle Sistem [www.handle.net]. Jauh lebih akrab adalah Internet Domain Name System (DNS), diperkenalkan pada Bab 3, yang nama komputer (dan entitas lain) di Internet. Pada bagian ini, kita membahas masalah desain utama untuk layanan nama, memberikan contoh dari DNS. Kami mengikuti ini dengan studi kasus yang lebih rinci dari DNS.



13.2.1 Nama Ruang

Sebuah ruang nama adalah koleksi semua nama yang valid diakui oleh layanan tertentu. Itu layanan akan berusaha untuk mencari nama yang valid, meskipun nama yang mungkin terbukti tidak sesuai dengan benda - yaitu, untuk menjadi terikat. Nama ruang membutuhkan sintaksis yang Definisi untuk memisahkan nama yang valid dari nama yang tidak valid. Misalnya, '...' tidak diterima sebagai nama DNS komputer, sedangkan www.cdk99.net berlaku (bahkan meskipun tidak terikat).

Nama mungkin memiliki struktur internal yang mewakili posisi mereka dalam hierarki ruang nama seperti nama path dalam sistem file, atau dalam hirarki organisasi seperti sebagai nama domain Internet, atau mereka dapat dipilih dari satu set datar numerik atau simbolik pengidentifikasi. Salah satu keuntungan penting dari hirarki adalah membuat ruang nama besar lebih mudah dikelola. Setiap bagian dari nama hierarkis teratasi relatif terpisah konteks ukurannya yang relatif kecil, dan nama yang sama dapat digunakan dengan arti yang berbeda dalam konteks yang berbeda, sesuai dengan situasi yang berbeda dari penggunaan. Dalam kasus file sistem, masing-masing direktori mewakili konteks. Jadi / etc / passwd adalah nama hierarkis dengan dua komponen. Pertama, 'dll', teratasi relatif terhadap konteks '/', atau akar, dan yang kedua bagian, 'passwd', relatif terhadap konteks '/ etc'. Nama / oldetc / passwd dapat memiliki arti yang berbeda karena komponen kedua diselesaikan dalam konteks yang berbeda. Demikian pula, nama yang sama / etc / passwd dapat mengatasi ke file yang berbeda dalam konteks dua komputer yang berbeda.

Ruang nama hirarkis berpotensi terbatas, sehingga mereka memungkinkan sistem untuk tumbuh tanpa batas. Sebaliknya, ruang nama datar biasanya terbatas. Ukuran mereka ditentukan oleh memperbaiki panjang maksimum yang diizinkan untuk nama. Keuntungan potensial lain dari  ruang nama hirarkis adalah bahwa konteks yang berbeda dapat dikelola oleh orang yang berbeda atau organisasi.

Struktur URL 'http' diperkenalkan di Bab 1. Nama URL ruang juga termasuk nama-nama relatif seperti ../images/figure1.jpg. Ketika browser atau web lainnya klien bertemu nama relatif seperti, menggunakan sumber daya di mana nama relatif tertanam untuk menentukan nama host server dan direktori yang pathname ini mengacu.

Nama-nama DNS adalah string disebut nama domain. Beberapa contoh adalah www.cdk5.net (Komputer), bersih, com dan ac.uk (tiga yang terakhir adalah domain).

Ruang nama DNS memiliki struktur hierarkis, nama domain terdiri dari satu atau lebih string disebut komponen nama atau label, dipisahkan oleh pembatas '.'. Ada tidak ada pembatas di awal atau akhir nama domain, meskipun akar DNS ruang nama kadang-kadang disebut sebagai '.' untuk tujuan administratif. Nama komponen adalah string dicetak non-null yang tidak mengandung '.'. Secara umum, Awalan dari Nama adalah bagian awal dari nama yang hanya berisi nol atau lebih seluruh komponen. Misalnya, di www DNS dan www.cdk5 keduanya prefiks dari www.cdk5.net. Nama-nama DNS tidak case-sensitive, sehingga www.cdk5.net dan WWW.CDK5.NET memiliki arti yang sama.

Server DNS tidak mengenali nama relatif: semua nama yang disebut global akar. Namun, dalam implementasi praktis, perangkat lunak klien menyimpan daftar domain. Nama-nama yang ditambahkan secara otomatis untuk setiap nama tunggal-komponen sebelum resolusi. Misalnya,  nama www disajikan dalam domain cdk5.net mungkin mengacu www.cdk5.net; perangkat  lunak klien akan menambahkan default cdk5.net domain dan berusaha untuk menyelesaikan nama ini. Jika ini gagal, maka nama domain default lebih lanjut dapat ditambahkan. Akhirnya, (mutlak) nama www akan disajikan kepada akar untuk resolusi (sebuah operasi yang tentu saja akan gagal dalam hal ini). Nama dengan lebih dari satu komponen, Namun, biasanya disajikan utuh ke DNS, sebagai nama mutlak.

Alias ​​• Alias ​​adalah nama yang ditetapkan untuk menunjukkan informasi yang sama seperti nama lain, mirip dengan symbolic link antara nama file path. Alias ​​memungkinkan lebih nyaman. Nama-nama yang akan diganti untuk yang relatif rumit, dan memungkinkan nama alternatif untuk digunakan oleh orang yang berbeda untuk entitas yang sama. Contohnya adalah penggunaan umum dari URL penyingkat, sering digunakan dalam posting Twitter dan situasi lain di mana ruang adalah pada premium. Misalnya, menggunakan web redirection, http://bit.ly/ctqjvH mengacu http://cdk5.net/additional/rmi/programCode/ShapeListClient.java. sebagai lain Misalnya, DNS memungkinkan alias di mana satu nama domain didefinisikan untuk berdiri untuk lain. Alias ​​sering digunakan untuk menentukan nama-nama mesin yang menjalankan web server atau server FTP. Misalnya, nama www.cdk5.net adalah alias untuk cdk5.net. Ini mempunyai keuntungan bahwa klien dapat menggunakan nama baik untuk web server, dan jika web server dipindahkan ke komputer lain, hanya entri untuk cdk5.net perlu diperbarui di Database DNS.

Penamaan domain • Sebuah domain penamaan adalah ruang nama yang terdapat satu kewenangan administratif secara keseluruhan bertanggung jawab untuk menetapkan nama di dalamnya. otoritas ini mengendalikan keseluruhan yang nama mungkin terikat dalam domain, tetapi gratis untuk mendelegasikan tugas ini.

Domain dalam DNS adalah koleksi dari nama domain; sintaksis, nama domain adalah akhiran umum dari nama domain di dalamnya, tapi jika tidak maka tidak dapat dibedakan dari, misalnya, nama komputer. Misalnya, bersih adalah domain yang mengandung cdk5.net. Perhatikan bahwa istilah 'nama domain' berpotensi membingungkan, karena hanya beberapa nama domain mengidentifikasi domain (orang lain mengidentifikasi komputer).

Administrasi domain dapat diserahkan kepada subdomain. Domain dcs.qmul.ac.uk - Departemen Ilmu Komputer di Queen Mary, University of London di Inggris - dapat berisi nama setiap departemen keinginan. Namun nama domain dcs.qmul.ac.uk sendiri harus setuju dengan otoritas perguruan tinggi, yang mengelola domain qmul.ac.uk. Demikian pula, qmul.ac.uk telah harus disepakati dengan otoritas terdaftar untuk ac.uk, dan sebagainya.

Tanggung jawab untuk penamaan domain biasanya bergandengan tangan dengan tanggung jawab untuk mengelola dan menjaga up-to-date yang sesuai bagian dari database disimpan dalam server nama otoritatif dan digunakan oleh layanan nama. Penamaan data milik domain penamaan yang berbeda pada umumnya disimpan dengan nama yang berbeda server dikelola oleh otoritas terkait.

Menggabungkan dan menyesuaikan ruang nama • DNS menyediakan global dan homogene ruang nama ous di mana nama yang diberikan mengacu pada entitas yang sama, tidak peduli proses yang di mana komputer mendongak nama. Sebaliknya, beberapa layanan nama memungkinkan berbeda nama ruang - ruang nama kadang-kadang heterogen - untuk dimasukkan ke dalam mereka; dan beberapa layanan nama memungkinkan ruang nama yang akan disesuaikan dengan kebutuhan individ-kelompok UAL, pengguna atau bahkan proses.

Penggabungan: Praktek pemasangan sistem file dalam UNIX dan NFS (lihat Bagian 12.3) memberikan contoh di mana bagian dari satu ruang nama yang mudah tertanam dalam lain. Tapi mempertimbangkan bagaimana untuk menggabungkan seluruh file sistem UNIX dari dua (atau lebih) komputer disebut merah dan biru. Setiap komputer memiliki akar sendiri, dengan tumpang tindih berkas nama. Misalnya, / etc / passwd mengacu pada satu file di merah dan file yang berbeda pada biru. Cara yang jelas untuk menggabungkan sistem file adalah untuk menggantikan akar masing-masing komputer dengan 'Super root' dan me-mount sistem file setiap komputer di akar super, mengatakan seperti / merah dan /biru. Pengguna dan program kemudian dapat merujuk / merah / etc / passwd dan / biru / etc / passwd. Tapi konvensi penamaan baru dengan sendirinya akan menyebabkan program pada dua komputer yang masih menggunakan nama lama / etc / passwd kerusakan. Sebuah solusi adalah untuk meninggalkan akar tua isi pada setiap komputer dan menanamkan sistem file mount / merah dan / biru dari kedua komputer (dengan asumsi bahwa ini tidak menghasilkan bentrokan nama dengan akar tua isi).

Moral adalah bahwa kita selalu dapat menggabungkan ruang nama dengan menciptakan akar-tingkat yang lebih tinggi konteks, tapi ini dapat meningkatkan masalah kompatibilitas ke belakang. Memperbaiki masalah kompatibilitas, pada gilirannya, meninggalkan kita dengan ruang nama hybrid dan ketidaknyamanan karena harus menerjemahkan nama lama antara pengguna dari dua computers.SECTION 13,2 LAYANAN NAMA DAN DOMAIN NAME SYSTEM 573

Heterogenitas: Distributed Computing Environment The (DCE) ruang nama [OSF 1997] memungkinkan ruang nama heterogen untuk dimasukkan di dalamnya. nama DCE mungkin mengandung persimpangan, yang mirip dengan mount point di NFS dan UNIX (lihat Bagian 12.3), kecuali bahwa mereka memungkinkan ruang nama heterogen untuk dipasang. Sebagai contoh, mempertimbangkan penuh DCE nama /.../dcs.qmul.ac.uk/principals/Jean.Dollimore. Bagian pertama nama ini, /.../dcs.qmul.ac.uk, menunjukkan konteks yang disebut sel. Komponen berikutnya adalah persimpangan. Misalnya, kepala sekolah persimpangan adalah keamanan konteks yang  mengandung kepala sekolah di mana komponen akhir, Jean. Dollimore, dapat mendongak, dan    nama-nama kepala sekolah memiliki sintaks sendiri. Demikian pula, di /.../dcs.qmul.ac.uk/files/pub/reports/TR2000-99, file persimpangan adalah konteks sesuai dengan direktori sistem file, di mana komponen akhir pub / laporan / TR2000-99 yang mendongak dan di mana ruang nama file memiliki yang berbeda sintaksis. Dua persimpangan kepala sekolah dan file adalah akar dari nama heterogen spasi, dilaksanakan oleh layanan nama heterogen.

Kustomisasi: Kami melihat pada contoh embedding file sistem NFS-mount di atas bahwa kadang-kadang pengguna lebih memilih untuk membangun ruang nama mereka secara mandiri daripada berbagi ruang nama tunggal. sistem file mount memungkinkan pengguna untuk mengimpor file yang disimpan di server dan berbagi, sementara nama-nama lainnya terus mengacu lokal, unshared file dan dapat diberikan secara otonom. Tapi file yang sama diakses dari dua komputer yang berbeda dapat dipasang pada titik-titik yang berbeda dan dengan demikian memiliki nama yang berbeda. Tidak berbagi seluruh ruang nama berarti pengguna harus menerjemahkan nama antara komputer.

Layanan Musim Semi penamaan [Radia et al. 1993] menyediakan kemampuan untuk membangun nama ruang dinamis dan berbagi konteks penamaan individu selektif. bahkan dua proses yang berbeda pada komputer yang sama dapat memiliki konteks penamaan yang berbeda. Musim semi konteks penamaan adalah benda-kelas yang bisa dibagi di sekitar sistem terdistribusi. Misalnya, pengguna di red komputer ingin menjalankan program pada biru yang masalah File path seperti / etc / passwd, namun nama-nama ini untuk menyelesaikan ke file pada itu merah sistem file, bukan biru ini. Hal ini dapat dicapai di Spring dengan melewati sebuah referensi untuk ini merah konteks penamaan lokal untuk biru dan menggunakannya sebagai konteks penamaan program. Plan 9 [Pike et al. 1993] juga memungkinkan proses untuk memiliki ruang nama sistem file mereka sendiri. Sebuah novel Fitur dari Plan 9 (yang juga dapat diterapkan di Spring) adalah bahwa direktori fisik dapat dipesan dan bergabung ke dalam direktori logis tunggal. Efeknya adalah bahwa nama mendongak di direktori logis tunggal mendongak dalam suksesi fisik direktori sampai ada pertandingan, ketika atribut dikembalikan. Ini menghilangkan perlu menyediakan daftar jalur ketika mencari program atau library file.



13.2.2 Nama Resolusi

Untuk kasus umum ruang nama hierarkis, resolusi nama merupakan berulang atau proses rekursif dimana nama berulang kali disampaikan kepada penamaan konteks dalam rangka untuk mencari atribut yang mengacu. Sebuah konteks penamaan baik memetakan sebuah nama yang diberikan ke satu set atribut primitif (seperti yang dari pengguna) secara langsung, atau peta itu ke konteks penamaan lebih lanjut dan nama yang diambil untuk disampaikan kepada konteks itu. Untuk menyelesaikan nama, itu pertama kali disajikan untuk beberapa konteks penamaan awal; iterates resolusi asalkan konteks lebih lanjut dan nama-nama yang berasal adalah output. Kami diilustrasikan ini pada awal Bagian 574 BAB 13 SERVICES NAME 13.2.1 dengan contoh / etc / passwd, di mana 'dll' disajikan dengan konteks '/', dan kemudian 'passwd' disajikan dengan konteks '/ etc'.

Contoh lain dari sifat iteratif dari resolusi adalah penggunaan alias. Untuk Misalnya, setiap kali server DNS diminta untuk menyelesaikan alias seperti www.dcs.qmul.ac.uk, server pertama menyelesaikan alias untuk nama domain lain (dalam hal ini kasus traffic.dcs.qmul.ac.uk), yang harus lebih diselesaikan untuk menghasilkan alamat IP.

Secara umum, penggunaan alias memungkinkan siklus untuk hadir dalam nama ruang, di mana penyelesaian kasus mungkin tidak pernah mengakhiri. Dua solusi yang mungkin adalah, untuk meninggalkan proses penyelesaian jika melewati sejumlah ambang resolusi, atau meninggalkan administrator untuk memveto alias yang akan memperkenalkan siklus.

Nama server dan navigasi • Setiap layanan nama, seperti DNS, yang menyimpan sangat besar database dan digunakan oleh penduduk yang besar tidak akan menyimpan semua informasi yang penamaan pada server komputer. Server tersebut akan menjadi hambatan dan titik kritis kegagalan. Setiap layanan nama banyak digunakan harus menggunakan replikasi untuk mencapai tinggi tersedianya. Kita akan melihat bahwa DNS menetapkan bahwa setiap bagian dari database-nya direplikasi dalam setidaknya dua server kegagalan-independen.

Kami disebutkan di atas bahwa data milik domain penamaan biasanya disimpan oleh server nama lokal yang dikelola oleh otoritas yang bertanggung jawab untuk domain tersebut. Meskipun, dalam beberapa kasus, server nama dapat menyimpan data untuk lebih dari satu domain, umumnya benar untuk mengatakan bahwa data yang dibagi menjadi server sesuai dengan domainnya. Kita akan melihat bahwa di DNS, sebagian besar entri untuk komputer lokal. Tapi ada juga nama server untuk semakin tinggi domain, seperti yahoo.com dan ac.uk, dan akar.

Partisi data menunjukkan bahwa nama server lokal tidak dapat menjawab semua pertanyaan tanpa bantuan server nama lainnya. Misalnya, nama server di domain dcs.qmul.ac.uk tidak akan mampu memasok alamat IP dari komputer di domain cs.purdue.edu kecuali itu cache - tentu bukan pertama kalinya itu bertanya.

Proses mencari data penamaan dari lebih dari satu nama server untuk menyelesaikan nama disebut navigasi. Nama perangkat lunak klien resolusi melakukan navigasi atas nama klien. Ini berkomunikasi dengan server nama yang diperlukan untuk menyelesaikan nama. Ini dapat diberikan sebagai kode perpustakaan dan dihubungkan ke klien, seperti misalnya dalam pelaksanaan BIND untuk DNS (lihat Bagian 13.2.3) atau di Grapevine [Birrell et al. 1982]. Alternatif, digunakan dengan X500, adalah untuk memberikan resolusi nama di terpisah Proses yang dibagi oleh semua proses client pada komputer itu.

Salah satu model navigasi yang mendukung DNS dikenal sebagai navigasi berulang (lihat Gambar 13.2). Untuk mengatasi nama, klien menyajikan nama untuk server nama lokal, yang mencoba untuk mengatasinya. Jika nama server lokal memiliki nama, ia mengembalikan hasilnya segera. Jika tidak, itu akan menyarankan server lain yang akan dapat membantu. Resolusi hasil di server baru, dengan navigasi lanjut yang diperlukan sampai Nama terletak atau ditemukan untuk menjadi terikat.

Sebagai DNS dirancang untuk menahan entri untuk jutaan domain dan diakses oleh luas jumlah klien, itu tidak akan layak untuk memiliki semua pertanyaan mulai server root, bahkan jika itu direplikasi berat. Database DNS dipartisi antara server di sedemikian rupa untuk memungkinkan banyak pertanyaan untuk menjadi puas lokal dan lain-lain harus puas tanpa perlu untuk menyelesaikan setiap bagian dari nama secara terpisah. Skema untuk menyelesaikan Nama-nama di DNS dijelaskan secara lebih rinci dalam Bagian 13.2.3.













Seorang klien iteratif kontak nama server NS1-NS3 untuk menyelesaikan nama





NFS juga mempekerjakan navigasi berulang dalam resolusi nama file, pada Komponen-by-komponen dasar (lihat Bab 12). Hal ini karena layanan file mungkin menemukan link simbolik ketika menyelesaikan sebuah nama. Sebuah link simbolik harus ditafsirkan dalam sistem file ruang nama klien karena dapat menunjuk ke sebuah file di direktori yang tersimpan di server lain. Komputer klien harus menentukan server ini, karena hanya klien tahu mount point-nya.

Dalam navigasi multicast, klien multicast nama untuk diselesaikan dan jenis objek yang diperlukan untuk kelompok server nama. Hanya server yang memegang bernama atribut merespon permintaan tersebut. Sayangnya, namun, jika nama tersebut terbukti terikat, permintaan tersebut disambut dengan keheningan. Cheriton dan Mann [1989] menggambarkan skema navigasi berbasis multicast di mana server terpisah termasuk dalam kelompok merespon ketika nama yang diperlukan tidak terikat.

Alternatif lain untuk model navigasi berulang adalah satu di mana server nama Koordinat resolusi nama dan melewati hasilnya kembali ke agen pengguna. Ma [1992] membedakan non- kursif dan navigasi server yang dikendalikan rekursif (Gambar 13.3). Di bawah non-rekursif navigasi server dikendalikan, nama server mungkin dipilih oleh klien. Server ini berkomunikasi dengan multicast atau iteratif dengan rekan-rekan dalam gaya yang dijelaskan di atas, seolah-olah klien. Di bawah rekursif server yang dikendalikan navigasi, klien sekali lagi kontak server tunggal.

Jika server ini tidak menyimpan nama, kontak server rekan menyimpan (lebih besar) awalan dari nama, yang pada gilirannya upaya untuk mengatasinya. Prosedur ini terus rekursif sampai nama teratasi. Jika layanan nama meliputi domain administrasi yang berbeda, maka klien mengeksekusi di satu domain administratif dapat dilarang mengakses server nama milik domain seperti yang lain. Selain itu, bahkan server nama dapat dilarang menemukan disposisi penamaan data di server nama di domain administrasi lain. Kemudian, kedua klien dikendalikan dan non-rekursif navigasi server terkontrol tidak pantas, dan rekursif navigasi server yang dikendalikan harus digunakan. Resmi Nama server meminta layanan data nama dari nama server yang ditunjuk dikelola oleh administrasi yang berbeda, yang mengembalikan atribut tanpa mengungkapkan di mana bagian yang berbeda dari database penamaan disimpan.















Caching • Dalam DNS dan layanan nama lainnya, nama perangkat lunak klien resolusi dan server mempertahankan cache hasil resolusi nama sebelumnya. Ketika klien memintanama lookup, perangkat lunak resolusi nama berkonsultasi cache. Jika itu memegang hasil terbaru dari lookup sebelumnya untuk nama, itu kembali ke klien; jika tidak, ia menetapkan tentang menemukan itu dari server. server yang, pada gilirannya, dapat kembali data cache dari server lain.

Caching adalah kunci untuk kinerja nama layanan dan membantu dalam menjaga ketersediaan dari kedua layanan nama dan layanan lainnya terlepas dari crash server nama. perannya dalam meningkatkan waktu respon dengan menyimpan komunikasi dengan server nama adalah jelas. Caching dapat digunakan untuk menghilangkan nama server tingkat tinggi - server root, di tertentu - dari jalur navigasi, resolusi yang memungkinkan untuk melanjutkan meskipun beberapa server yang kegagalan.

Caching oleh resolvers nama klien secara luas diterapkan dalam layanan nama dan terutama sukses karena data penamaan berubah relatif jarang. Sebagai contoh, informasi seperti komputer atau layanan alamat bertanggung jawab untuk tetap tidak berubah untuk bulan atau tahun. Namun, ada kemungkinan dari layanan nama kembali out-of-date atribut - misalnya, alamat out-of-date - selama resolusi.



13.2.3 The Domain Name System

Domain Name System adalah desain layanan nama database penamaan yang utama adalah digunakan di Internet. Itu dirancang terutama oleh Mockapetris dan ditentukan dalam RFC 1034 [Mockapetris 1987] dan RFC 1035. DNS menggantikan penamaan Internet asli skema, di mana semua nama host dan alamat diadakan di file induk pusat tunggal dan di-download oleh FTP untuk semua komputer yang diperlukan mereka [Harrenstien et al. 1985]. Skema ini asli segera terlihat menderita tiga kelemahan utama:

Ini tidak skala untuk sejumlah besar komputer.
Organisasi-organisasi lokal berharap untuk mengelola sistem penamaan mereka sendiri.
Sebuah layanan nama umum diperlukan - tidak satu yang berfungsi hanya untuk mencari
alamatnya.

Benda-benda yang ditunjuk oleh DNS terutama komputer - untuk yang terutama alamat IP disimpan sebagai atribut - dan apa yang telah kita dimaksud dalam bab ini sebagai domain penamaan disebut hanya domain di DNS. Pada prinsipnya, bagaimanapun, setiap jenis objek dapat  bernama, dan arsitekturnya memberikan ruang untuk berbagai implementasi. Organisasi dan departemen dalam mereka dapat mengelola data penamaan mereka sendiri. Jutaan nama yang terikat oleh DNS Internet, dan pencarian dilakukan terhadap hal itu dari seluruh dunia. Apa saja Nama dapat diatasi dengan klien. Hal ini dicapai dengan partisi hirarkis nama database, dengan replikasi data penamaan, dan dengan caching.

Nama domain • DNS ini dirancang untuk digunakan dalam beberapa implementasi, masing-masing yang mungkin memiliki ruang nama sendiri. Dalam prakteknya, bagaimanapun, hanya satu yang di luas menggunakan, dan itu adalah salah satu yang digunakan untuk penamaan di Internet. Nama DNS Internet ruang dipartisi baik organisasi dan sesuai dengan geografi. Nama-nama yang ditulis dengan domain tingkat tertinggi di sebelah kanan. Asli top-level organisasi domain (juga disebut domain generik) digunakan di Internet adalah:

com - Organisasi komersial

edu - Universitas dan lembaga pendidikan lainnya

gov - US lembaga pemerintah

mil - organisasi militer AS

net - pusat dukungan jaringan utama

org - Organisasi tidak disebutkan di atas

int - organisasi Internasional

Domain tingkat atas baru seperti biz dan Mobi telah ditambahkan sejak awal 2000-an. Sebuah daftar lengkap nama-nama domain generik saat ini tersedia dari Internet Assigned Numbers Authority [www.iana.org I].

Selain itu, setiap negara memiliki domain sendiri:

kita - Amerika Serikat

uk - Inggris Raya

fr - Perancis

... -...

Negara, terutama yang selain AS sering menggunakan subdomain mereka sendiri untuk membedakan organisasi mereka. Inggris, misalnya, memiliki domain co.uk dan ac.uk, yang sesuai dengan com dan edu masing-masing (ac singkatan dari 'komunitas akademik').

Perhatikan bahwa, meskipun uk akhiran geografis yang terdengar nya, domain seperti doit.co.uk bisa memiliki data mengacu komputer di kantor Spanyol dari Doit Ltd, nosional Perusahaan Inggris. Dengan kata lain, bahkan geografis yang terdengar nama domain yang konvensional dan benar-benar independen dari lokasi fisik mereka.

Query DNS • Internet DNS terutama digunakan untuk resolusi nama host sederhana dan untuk mencari host surat elektronik, sebagai berikut:

Tuan resolusi nama: Secara umum, aplikasi menggunakan DNS untuk menyelesaikan nama host  menjadi alamat IP. Sebagai contoh, ketika web browser diberikan URL yang berisi  nama domain www.dcs.qmul.ac.uk, itu membuat penyelidikan DNS dan memperoleh alamat IP yang sesuai. Seperti yang ditunjukkan dalam Bab 4, browser kemudian menggunakan HTTP untuk berkomunikasi dengan web server di alamat IP yang diberikan, menggunakan port yang dipesan Nomor jika tidak di tentukan dalam URL. FTP dan SMTP layanan bekerja dalam yang sama cara; misalnya, program FTP dapat diberikan nama domain ftp.dcs.qmul.ac.uk dan dapat membuat penyelidikan DNS untuk mendapatkan alamat IP dan kemudian menggunakan TCP untuk berkomunikasi dengan itu di nomor port yang dipesan.

Mail lokasi host: software Surat elektronik menggunakan DNS untuk menyelesaikan nama domain ke alamat IP dari host email - yaitu, komputer yang akan menerima surat untuk mereka domain. Misalnya, ketika tom@dcs.rnx.ac.uk alamat harus diselesaikan, DNS adalah bertanya dengan dcs.rnx.ac.uk alamat dan jenis peruntukan 'surat'. Saya mengembalikan daftar nama domain dari host yang dapat menerima email untuk dcs.rnx.ac.uk, jika seperti ada (dan, opsional, alamat IP yang sesuai). DNS dapat kembali lebih dari satu nama domain sehingga software email dapat mencoba alternatif jika email utama host unreachable untuk beberapa alasan. DNS mengembalikan nilai preferensi integer untuk setiap host mail, menunjukkan urutan surat host harus diadili.

Beberapa jenis lain dari permintaan yang diimplementasikan dalam beberapa instalasi tetapi kurang sering digunakan daripada mereka hanya diberikan adalah:

Resolusi sebaliknya: Beberapa perangkat lunak memerlukan nama domain untuk dikembalikan diberi Alamat IP. Ini hanya kebalikan dari normal nama host query, tapi nama server menerima permintaan balasan hanya jika alamat IP dalam domain sendiri.

Informasi host: DNS dapat menyimpan jenis arsitektur mesin dan operasi sistem dengan nama domain dari host. Ia telah mengemukakan bahwa pilihan ini harus tidak digunakan di depan umum, karena memberikan informasi yang berguna bagi mereka yang berusaha untuk mendapatkan akses tidak sah ke komputer.

Pada prinsipnya, DNS dapat digunakan untuk menyimpan atribut sewenang-wenang. Sebuah query ditentukan oleh nama domain, kelas dan jenis. Untuk nama domain di internet, kelas adalah IN. Tipe query menentukan apakah alamat IP, host mail, server nama atau beberapa jenis lain informasi yang diperlukan. Sebuah domain khusus, in-addr.arpa, ada untuk menahan alamat IP untuk reverse lookup. Atribut class digunakan untuk membedakan, misalnya, Internet penamaan database dari database penamaan (percobaan) DNS lainnya. Satu set jenis adalah ditetapkan untuk database yang diberikan; mereka untuk database Internet diberikan pada Gambar 13.5.

server nama DNS • Masalah skala diperlakukan dengan kombinasi partisi database penamaan dan mereplikasi dan caching bagian itu dekat dengan titik kebutuhan. Database DNS didistribusikan di seluruh jaringan logis dari server. Setiap server memegang bagian dari database penamaan - terutama data untuk domain lokal. pertanyaan tentang komputer dalam domain lokal dipenuhi oleh server dalam domain tersebut. Namun, setiap server mencatat nama domain dan alamat server nama lain, sehingga query yang berkaitan dengan benda-benda di luar domain dapat dipenuhi.

DNS penamaan data dibagi menjadi zona. Sebuah zona berisi data sebagai berikut:

Atribut data untuk nama dalam domain, dikurangi subdomain dikelola oleh lebih rendah untuk berwenang tingkat. Misalnya, zona bisa berisi data untuk Queen Mary, University of London - qmul.ac.uk - kurang data yang dimiliki oleh departemen (untuk Misalnya Departemen Ilmu Komputer - dcs.qmul.ac.uk).
Nama dan alamat dari setidaknya dua server nama yang memberikan otoritatif Data untuk zona. Ini adalah versi data zona yang dapat diandalkan sebagai cukup up-to-date.
Nama-nama server nama yang menyimpan data otoritatif untuk subdomain didelegasikan; dan data 'lem' memberikan alamat IP dari server tersebut.
Parameter Zona-manajemen, seperti yang mengatur caching dan replikasi data zona.
Sebuah server dapat menyimpan data otoritatif untuk nol atau lebih zona. Sehingga data penamaan yang tersedia bahkan ketika server tunggal gagal, arsitektur DNS menetapkan bahwa setiap zona harus direplikasi otoritatif dalam setidaknya dua server.

Administrator sistem memasukkan data untuk zona ke file induk, yang merupakan sumber data otoritatif untuk zona. Ada dua jenis server yang dianggap menyediakan data otoritatif. Sebuah server utama atau induk membaca data zona langsung dari file induk lokal. Sekunder Data server download zona dari primer Server. Mereka berkomunikasi secara berkala dengan server utama untuk memeriksa apakah mereka Versi disimpan cocok dengan yang dipegang oleh server utama. Jika salinan sekunder adalah dari tanggal, primer mengirimkannya versi terbaru. Frekuensi cek sekunder adalah ditetapkan oleh administrator sebagai parameter zona, dan nilainya biasanya sekali atau dua kali sehari.

Server bebas untuk cache data dari server lain untuk menghindari harus menghubungi mereka ketika resolusi nama memerlukan data yang sama lagi; hal ini ini pada ketentuan bahwa klien diberitahu bahwa data tersebut adalah non-otoritatif sebagai disediakan. Setiap entri dalam zona memiliki waktu-to-live nilai. Ketika server non-otoritatif cache data dari otoritatif server, catatan waktu untuk hidup. Ini hanya akan memberikan data cache untuk klien hingga kali ini; ketika ditanya setelah jangka waktu telah berakhir, itu recontacts yang berwibawa server untuk memeriksa datanya. Ini adalah fitur yang berguna yang meminimalkan jumlah jaringan lalu lintas sementara tetap mempertahankan fleksibilitas untuk administrator sistem. Ketika atribut diharapkan untuk mengubah jarang, mereka dapat diberikan waktu Sejalan besar untuk hidup. Jika administrator tahu bahwa atribut yang kemungkinan akan segera berubah, mereka dapat mengurangi waktu untuk hidup sesuai.

Gambar 13.4 menunjukkan susunan dari beberapa database DNS seperti berdiri di Tahun 2001. Contoh ini adalah sama berlaku saat ini bahkan jika beberapa data telah diubah sebagai sistem telah ulang dari waktu ke waktu. Perhatikan bahwa, dalam prakteknya, akar server seperti a.root-servers.net tahan entri untuk beberapa tingkatan domain, serta entri untuk pertama-nama domain tingkat. Hal ini untuk mengurangi jumlah langkah navigasi yang diperlukan untuk menyelesaikan nama domain. Nama akar server terus entri otoritatif untuk server nama untuk top-level domain. Mereka juga nama server otoritatif untuk generik tingkat atas domain, seperti com dan edu. Namun, server nama akar tidak nama server untuk domain negara. Misalnya, domain uk memiliki koleksi server nama, satu yang disebut ns1.nic.net. Nama server ini tahu nama server untuk domain tingkat kedua di Inggris seperti ac.uk dan co.uk. Nama server untuk domain ac.uk tahu nama server untuk semua domain universitas di negara, seperti qmul.ac.uk atau ic.ac.uk. Dalam beberapa kasus, delegasi domain universitas beberapa tanggung jawab untuk subdomain, seperti dcs.qmul.ac.uk.

Informasi domain akar direplikasi oleh server utama untuk koleksi server sekunder, seperti dijelaskan di atas. Meskipun ini, root server melayani ribuan atau Gambar 13.4 DNS sebuah nama server.

pertanyaan lebih per detik. Semua server DNS menyimpan alamat dari nama satu atau lebih akar server, yang tidak terlalu sering berubah. Mereka juga biasanya menyimpan alamat dari suatu Server otoritatif untuk domain induk. Sebuah query melibatkan domain tiga komponen nama seperti www.berkeley.edu dapat dipenuhi dengan menggunakan terburuk dua langkah navigasi: satu untuk root server yang menyimpan sebuah entri nama server yang sesuai, dan kedua untuk Server yang namanya dikembalikan.

Mengacu pada Gambar 13.4, nama domain jeans-pc.dcs.qmul.ac.uk dapat tampak up dari dalam dcs.qmul.ac.uk menggunakan dns0.dcs.qmul.ac.uk. server lokal Server ini tidak menyimpan entri untuk www.ic.ac.uk web server, tetapi tidak menyimpan entri cache untuk ic.ac.uk (yang diperoleh dari ns0.ja.net server yang berwenang). Server dns0-doc.ic.ac.uk dapat dihubungi untuk menyelesaikan nama lengkap.

Navigasi dan pemrosesan query • Seorang klien DNS disebut resolver a. Hal ini biasanya

diimplementasikan sebagai perangkat lunak perpustakaan. Ia menerima permintaan, format mereka ke pesan di Formulir diharapkan bawah protokol DNS dan berkomunikasi dengan satu atau lebih nama server untuk memenuhi permintaan. Sebuah sederhana request-reply protokol yang digunakan, biasanya menggunakan paket UDP di Internet (server DNS menggunakan nomor port terkenal). Itu kali penyelesai dan mengirim ulang permintaan jika diperlukan. resolver dapat dikonfigurasi untuk hubungi daftar server nama awal dalam urutan preferensi dalam satu kasus atau lebih tidak tersedia.























Arsitektur DNS memungkinkan untuk navigasi rekursif serta berulang navigasi. resolver menentukan jenis navigasi diperlukan saat menghubungi server nama. Namun, server nama tidak terikat untuk melaksanakan navigasi rekursif. Seperti yang telah disebutkan di atas, menu rekursif dapat mengikat benang Server, yang berarti bahwa permintaan lainnya mungkin akan tertunda.

Dalam rangka untuk menghemat komunikasi jaringan, protokol DNS memungkinkan untuk beberapa query untuk dikemas ke dalam pesan permintaan yang sama dan untuk server nama sejalan mengirim beberapa balasan di pesan respon mereka.

Catatan sumber daya • Data Zona disimpan oleh server nama di file dalam salah satu dari beberapa tetap jenis catatan sumber daya. Untuk database Internet, ini termasuk jenis yang diberikan dalam Gambar 13.5. Setiap record mengacu pada nama domain, yang tidak ditampilkan. Entri dalam tabel merujuk ke item yang telah disebutkan, kecuali bahwa catatan AAAA toko alamat IPv6 sedangkan Sebuah toko catatan entri IPv4 alamat, dan TXT termasuk untuk memungkinkan sewenang-wenang Informasi lain untuk disimpan bersama dengan nama domain.

Data untuk zona dimulai dengan catatan SOA-jenis, yang berisi zona parameter yang menentukan, misalnya, nomor versi dan seberapa sering sekunder harus menyegarkan salinan mereka. Ini diikuti dengan daftar catatan tipe NS menspesifikasikan nama server untuk domain dan daftar catatan jenis MX memberikan domain nama-nama host email, masing-masing diawali oleh sejumlah mengungkapkan preferensinya. Sebagai contoh, bagian dari database untuk dcs.qmul.ac.uk domain pada satu titik ditunjukkan pada Gambar 13.6, di mana waktu untuk hidup 1D berarti 1 hari.

Catatan lebih lanjut dari jenis kemudian dalam database memberikan alamat IP untuk dua nama server dns0 dan DNS1. Alamat IP dari host mail dan nama server ketiga diberikan dalam database sesuai dengan domain mereka.

Berbagi beban dengan server nama: Pada beberapa situs, sangat layanan yang digunakan seperti Web dan FTP yang didukung oleh sekelompok komputer di jaringan yang sama. Dalam hal ini, sama nama domain digunakan untuk masing-masing anggota kelompok. Ketika nama domain dibagi oleh beberapa komputer, ada satu catatan untuk setiap komputer dalam kelompok, memberikan IP-nya alamat. Secara default, nama server merespon permintaan yang beberapa catatan sesuai dengan nama yang diminta dengan mengembalikan alamat IP sesuai dengan round-robin susunan acara. klien berturut diberi akses ke server yang berbeda sehingga server dapat berbagi beban kerja. Caching memiliki potensi untuk merusak skema ini, untuk sekali non berwibawa nama server atau klien memiliki alamat server dalam cache akan terus menggunakannya. Untuk mengatasi efek ini, catatan diberikan waktu yang singkat untuk hidup.

Pelaksanaan BIND dari DNS • The Berkeley Internet Name Domain (BIND) adalah merupakan implementasi dari DNS untuk komputer yang menjalankan UNIX. program klien link dalam software perpustakaan sebagai resolver. Nama server DNS komputer menjalankan bernama daemon.

BIND memungkinkan untuk tiga kategori name server: server primer, sekunder server dan server caching-only. Program ini bernama mengimplementasikan hanya salah satu dari ini jenis, sesuai dengan isi dari file konfigurasi. Dua kategori pertama adalah sebagai dijelaskan di atas. server caching-hanya membaca di dari nama yang cukup file konfigurasi dan alamat server otoritatif untuk menyelesaikan nama apapun. Setelah itu, mereka hanya menyimpan data ini dan data yang mereka belajar dengan memecahkan nama untuk klien.

Sebuah organisasi yang khas memiliki satu server utama, dengan satu atau lebih server sekunder bahwa nama memberikan melayani pada jaringan area lokal yang berbeda di situs. Selain itu, komputer individu sering menjalankan server caching-only mereka sendiri, untuk mengurangi lalu lintas jaringan dan mempercepat waktu respon lebih jauh.

Diskusi DNS • Pelaksanaan Internet DNS mencapai relatif singkat Rata-rata waktu respon untuk pencarian, mengingat jumlah data penamaan dan skala jaringan yang terlibat. Kita telah melihat bahwa itu mencapai ini dengan kombinasi partisi, replikasi dan caching data yang penamaan. Benda-benda bernama terutama komputer, nama server dan host email. Komputer (host) nama-to-IP address pemetaan mengubah relatif jarang, seperti halnya identitas server nama dan email host, sehingga caching dan replikasi terjadi di lingkungan yang relatif sejuk.

DNS memungkinkan penamaan data menjadi tidak konsisten. Artinya, jika data penamaan adalah berubah, maka server lain mungkin menyediakan klien dengan data basi untuk periode pada urutan hari. Tak satu pun dari teknik replikasi dieksplorasi dalam Bab 18 diterapkan. Namun, inkonsistensi tidak ada konsekuensi sampai saat klien mencoba untuk menggunakan data basi.  DNS tidak membahas itu sendiri bagaimana staleness alamat terdeteksi.

Selain komputer, DNS juga nama salah satu jenis tertentu dari layanan - mail - pada basis per-domain. DNS mengasumsikan ada menjadi hanya satu layanan email per ditujukan domain, sehingga pengguna tidak perlu menyertakan nama layanan ini secara eksplisit dalam nama. aplikasi surat elektronik transparan pilih layanan ini dengan menggunakan Jenis sesuai permintaan saat menghubungi server DNS.

Singkatnya, DNS menyimpan berbagai terbatas penamaan data, tapi ini sudah cukup sejauh aplikasi seperti surat elektronik memaksakan skema penamaan mereka sendiri pada atas nama domain. Mungkin dikatakan bahwa database DNS merupakan yang terendah denominator umum dari apa yang akan dianggap berguna oleh banyak pengguna masyarakat di Internet. DNS ini tidak dirancang untuk menjadi satu-satunya layanan nama di Internet; itu berdampingan dengan nama dan direktori layanan lokal yang menyimpan data yang paling relevan dengan kebutuhan lokal (seperti Sun Layanan Jaringan Informasi, yang menyimpan password disandikan, misalnya, atau Microsoft Active Directory Services [Www.microsoft.com I], yang menyimpan informasi rinci tentang semua sumber daya dalam domain).

Yang tersisa sebagai masalah potensial untuk desain DNS adalah kekakuan dengan hormat

perubahan dalam struktur ruang nama, dan kurangnya kemampuan untuk menyesuaikan nama ruang untuk memenuhi kebutuhan lokal. Aspek-aspek penamaan desain diambil oleh kasus ini Studi tentang Global Name Service dalam Bagian 13.4. Tapi sebelum itu, kita mempertimbangkan direktori services.



13.3 Layanan Direktori

Kami telah menggambarkan bagaimana koleksi layanan nama toko <nama, atribut> pasang, dan bagaimana atribut mendongak dari nama. Itu wajar untuk mempertimbangkan ganda ini pengaturan, di mana atribut digunakan sebagai nilai yang akan mendongak. Dalam layanan ini, nama tekstual dapat dianggap hanya atribut lain. Kadang-kadang pengguna ingin menemukan orang atau sumber daya tertentu, tetapi mereka tidak tahu namanya, hanya beberapa yang lainnya atribut. Misalnya, pengguna mungkin bertanya: 'Apa nama pengguna dengan telepon nomor 020-555 9980? "Demikian juga, kadang-kadang pengguna membutuhkan layanan, tetapi mereka tidak peduli dengan apa entitas sistem pasokan layanan itu, selama layanan mudah diakses. Misalnya, pengguna mungkin bertanya, 'Yang komputer di ini Bangunan yang Macintosh yang menjalankan sistem operasi Mac OS X? 'atau' Di mana saya bisa mencetak gambar berwarna dengan resolusi tinggi? ' .

Sebuah layanan yang menyimpan koleksi binding antara nama dan atribut dan mendongak entri yang sesuai dengan spesifikasi berbasis atribut disebut layanan direktori. Contohnya adalah Microsoft Active Directory Services, X.500 dan sepupunya LDAP (Dijelaskan dalam Bagian 13,5), Univers [Bowman et al. 1990] dan Profil [Peterson 1988]. layanan direktori kadang-kadang disebut layanan halaman kuning, dan nama konvensional jasa Sejalan disebut layanan halaman putih, di analogi dengan jenis tradisional telepon. layanan direktori juga kadang-kadang dikenal sebagai atribut-layanan berbasis nama.

Sebuah layanan direktori mengembalikan set atribut dari setiap objek ditemukan yang cocok beberapa atribut yang ditetapkan. Jadi, misalnya, permintaan 'no.telepon = 020 5559980 'mungkin kembali {' Nama = John Smith ',' no.telepon = 020 555 9980 ','EmailAddress = john@dcs.gormenghast.ac.uk', ...}. Klien dapat menentukan bahwa hanya subset dari atribut yang menarik - misalnya, hanya alamat email yang cocok benda. X.500 dan beberapa layanan direktori lain juga memungkinkan objek yang akan tampak oleh nama tekstual hierarchic konvensional. Direktori Universal dan Service Discovery (UDDI), yang disajikan dalam Bagian 9.4, memberikan kedua halaman putih dan kuning layanan halaman untuk memberikan informasi tentang organisasi dan layanan web mereka menawarkan.

UDDI samping, layanan penemuan istilah biasanya menunjukkan kasus khusus dari layanan direktori layanan yang disediakan oleh perangkat dalam jaringan spontan lingkungan Hidup. Sebagai Bagian 1.3.2 dijelaskan, perangkat dalam jaringan spontan bertanggung jawab untuk menghubungkan dan memutuskan tak terduga. Salah satu perbedaan utama antara layanan penemuan dan layanan direktori lainnya adalah bahwa alamat dari layanan direktori biasanya juga dikenal dan telah dikonfigurasikan pada klien, sedangkan perangkat memasuki spontan lingkungan jaringan harus resor ke menu multicast, setidaknya pertama kali mengakses layanan penemuan lokal. Bagian 19.2.1 menjelaskan layanan penemuan dirinci.

Atribut yang jelas lebih kuat daripada nama sebagai designators benda: program dapat ditulis untuk memilih objek sesuai dengan spesifikasi atribut yang tepat di mana nama mungkin tidak diketahui. Keuntungan lain dari atribut adalah bahwa mereka tidak mengekspos struktur organisasi ke dunia luar, seperti halnya organisatoris nama dipartisi. Namun, kesederhanaan relatif penggunaan nama tekstual membuat mereka tidak mungkin digantikan oleh atribut berbasis penamaan di banyak STUDI KASUS applications.



13.4 Studi kasus: The Global Name Service

Sebuah Nama Global Service (GNS) dirancang dan dilaksanakan oleh Lampson dan rekan-rekannya di Desember Sistem Research Center [Lampson 1986] untuk menyediakan fasilitas untuk lokasi sumber daya, surat menangani dan otentikasi. Tujuan desain dari GNS telah terdaftar pada akhir Bagian 13.1; mereka mencerminkan fakta bahwa nama layanan untuk digunakan dalam sebuah internetwork harus mendukung database penamaan yang dapat memperpanjang ke termasuk nama-nama jutaan komputer dan (akhirnya) alamat email untuk miliaran pengguna. Para desainer dari GNS juga mengakui bahwa database penamaan cenderung memiliki masa pakai yang lama dan itu harus terus beroperasi secara efektif sementara itu tumbuh dari kecil untuk skala besar dan sementara jaringan di mana ia untuk dibangkitkan berdasarkan. Struktur ruang nama mungkin berubah selama waktu itu untuk mencerminkan perubahan dalam organisasi struktur. layanan harus mengakomodasi perubahan nama-nama individu, organisasi dan kelompok yang memegang, dan perubahan struktur penamaan seperti yang yang terjadi ketika salah satu perusahaan diambil alih oleh yang lain. Dalam uraian ini, kita fokus pada fitur-fitur desain yang memungkinkan untuk mengakomodasi perubahan tersebut.

Database penamaan berpotensi besar dan skala lingkungan terdistribusi di mana GNS dimaksudkan untuk beroperasi membuat penggunaan caching penting dan membuat itu sangat sulit untuk menjaga konsistensi lengkap antara semua salinan dari database masuk. Strategi konsistensi persediaan diadopsi bergantung pada asumsi bahwa update ke database akan jarang terjadi dan bahwa penyebaran lambat update diterima, karena klien dapat mendeteksi dan pulih dari penggunaan out-of-date data yang penamaan.

GNS mengelola database penamaan yang terdiri dari pohon direktori memegang nama dan nilai-nilai. Direktori yang disebut oleh multi-bagian nama path dirujuk ke root, atau relatif ke direktori kerja, seperti nama file dalam sistem file UNIX. Setiap direktori juga ditugaskan integer, yang berfungsi sebagai pengenal direktori yang unik (DI). Pada bagian ini, kita menggunakan nama dalam huruf miring ketika mengacu pada DI direktori, sehingga EC adalah identifier dari direktori EC. Sebuah direktori berisi daftar nama dan referensi. Nilai-nilai yang disimpan di daun pohon direktori tersebut akan disusun dalam nilai pohon, sehingga atribut yang terkait dengan nama-nama dapat  nilai terstruktur.

Nama dalam GNS memiliki dua bagian: <nama direktori, nama value>. Bagian pertamamengidentifikasi direktori; kedua mengacu pada pohon nilai, atau beberapa bagian dari pohon nilai. Sebagai contoh, lihat Gambar 13.7, di mana DIs diilustrasikan bilangan bulat kecil (meskipun mereka benar-benar dipilih dari berbagai bilangan bulat untuk memastikan keunikan). Atribut dari pengguna Peter.Smith di QMUL direktori akan disimpan di pohon value bernama <EC / UK / AC / QMUL, Peter.Smith>. Pohon nilai termasuk password, yang dapat dirujuk sebagai <EC / UK / AC / QMUL, Peter.Smith / password>, dan beberapa alamat email, yang masing-masing akan dicatatkan di pohon nilai sebagai simpul tunggal dengan nama <EC / UK / AC / QMUL, Peter.Smith / kotak surat>.

Pohon direktori dipartisi dan disimpan di banyak server, dengan masing-masing partisi direplikasi di beberapa server. Konsistensi pohon dipertahankan dalam menghadapi dua atau lebih update bersamaan - misalnya, dua pengguna dapat secara bersamaan mencoba untuk membuat entri dengan nama yang sama, dan hanya satu harus berhasil. direktori direplikasi menyajikan masalah konsistensi kedua; ini ditangani oleh update asynchronous algoritma distribusi yang menjamin konsistensi akhirnya, tetapi dengan tidak ada jaminan bahwa semua salinan selalu saat.

Menampung perubahan • Kita sekarang beralih ke aspek desain yang bersangkutan dengan menampung pertumbuhan dan perubahan struktur database penamaan. Pada tingkat klien dan administrator, pertumbuhan ditampung melalui perpanjangan pohon direktori dengan cara biasa. Tapi kita mungkin ingin mengintegrasikan pohon penamaan dari dua sebelumnya GNS terpisah layanan. Sebagai contoh, bagaimana kita bisa mengintegrasikan database berakar pada direktori EC yang ditunjukkan pada Gambar 13.7 dengan database lain untuk UTARA AMERIKA? Gambar 13.8 menunjukkan akar baru, WORLD, diperkenalkan di atas akar yang ada dari dua pohon yang akan digabung. Ini adalah teknik sederhana, tapi bagaimana hal itu mempengaruhi klien yang terus menggunakan nama-nama yang disebut apa 'akar' sebelum  integrasi berlangsung? Misalnya, </ UK / AC / QMUL, Peter.Smith> adalah nama yang digunakan oleh klien sebelum integrasi. Ini adalah nama yang mutlak (karena diawali dengan simbol untuk root, '/'), tapi akar itu merujuk adalah EC, tidak WORLD. EC dan AMERIKA UTARA adalah akar bekerja - konteks awal terhadap yang nama yang diawali dengan root '/' adalah untuk akan mendongak.











Keberadaan pengidentifikasi direktori yang unik dapat digunakan untuk memecahkan masalah  ini. Akar bekerja untuk setiap program harus diidentifikasi sebagai bagian dari pelaksanaannya  lingkungan (banyak seperti yang dilakukan untuk direktori kerja program ini). Ketika klien di Masyarakat Eropa menggunakan nama dalam bentuk </ UK / AC / QMUL, Peter.Smith>, yang agen pengguna lokal, yang menyadari akar kerja, prefiks direktori identifier EC (# 599), sehingga menghasilkan nama <# 599 / UK / AC / QMUL, Peter.Smith>. Agen pengguna melewati nama ini berasal dalam permintaan pencarian ke server GNS. Agen pengguna dapat menangani sama dengan nama relatif disebut direktori kerja. Klien yang sadar konfigurasi baru mungkin juga menyediakan nama mutlak untuk server GNS, yang disebut direktori super-akar konseptual yang berisi semua pengidentifikasi direktori – untuk Misalnya, <WORLD / EC / UK / AC / QMUL, Peter.Smith> - tapi desain tidak bisa berasumsi bahwa semua klien akan diperbarui untuk memperhitungkan perubahan tersebut.

Teknik yang dijelaskan di atas memecahkan masalah logika, yang memungkinkan pengguna dan program klien untuk terus menggunakan nama-nama yang didefinisikan relatif terhadap akar tua bahkan ketika akar nyata baru dimasukkan, tetapi daun masalah implementasi: dalam Database penamaan terdistribusi yang mungkin berisi jutaan direktori, bagaimana bisa GNS layanan mencari direktori tertentu hanya identifier, seperti # 599? Solusinya diadopsi oleh GNS adalah daftar direktori yang digunakan sebagai akar bekerja, seperti EC, dalam tabel 'direktori terkenal' diadakan di direktori root nyata saat penamaan Database. Setiap kali akar nyata dari perubahan database penamaan, seperti dalam Gambar 13,8, semua server GNS diberitahu tentang lokasi baru dari akar nyata. Mereka kemudian bisa menafsirkan nama-nama bentuk WORLD / EC / UK / AC / QMUL (disebut akar nyata) di cara yang biasa, dan mereka dapat menafsirkan nama-nama bentuk # 599 / UK / AC / QMUL dengan menggunakan tabel 'direktori terkenal' untuk menerjemahkan mereka untuk nama path penuh dimulai pada akar nyata.

GNS juga mendukung restrukturisasi database untuk menampung perubahan organisasi. Misalkan Amerika Serikat menjadi bagian dari Eropa Masyarakat (!). Gambar 13.9 menunjukkan pohon direktori baru. Tetapi jika subtree US hanya pindah ke direktori EC, nama yang diawali WORLD / NORTH AMERICA / US akan ada lagi bekerja. Solusi yang diadopsi oleh GNS adalah untuk menyisipkan 'link simbolik' di tempat entri US asli (ditampilkan dalam huruf tebal pada Gambar 13.9). GNS lookup direktori Prosedur menafsirkan link sebagai pengalihan ke direktori AS di lokasi baru.

Diskusi GNS • The GNS adalah keturunan dari Grapevine [Birrell et al. 1982] dan Clearinghouse [oppen dan Dalal 1983], dua sistem penamaan yang berhasil dikembangkan terutama untuk tujuan pengiriman email oleh Xerox Corporation. GNS berhasil membahas kebutuhan untuk skalabilitas dan reconfigurability, tetapi solusi diadopsi untuk penggabungan dan bergerak hasil pohon direktori di persyaratan untuk database (Tabel direktori terkenal) yang harus direplikasi di setiap simpul. Dalam besar- a jaringan skala, pengaturan ulang konfigurasi dapat terjadi di tingkat manapun, dan tabel ini bisa tumbuh ke ukuran besar, bertentangan dengan tujuan skalabilitas.



13.5 Studi Kasus: Direktori X.500 Layanan

X.500 adalah layanan direktori dalam arti ditentukan dalam Bagian 13.3. Hal ini dapat digunakan dalam cara yang sama seperti layanan nama konvensional, tetapi terutama digunakan untuk memenuhi deskriptif query dan dirancang untuk menemukan nama dan atribut dari pengguna lain atau sistem sumber. Pengguna dapat memiliki berbagai persyaratan untuk pencarian dan browsing di direktori pengguna jaringan, organisasi dan sumber daya sistem untuk mendapatkan informasi tentang entitas yang direktori berisi. Penggunaan untuk layanan tersebut cenderung cukup beragam. Mulai dari pertanyaan yang langsung analog dengan penggunaan direktori telepon, seperti akses sederhana 'halaman putih' untuk mendapatkan pengguna elektronik mail atau query 'halaman kuning' yang ditujukan, misalnya, untuk memperoleh nama dan nomor telepon dari garasi yang mengkhususkan diri dalam perbaikan make tertentu mobil, untuk penggunaan direktori untuk mengakses informasi pribadi seperti peran pekerjaan, kebiasaan makan atau bahkan gambar foto dari individu-individu.

pertanyaan tersebut mungkin berasal dari pengguna, dalam 'pages'example kuning disebutkan di atas, atau dari proses, ketika mereka dapat digunakan untuk mengidentifikasi layanan untuk memenuhi persyaratan fungsional.

Individu dan organisasi dapat menggunakan layanan direktori untuk menyediakan lebar berbagai informasi tentang diri mereka sendiri dan sumber daya yang mereka ingin menawarkan untuk digunakan dalam jaringan. Pengguna dapat mencari direktori untuk informasi spesifik dengan hanya parsial pengetahuan tentang namanya, struktur atau konten.

ITU dan ISO organisasi standar yang ditetapkan dalam X.500 Directory Service [ITU / ISO 1997] sebagai layanan jaringan dimaksudkan untuk memenuhi persyaratan ini. Standar menyebutnya sebagai layanan untuk akses ke informasi tentang 'entitas dunia nyata', tetapi juga kemungkinan besar akan digunakan untuk akses ke informasi tentang hardware dan software layanan dan perangkat. X.500 ditetapkan sebagai layanan aplikasi-tingkat di Sistem Terbuka Interkoneksi (OSI) menetapkan standar, tapi desainnya tidak tergantung apapun yang signifikan sejauh pada standar OSI lainnya, dan itu dapat dilihat sebagai sebuah desain untuk keperluan umum layanan direktori. Kami garis desain layanan direktori X.500 dan yang implementasi di sini. Pembaca yang tertarik pada penjelasan lebih rinci dari X.500 dan metode untuk pelaksanaannya disarankan untuk mempelajari buku Rose pada subjek [Rose 1992]. X.500 juga merupakan dasar untuk LDAP (dibahas di bawah), dan digunakan dalam DCE layanan direktori [OSF 1997] .

























Data yang disimpan di server X.500 diatur dalam struktur pohon dengan nama node, seperti dalam kasus server nama lain yang dibahas dalam bab ini, tetapi dalam X.500 lebar berbagai atribut disimpan di setiap node di pohon, dan akses mungkin tidak hanya dengan nama tetapi juga dengan mencari entri dengan kombinasi diperlukan atribut.

Pohon Nama X.500 disebut Direktori Informasi Pohon (DIT), dan seluruh struktur direktori termasuk data yang terkait dengan node, disebut Direktori Information Base (DIB). Ada dimaksudkan untuk menjadi terintegrasi DIB tunggal mengandung informasi yang diberikan oleh organisasi di seluruh dunia, dengan porsi dari DIB terletak di server X.500 individu. Biasanya, menengah atau besar organisasi akan memberikan setidaknya satu server. Klien mengakses direktori dengan membangun koneksi ke server dan mengeluarkan permintaan akses. Klien dapat menghubungi server dengan penyelidikan. Jika data yang dibutuhkan tidak dalam segmen DIB diselenggarakan oleh dihubungi server, akan baik memanggil server lain untuk menyelesaikan query atau mengarahkan client ke server lain.

Dalam terminologi standar X.500, server direktori Layanan Agen (DSA), dan klien mereka disebut Agen Direktori User (Duas). Gambar 13.10 menunjukkan arsitektur perangkat lunak dan salah satu dari beberapa model navigasi mungkin, dengan setiap proses klien DUA berinteraksi dengan proses DSA tunggal, yang mengakses lainnya DSA yang diperlukan untuk memenuhi permintaan.

Setiap entri dalam DIB terdiri dari nama dan satu set atribut. Seperti nama lainnya server, nama lengkap entri sesuai dengan jalan melalui DIT dari akar pohon untuk entri. Selain nama lengkap atau absolut, sebuah DUA dapat membangun konteks, yang mencakup dasar node, dan kemudian menggunakan nama relatif pendek yang memberikan jalan dari dasar node bernama entri.

Gambar 13.11 menunjukkan porsi Direktori Informasi Pohon yang mencakup nosional Universitas Gormenghast di Britania Raya, dan Gambar 13.12 adalah salah satu terkait entri DIB. Struktur data untuk entri dalam DIB dan DIT yang sangat fleksibel. Entri DIB terdiri dari satu set atribut, di mana atribut memiliki tipe dan satu atau lebih nilai. Jenis setiap atribut dilambangkan dengan nama jenis (misalnya, COUNTRYNAME, ORGANIZATIONNAME, COMMONNAME, telephoneNumber, kotak, objectClass). jenis atribut baru dapat didefinisikan jika mereka diperlukan. Untuk masing-masing berbeda,

nama jenis ada jenis definisi yang sesuai, yang mencakup deskripsi jenis dan definisi sintaks dalam notasi ASN.1 (notasi standar untuk definisi sintaks) mendefinisikan representasi untuk semua nilai yang diperbolehkan dari jenis.

Entri DIB diklasifikasikan dengan cara yang mirip dengan struktur kelas objek yang ditemukan dalam bahasa pemrograman berorientasi objek. Setiap entri berisi atribut objectClass, yang menentukan kelas (atau kelas) dari objek yang entri mengacu. Organisasi, organizationalPerson dan dokumen merupakan contoh object Class nilai-nilai. Kelas lanjut dapat didefinisikan sebagai mereka diwajibkan. Definisi kelas menentukan atribut yang wajib dan yang opsional untuk entri dari diberikan kelas. Definisi kelas diatur dalam hirarki warisan di mana semua kelas kecuali satu (disebut Topclass) harus berisi atribut object Class, dan nilai atribut objectClass harus nama satu atau lebih kelas. Jika ada beberapa nilai objectClass, objek mewarisi atribut wajib dan opsional masing-masing kelas.

Nama entri DIB (nama yang menentukan posisinya di DIT) adalah ditentukan dengan memilih satu atau lebih atribut sebagai atribut dibedakan. Itu atribut yang dipilih untuk tujuan ini disebut sebagai Nama Distinguished entri ini (DN).



Sekarang kita bisa mempertimbangkan metode yang direktori diakses. Ada dua jenis utama dari permintaan akses:

Baca: Sebuah nama absolut atau relatif (nama domain dalam terminologi X.500) untuk entri diberikan, bersama-sama dengan daftar atribut untuk dibaca (atau indikasi bahwa semua atribut yang diperlukan). The DSA menempatkan bernama entri dengan menavigasi di DIT tersebut, melewati permintaan ke server DSA lain di mana itu tidak tahan bagian yang relevan dari pohon. Ini mengambil atribut yang diperlukan dan mengembalikan mereka ke klien.

Pencarian: Ini adalah permintaan akses berbasis atribut. Sebuah nama dasar dan ekspresi filter disediakan sebagai argumen. Nama dasar menentukan node di DIT dari mana pencarian adalah untuk memulai; ekspresi filter ekspresi boolean yang menjadi dievaluasi untuk setiap node di bawah dasar simpul. filter menentukan kriteria pencarian: kombinasi logis dari tes pada nilai-nilai dari setiap atribut dalam entri. Itu perintah pencarian mengembalikan daftar nama (nama domain) untuk semua entri di bawah ini dasar simpul yang filter bernilai TRUE.

Misalnya, filter mungkin akan dibangun dan diterapkan untuk menemukan commonNames dari anggota staf yang menempati kamar Z42 di Departemen Ilmu Komputer di University of Gormenghast (Gambar 13.12). Sebuah permintaan membaca kemudian dapat digunakan untuk mendapatkan salah satu atau semua atribut entri DIB.

Mencari dapat cukup mahal bila diterapkan untuk sebagian besar dari pohon direktori (yang mungkin berada di beberapa server). argumen tambahan dapat disediakan untuk mencari untuk membatasi ruang lingkup, waktu yang pencarian diperbolehkan untuk melanjutkan dan ukuran daftar entri yang dikembalikan.

Administrasi dan memperbarui antarmuka DIB • The DSA termasuk operasi untuk menambahkan, menghapus dan memodifikasi entri. kontrol akses disediakan untuk kedua pertanyaan dan memperbarui operasi, sehingga akses ke bagian dari DIT dapat dibatasi untuk pengguna tertentu atau kelas pengguna.

DIB dipartisi, dengan harapan bahwa setiap organisasi akan memberikan di paling tidak satu server memegang rincian entitas dalam organisasi itu. Bagian dari DIB dapat direplikasi di beberapa server.

Sebagai standar (atau 'rekomendasi' dalam terminologi CCITT), X.500 tidak mengatasi masalah implementasi. Namun, sangat jelas bahwa pelaksanaan setiap melibatkan beberapa server di jaringan area luas harus bergantung pada penggunaan luas replikasi dan caching teknik untuk menghindari terlalu banyak pengalihan dari pertanyaan.

Salah satu implementasi, dijelaskan oleh Rose [1992], adalah sistem yang dikembangkan di University College, London, yang dikenal sebagai Quipu [Kille 1991]. Dalam implementasi ini, baik caching dan replikasi dilakukan pada tingkat entri DIB individu, dan pada tingkat koleksi entri turun dari node yang sama. Ini diasumsikan bahwa nilai-nilai dapat menjadi tidak konsisten setelah update, dan interval waktu di mana konsistensi dipulihkan mungkin beberapa menit. Bentuk pembaruan sosialisasi adalah umumnya dianggap diterima untuk aplikasi layanan direktori.

Asumsi Lightweight Directory Access Protocol • X.500 yang organisasi akan memberikan informasi tentang diri mereka sendiri di direktori publik dalam sistem umum memiliki terbukti sebagian besar tidak berdasar. Sama, compexity yang berarti bahwa serapan yang telah relatif sederhana.

Sebuah kelompok di University of Michigan mengusulkan pendekatan yang lebih ringan disebut Lightweight Directory Access Protocol (LDAP), di mana DUA mengakses layanan direktori X.500 langsung di atas TCP / IP bukan lapisan atas dari ISO stack protokol. Hal ini dijelaskan dalam RFC 2251 [Wahl et al. 1997]. LDAP juga menyederhanakan antarmuka untuk X.500 dengan cara lain: misalnya, menyediakan API relatif sederhana dan itu menggantikan ASN.1 encoding dengan tekstual encoding.

Meskipun spesifikasi LDAP didasarkan pada X.500, LDAP tidak memerlukan itu. Penerapan dapat menggunakan server direktori lain yang mematuhi LDAP sederhana spesifikasi, yang bertentangan dengan spesifikasi X.500. Sebagai contoh, Microsoft Active Directory Services menyediakan antarmuka LDAP.

Tidak seperti X.500, LDAP telah diadopsi secara luas, terutama untuk direktori intranet layanan. Ini memberikan akses aman ke direktori data melalui otentikasi.



13.6 Ringkasan

Bab ini menggambarkan desain dan implementasi layanan nama di sistem terdistribusi. layanan nama menyimpan atribut dari objek dalam sistem terdistribusi - Khususnya, alamat mereka - dan kembali atribut ini ketika nama tekstual adalah disediakan untuk mendongak.

Persyaratan utama untuk layanan nama adalah kemampuan untuk menangani sewenang-wenang sejumlah nama, seumur hidup panjang, ketersediaan tinggi, isolasi kesalahan dan toleransi ketidakpercayaan.

Masalah desain utama adalah struktur ruang nama - aturan sintaksis mengatur nama. Isu yang berhubungan adalah model resolusi, yang menetapkan aturan dengan yang nama multi-komponen memutuskan untuk satu set atribut. Set nama terikat harus dikelola. Kebanyakan desain mempertimbangkan ruang nama yang akan dibagi ke dalam domain - BAGIAN 13,6 RINGKASAN 593 bagian diskrit dari ruang nama, yang masing-masing terkait dengan otoritas tunggal mengendalikan pengikatan nama di dalamnya.

Pelaksanaan layanan nama dapat span organisasi yang berbeda dan komunitas pengguna. Koleksi binding antara nama dan atribut, di lain kata, disimpan di beberapa server nama, yang masing-masing menyimpan setidaknya bagian dari himpunan nama dalam domain penamaan. Pertanyaan navigasi karena itu timbul - dengan apa Prosedur dapat nama diselesaikan ketika informasi yang diperlukan disimpan di beberapa situs? Jenis navigasi yang didukung adalah berulang, multicast, rekursif server dikendalikan dan non-rekursif server dikendalikan.

Aspek penting lain dari pelaksanaan layanan nama adalah penggunaan replikasi dan caching. Kedua hal ini membantu dalam membuat layanan sangat tersedia, dan keduanya juga mengurangi waktu yang dibutuhkan untuk menyelesaikan sebuah nama.

Bab ini telah mempertimbangkan dua kasus utama desain layanan nama dan pelaksanaan. Domain Name System secara luas digunakan untuk penamaan komputer dan menangani surat elektronik di Internet; itu mencapai waktu respon yang baik melalui replikasi dan caching. Layanan Global Nama adalah desain yang telah ditangani masalah ini konfigurasi ulang ruang nama sebagai perubahan organisasi terjadi.

Bab juga dianggap layanan direktori, yang menyediakan data tentang pencocokan objek dan layanan ketika klien menyediakan deskripsi berbasis atribut. X.500 adalah model untuk layanan direktori yang dapat berkisar dalam lingkup dari organisasi individu ke direktori global. Telah diambil lebih luas untuk digunakan dalam intranet sejak kedatangan perangkat lunak LDAP.