PERTEMUAN V (SISTEM TERDISTRIBUSI)

SISTEM TERDISTRIBUSI

Chapter 4. Naming

4.1 Naming Entities

   Sebuah nama dalam sistem terdistribusi adalah sebuah deretean karakter yang digunakan untuk mewakili sebuah entitas. Entitas sendiri dapat berupa secara praktis dapat berarti apapun baik yang bersifat fisik seperti: komputer, printer, media penyimpanan, ataupun modem, maupun yang bersifat abstrak (lojik) seperti: berkas (file), user, proses, mailbox, dsb. Pengertian lain nya Name Service dalam Sistem Terdistribusi merupakan layanan penamaan yang berfungsi untuk menyimpan naming context, yakni kumpulan binding nama dengan objek, tugasnya untuk me-resolve nama. Pada sistem terdistribusi implementasi sistem penamaan tidak berpusat pada sebuah komputer namun lebih sering terdistribusi pada beberapa mesin dan cara pendistribusiannya mempengaruhi efisiensi dan skalabilitas dari sistem penamaan tersebut.

Untuk memanfaatkan entitas-entitas dalam sistem terdistribusi pengguna (manusia ataupun mesin) perlu mengakses entitas-entitas tersebut melalui sesuatu yang disebut access point, address, atau alamat. Sebuah entitas dapat memiliki beberapa alamat seperti halnya seseorang dapat memiliki beberapa nomor telepon genggam. Contoh lainnya adalah ketika seseorang berpindah tempat seperti kota atau negara maka nomor teleponnya sering harus diubah sesuai dengan sistem di kota (kode area) atau negara (kode negara) tersebut.

Jenis nama lain yang mendapat perlakuan khusus selain alamat adalah identifier dengan sifat-sifat sebagai berikut:

1. mewakili paling banyak satu entitas,

2. setiap entitas diwakili oleh paling banyak satu identifier,

3. sebuah identifier selalu mewakili entitas yang sama (tidak berubah meurut waktu dan kondisi).

Satu lagi jenis nama penting adalah nama dengan sifat user-friendly yang mudah dibaca dan diingat oleh manusia. Nama ini biasanya terdiri dari sederetan karakter yang dikenali manusia seperti nama pada file atau nama yang digunakan pada Domain Name System seperti www.google.co.id, dsb.

Yang menjadi pusat pembahasan pada bab ini adalah bagaimana nama yang user-friendly atau identifier yang unik dapat diterjemahkan menjadi alamat dari sebuah entitas. Solusi sederhananya adalah sebuah tabel berisi pasangan nama atau identifier dengan sebuah alamat. Solusi ini tidak fleksibel dan sulit diterapkan pada sebuah sistem terdistribusi

Nama-nama biasanya diatur menjadi sesuatu yang dikenal sebagai ruang nama (name space). Name space untuk nama yang terstruktur dapat direpresentasikan dalam bentuk graph (sebuah diagram yang terdiri dari simpul

(node) dan sisi (edge)yang menghubungkan dua simpul) yang memiliki label (nama) dan arah.

<gambar penjelasan graph biasa dan graph dengan label dan arah>

Ada dengan dua macam simpul pada graph yang merepresentasikan name space, yaitu:

1. Simpul daun yang merepresentasikan entitas yang memiliki nama dan tidak menjadi induk dari simpul lainnya

2. Simpul direktori yang memiliki ujung-ujung yang bernama dan menunjuk pada dari simpul daun lain

Simpul direktori menyimpan sebuah tabel yang disebut directory table yang berisi pasangan nama sisi (edge) yang mengarah ke luar menuju pada sebuah simpul anak dan identifier dari simpul anak tersebut. Simpul yang menjadi induk dan tidak memiliki induk disebut sebagai simpul root (akar). Sebuah graph penamaan dapat memiliki beberapa root namun demi kesederhanaan biasanya sebuah graph penamaan hanya memiliki satu root.

Setiap jalur (path) menuju suatu entitas dapat ditulis sebagai urutan label-label dari setiap sisi yang mengarah pada entitas tersebut seperti N:<label-1, label-2, …, label-n> di mana N adalah simpul di awal jalur. Jika sebuah jalur diawali dengan simpul root maka jalur tersebut disebut absolute path dan jika tidak diawali simpul root maka dinamakan relative path.

Contoh mudahnya adalah jalur ke sebuah file pada banyak sistem berkas (filesystem) ditulis sebagai urutan label dari sisi-sisi (melambangkan direktori - jangan tertukar dengan istilah simpul direktori) yang mengarah pada file tersebut seperti c:\windows\system32\cmd.exe atau /home/faculty/test.sh. Ada beberapa cara berbeda untuk mengatur sebuah name space namun kebanyakan hanya memiliki satu simpul root dan pada banyak kasus bersifat hierarkis dalam artian name space tersebut memiliki struktur seperti pohon (tree). Pada pengorganisasian seperti itu semua simpul memiliki tepat satu sisi yang mengarah ke simpul tersebut (kecuali simpul root) dan dapat memiliki beberapa sisi yang mengarah ke luar dari simpul tersebut ke simpul di bawahnya sehingga setiap simpul memiliki tepat satu absolute path.

Grafik penamaan ditunjukkan pada Gambar. 4-1 adalah contoh grafik asiklik diarahkan. Dalam sebuah organisasi, node dapat memiliki lebih dari satu sisi masuk, tapi grafik tidak diizinkan untuk memiliki siklus. Ada juga nama ruang yang tidak memiliki pembatasan ini. Untuk membuat keadaan menjadi lebih konkret, pertimbangkan cara file secara tradisional UNIX sistem file yang bernama. Dalam grafik penamaan untuk UNIX, node direktori merupakan direktori file, sedangkan simpul daun merepresentasikan file. Ada satu direktori root, diwakili dalam grafik penamaan oleh simpul akar. Implementasi dari grafik penamaan merupakan bagian integral dari pelaksanaan lengkap sistem file. Bahwa pelaksanaan terdiri dari serangkaian bersebelahan blok dari logis disk, umumnya dibagi menjadi blok boot, superblok, serangkaian indeks node (disebut inode), dan blok file data. Lihat juga (Crowley, 1997, Nutt, 2000; Tanenbaum dan Woodhull, 1997). Organisasi ini ditunjukkan pada Gambar. 4-2.

Boot block adalah blok khusus data dan instruksi yang otomatis dimuat ke memori utama ketika sistem di-boot. Boot block digunakan untuk memuat sistem operasi ke dalam memori utama. Superblock berisi informasi tentang seluruh sistem file, seperti ukuran, yang blok pada disk yang belum dialokasikan, yang inode belum digunakan, dan sebagainya pada. Inode disebut oleh nomor indeks, mulai dari angka nol, yaitu dicadangkan untuk inode mewakili direktori root.Inode masing-masing berisi informasi yang tepat di mana data file terkait dapat ditemukan pada disk. Selain itu, inode berisi informasi tentang pemiliknya, waktu penciptaan dan modifikasi terakhir, perlindungan, dan sejenisnya. Akibatnya, ketika diberi nomor indeks inode, adalah mungkin untuk mengakses terkait file. Setiap direktori diimplementasikan sebagai file juga. Ini juga kasus untuk direktori root, yang berisi pemetaan antara nama file dan nomor indeks inode. Hal demikian terlihat bahwa jumlah indeks inode sesuai dengan node identifier dalam grafik penamaan.

4.1.2 Name Resolution

   Name resolution merupakan istilah untuk proses pencarian (looking up) sebuah nama ketika kita mendapatkan path dari nama tersebut. Proses name resolution ini akan menghasilkan identifier dari sebuah simpul yang dilalui pada proses tersebut.

Ruang nama menawarkan mekanisme yang nyaman untuk menyimpan dan mengambil informasi tentang entitas dengan cara nama. Lebih umum, diberi nama jalan, maka harus mungkin untuk mencari informasi yang tersimpan di simpul yang dirujuk oleh nama itu. Proses mencari nama disebut resolusi nama Untuk menjelaskan bagaimana resolusi nama bekerja, mempertimbangkan nama jalan seperti N: <label-1, label-2, ..., label-n>. Resolusi nama ini dimulai pada node N dari penamaan grafik, di mana nama label-1 adalah mendongak dalam tabel direktori, dan yang mengembalikan identifier dari node yang label-1 mengacu. resolusi kemudian terus di simpul diidentifikasi dengan melihat nama label-2 dalam direktori yang meja, dan sebagainya. Dengan asumsi bahwa jalan bernama benar-benar ada, resolusi berhenti di simpul terakhir disebut oleh label-n, dengan mengembalikan isi dari simpul tersebut.

   Sebuah pencarian nama mengembalikan identifier node dari mana resolusi nama Proses berlanjut. Secara khusus, perlu untuk mengakses tabel direktori node diidentifikasi. Pertimbangkan lagi grafik penamaan untuk sistem file UNIX. Sebagai disebutkan, pengenal simpul diimplementasikan sebagai nomor indeks dari inode. Mengakses tabel direktori berarti bahwa pertama inode harus dibaca untuk mengetahui dimana data tersebut disimpan pada disk, dan kemudian selanjutnya untuk membaca data blok berisi tabel direktori.

Mekanisme Penutupan (Closure)

Proses name resolution hanya dapat terjadi apabila pencari mengetahui bagaimana dan di mana untuk memulai proses. Hal ini dikenal sebagai closure mechanism yang secara esensi berurusan dengan menentukan simpul awal dalam name space di mana proses pencarian bisa dimulai. Closure mechanism terkadang tidak tampak (implicit) dan sudah menjadi bagian dari sebuah sistem dan dapat berbeda-beda pada setiap sistem. Sebagai contoh proses name resolution pada graph penamaan di filesystem UNIX menggunakan aturan bahwa inode (simpul) dari direktori root adalah inode (simpul) pertama. Jika sebuah file bernama /home/steen/mbox ingin ditemukan maka sistem operasi harus sudah dapat mengakses inode root untuk memulai pencarian.

Contoh lainnya dari closure mechanism ialah jika diberikan sebuah deretan angka “00301231751” banyak yang tidak mengetahui apa yang harus dilakukan kecuali ada informasi tambahan bahwa deretan angka tersebut adalah nomor telepon. Informasi tersebut cukup untuk memulai sebuah proses name resolution dengan cara memanggil nomor tersebut melalui pesawat telepon dan sistem telekomunikasi telepon akan melakukan proses lookup.

Linking dan Mounting

Terkadang suatu entitas memiliki beberapa nama atau dikenal sebagai alias. Pada sebuah graph penamaan terdapat dua cara untuk mengimplementasikan konsep alias, yaitu:

1. dengan mengizinkan adanya lebih dari satu absolute path menuju suatu simpul (pada dunia filesystem UNIX ini dikenal sebagai hard link)

2. atau dengan merepresentasikan sebuah entitas dengan sebuah simpul daun yang berisi informasi berupa absolute path dari entitas tersebut. Cara ini ke-dua dikenal dengan istilah symbolic link.

Proses name resolution yang dicontohkan sejauh ini berada dalam sebuah name space. Name resolution dapat juga melibatkan dua atau lebih name space. Contohnya adalah mounted filesystem pada UNIX. Proses mounting terjadi ketika sebuah simpul direktori menyimpan identifier dari simpul direktori yang berada di naming space yang berbeda atau dikenal sebagai simpul direktori asing. Simpul direktori yang menyimpan identifier simpul direktori asing disebut sebagai mount point sedangkan simpul direktori asing dikenal sebagai mounting point.

Pada sebuah sistem tersebar proses mounting dapat dilakukan lintas komputer jika didukung oleh tiga informasi berikut ini, yaitu:

1. nama dari protocol aksesnya,

2. nama dari komputer lain,

3. nama mounting point yang berada pada name space yang dimiliki komputer tersebut.

Perhatikan bahwa masing-masing nama harus diselesaikan. Nama dari protokol akses harus diselesaikan dengan pelaksanaan protokol dimana komunikasi dengan server dari ruang nama asing dapat terjadi. Nama dari

Server harus diselesaikan ke alamat mana server yang dapat dihubungi. Sebagai bagian terakhir dalam resolusi nama, nama titik pemasangan perlu diselesaikan

ke pengenal simpul dalam ruang nama asing. Dalam sistem nondistributed, tidak satupun dari tiga poin sebenarnya mungkin diperlukan. Misalnya, dalam UNIX, tidak ada protokol akses dan tidak ada server. Juga, nama dari titik pemasangan tidak perlu, karena hanya direktori root dari asing ruang nama. Nama titik pemasangan yang akan diselesaikan oleh server dari luar negeri ruang nama. Namun, kita juga perlu ruang nama dan implementasi untuk

akses protokol dan nama server. Salah satu kemungkinan adalah untuk mewakili tiga, nama yang tercantum di atas sebagai URL.

Untuk membuat hal-hal konkret, pertimbangkan situasi di mana pengguna dengan laptop komputer ingin mengakses file yang disimpan pada file server remote. Klien mesin dan file server keduanya dikonfigurasi dengan File System Sun Jaringan (NFS), yang akan kita bahas secara rinci dalam Bab. 10. NFS merupakan sebuah sistem berkas terdistribusi yang datang dengan sebuah protokol yang menggambarkan secara tepat bagaimana klien dapat mengakses file yang disimpan pada file server (remote) NFS. Secara khusus, untuk memungkinkan NFS untuk bekerja di Internet, klien dapat menentukan mana yang file itu ingin mengakses dengan sarana URL NFS, misalnya, nfs :/ / flits.cs.vu.nl / / home / steen. URL ini nama file (yang terjadi menjadi sebuah direktori) disebut / home / steen pada file NFS Server flits.cs.vu.nl, yang dapat diakses oleh klien melalui protokol NFS (Callaghan, 2000).

Nama nfs adalah nama terkenal dalam arti bahwa seluruh dunia perjanjian ada di bagaimana menafsirkan nama itu. Dengan kata lain, mengingat bahwa kita berhadapan dengan URL, nama nfs akan memutuskan untuk sebuah implementasi dari protokol NFS. Nama server diselesaikan ke alamat dengan menggunakan Domain Name System,

yang dibahas pada bagian selanjutnya. Seperti yang kami katakan, / home / steen diselesaikan oleh Server dari ruang nama asing.

Contoh implementasinya adalah NFS (Network File System) yang dikembangkan oleh Sun Microsystem.

Organisasi dari sistem file pada komputer klien sebagian ditampilkan dalam Gambar. 4-4. Direktori root memiliki sejumlah user-defined entri, termasuk subdirektori disebut / remote. Ini subdirektori dimaksudkan untuk memasukkan mount point. untuk ruang nama asing seperti direktori home user di Vrije Universiteit.

Untuk tujuan ini, sebuah node direktori bernama / remote / vu digunakan untuk menyimpan URL

nfs :/ / flits.cs.vu.nl / / home / steen.

Sekarang perhatikan nama / remote / vu / mbox. Nama ini diselesaikan dengan memulai dalam direktori root pada mesin klien dan berlanjut sampai node / remote / vu tercapai. Resolusi nama kemudian berlanjut dengan kembali URL nfs :/ / flits.cs.vu.nl / / home / steen, pada gilirannya menyebabkan mesin klien untuk menghubungi file server flits.cs.vu.nl melalui protokol NFS, dan kemudian mengakses

direktori / home / steen. Resolusi nama kemudian dapat dilanjutkan dengan membaca file bernama mbox dalam direktori tersebut. Terdistribusi sistem yang memungkinkan pemasangan sistem file jarak jauh seperti yang baru saja dijelaskan memungkinkan mesin klien untuk, misalnya, jalankan perintah berikut

cd /remote/vu

ls –l

yang kemudian daftar file di direktori / home / steen pada file remote server. Keindahan ini semua adalah bahwa pengguna terhindar rincian actual akses ke server remote. Idealnya, hanya beberapa penurunan performa yang melihat dibandingkan dengan mengakses file yang tersedia secara lokal. Akibatnya, untuk klien tampak bahwa ruang nama berakar pada mesin lokal, dan yang berakar pada / home / steen pada mesin remote, membentuk ruang nama tunggal.

4.1.3 Pelaksanaan Space Nama

Sebuah ruang nama membentuk jantung dari layanan penamaan, yaitu sebuah layanan yang memungkinkan pengguna dan proses untuk menambah, menghapus, dan mencari nama. Sebuah layanan penamaan diimplementasikan oleh server nama. Jika sistem terdistribusi terbatas pada local area jaringan, sering layak untuk menerapkan layanan penamaan dengan cara hanya server tunggal nama. Namun, dalam skala besar sistem terdistribusi dengan banyak entitas, mungkin tersebar di seluruh wilayah geografis yang luas, perlu untuk mendistribusikan pelaksanaan ruang nama atas nama beberapa server. Nama ruang untuk sistem skala besar, didistribusikan mungkin di seluruh dunia, biasanya diselenggarakan secara hierarkis. Seperti sebelumnya, asumsikan seperti ruang nama hanya memiliki tunggal akar simpul. Untuk secara efektif menerapkan seperti ruang nama, akan lebih mudah untuk partisi ke dalam lapisan logis. Cheriton dan Mann (1989) membedakan tiga lapisan yaitu sebagai berikut:

a.    Lapisan global yang dibentuk oleh tingkat tertinggi node, yaitu, simpul akar dan node direktori lain secara logis dekat dengan akar, yaitu anak-anaknya. Node dalam lapisan global sering ditandai oleh stabilitas mereka, dalam arti bahwa direktori tabel jarang berubah. Node tersebut dapat mewakili organisasi .. atau kelompok organisasi, yang namanya disimpan dalam ruang nama.

b.    Lapisan administrasi dibentuk oleh node direktori yang bersama-sama adalah dikelola dalam satu organisasi. Karakteristik dari direktori node pada lapisan administrasi adalah bahwa mereka mewakili kelompok entitas yang milik organisasi yang sama atau unit administrasi. Sebagai contoh, mungkin ada menjadi simpul direktori untuk setiap departemen dalam suatu organisasi, atau node direktori dari mana semua host dapat ditemukan. Node lain direktori dapat digunakan sebagai titik awal untuk penamaan semua pengguna, dan sebagainya. Node dalam administrasi Lapisan relatif stabil, meskipun perubahan umumnya terjadi lebih sering daripada ke node di lapisan global.

c.    Lapisan manajerial terdiri dari node yang biasanya bisa berubah teratur. Sebagai contoh, node yang mewakili host di jaringan lokal milik lapisan ini. Untuk alasan yang sama, lapisan termasuk node yang mewakili file bersama seperti untuk perpustakaan atau binari. Kelas lain yang penting dari node meliputi orang yang mewakili user-defined direktori dan file. Berbeda dengan global dan Lapisan administrasi, node pada lapisan manajerial diselenggarakan tidak hanya oleh administrator sistem, tetapi juga oleh pengguna akhir individu suatu sistem terdistribusi.

Untuk membuat keadaan menjadi lebih konkret, Gambar. 5-13 menunjukkan contoh partisi bagian dari ruang nama DNS, termasuk nama-nama file dalam suatu organisasi yang dapat diakses melalui Internet, misalnya, halaman Web file dipindahtangankan dan ruang nama dibagi menjadi bagian-bagian nonoverlapping, disebut zona dalam DNS. Zona adalah bagian dari ruang nama yang diimplementasikan oleh server nama yang terpisah. Beberapa zona diilustrasikan dalam Gambar. 4-6.

Jika kita melihat ketersediaan dan kinerja, server nama di setiap lapisan harus memenuhi kebutuhan yang berbeda. Ketersediaan tinggi ini sangat penting untuk Nama server di lapisan global. Jika name server gagal, sebagian besar nama ruang akan terjangkau karena resolusi nama tidak bisa melanjutkan di luar gagal server. Kinerja agak halus. Karena rendahnya tingkat perubahan node dalam lapisan global, hasil usaha pencarian umumnya tetap berlaku untuk waktu yang lama waktu. Akibatnya, hasil tersebut bisa efektif cache (yaitu, disimpan secara lokal) .

Gambar 4-6. Contoh partisi dari ruang nama DNS, termasuk Internet yang dapat diakses file, menjadi tiga lapisan.

Ketersediaan untuk server nama dalam lapisan administrasi terutama penting untuk klien di organisasi yang sama sebagai server nama. Jika nama server gagal, banyak sumber daya dalam organisasi menjadi tidak terjangkau karena mereka tidak dapat mendongak. Di sisi lain, mungkin kurang penting bahwa sumber daya di sebuah organisasi untuk sementara terjangkau bagi pengguna di luar organisasi.

Sehubungan dengan kinerja, nama server di lapisan administrasi memiliki karakteristik yang sama seperti yang di lapisan global. Karena perubahan node melakukan tidak terjadi semua yang sering, caching hasil pencarian dapat sangat efektif, sehingga kinerja kurang kritis. Namun, berbeda dengan lapisan global, yang administrational layer harus berhati-hati bahwa hasil pencarian dikembalikan dalam milidetik beberapa baik secara langsung dari server atau dari cache lokal klien. Demikian juga, update umumnya harus diproses lebih cepat daripada lapisan global. Untuk Misalnya, tidak dapat diterima bahwa account untuk user baru mengambil jam untuk menjadi efektif.

Persyaratan ini seringkali dapat dipenuhi dengan menggunakan performa tinggi mesin untuk menjalankan server nama. Selain itu, client-side caching harus diterapkan, dikombinasikan dengan replikasi untuk ketersediaan keseluruhan meningkat. Ketersediaan persyaratan untuk server nama di tingkat manajerial umumnya kurang menuntut. Secara khusus, sering cukup untuk menggunakan mesin (dedicated) tunggal untuk menjalankan server nama dengan risiko tidak tersedianya sementara. Namun, kinerja sangat penting. Pengguna berharap operasi berlangsung segera. Karena update terjadi secara teratur, client-side caching sering kurang efektif, kecuali khusus langkah-langkah yang diambil, yang kita bahas dalam Bab. 6

Item	Global	Administrational	Managerial
Geographical scale of network	Worldwide	Organization	Department
Total number of nodes	Few	Many	Vast numbers
Responsiveness to lookups	Seconds	Milliseconds	Immediate
Update propagation	Lazy	Immediate	Immediate
Number of replicas	Many	None or few	None
Is client-side caching applied?	Yes	Yes	Sometimes

Gambar 4-7. Perbandingan antara server nama untuk node pelaksanaan dari skala besar ruang nama dipartisi menjadi lapisan global, suatu administrasi lapisan, dan lapisan manajerial.

Perbandingan antara server nama pada lapisan yang berbeda ditunjukkan pada Gambar. 4-7. Dalam sistem terdistribusi, nama server di lapisan global dan administrasi yang paling sulit untuk diterapkan. Kesulitan disebabkan oleh replikasi dan caching, yang dibutuhkan untuk ketersediaan dan kinerja, tetapi juga memperkenalkan konsistensi masalah. Beberapa masalah yang diperparah oleh kenyataan bahwa cache dan replika yang tersebar di seluruh jaringan wide-area, yang memperkenalkan lama keterlambatan komunikasi sehingga membuat sinkronisasi lebih keras. Peniruan dan caching dibahas secara luas dalam Bab. 6

Pelaksanaan Resolusi Nama.

Pembagian ruang nama di server nama multiple mempengaruhi pelaksanaan resolusi nama. Untuk menjelaskan pelaksanaan resolusi nama dalam skala besar layanan nama, kita asumsikan untuk saat ini bahwa nama server tidak direplikasi dan bahwa tidak ada sisi klien cache yang digunakan. Setiap klien memiliki akses ke resolver lokal nama, yang bertanggung jawab untuk memastikan bahwa resolusi nama Proses dilakukan. Mengacu pada Gambar. 4-6, menganggap nama path (absolut)  root: «nl, VU, CS, ftp, pub, globe, index.html>   Yang harus diselesaikan. Menggunakan notasi URL, nama path ini akan sesuai dengan  ftp://ftp.cs. vu.nl/pub/globe/index.html. Sekarang ada dua cara untuk menerapkan resolusi nama.

Dalam iteratif resolusi nama, nama resolver tangan di atas nama lengkap ke root server nama. Diasumsikan bahwa alamat di mana root server dapat dihubungi adalah terkenal. Root server akan menyelesaikan nama jalan sejauh bisa, dan mengembalikan hasilnya ke klien. Dalam contoh kita, server root dapat mengatasi hanya label nl, yang akan mengembalikan alamat dari server nama yang terkait.

Pada saat itu. klien melewati nama jalan yang tersisa  (i.e., nl: <VU, cs, jtp, pub, globe, index.html>)ke server nama. Server ini dapat mengatasi hanya label VU, dan mengembalikan alamat dari server nama yang terkait, bersama dengan tersisa nama path vu:<cs, ftp, pub, globe, index.html>.

Resolver nama klien kemudian akan menghubungi server ini nama berikutnya, yang merespon dengan memecahkan label cs, dan kemudian alsoftp, kembali alamat dari server FTP bersama dengan nama jalan ftp:<pub, globe, index.html>.itu klien maka kontak server FTP, memintanya untuk menyelesaikan bagian terakhir dari aslinya nama path. Server FTP selanjutnya akan menyelesaikan labe  pub. globe, dan index.html dan mentransfer file yang diminta (dalam hal ini menggunakan FTP). proses ini iteratif resolusi nama ditunjukkan pada Gambar. 4-8 (Notasi # <cs> adalah digunakan untuk menunjukkan alamat server bertanggung jawab untuk menangani node disebut oleh <cs>.)

Dalam prakteknya, langkah terakhir, yaitu menghubungi server FTP dan memintanya untuk mentransfer file dengan nama path ftp i-cpub, globe, index.himl », dilakukan terpisah oleh proses klien. Dengan kata lain, klien biasanya akan menyerahkan hanya akar nama path: «nl, VU, CS, ftp> ke resolver nama, dari mana ia harapkan alamat di mana ia dapat menghubungi server FTP, seperti yang juga ditampilkan dalam Gambar.

Sebuah alternatif untuk berulang resolusi nama adalah dengan menggunakan rekursi selama nama resolusi. Alih-alih kembali setiap hasil tengah kembali ke nama klien resolver, dengan resolusi nama rekursif, nama server melewati hasilnya ke name server berikutnya yang ditemukan. Jadi, misalnya, ketika server nama akar menemukan alamat server nama menerapkan node bernama nl, itu permintaan bahwa nama server untuk mengatasi jalan nl Nama: <vu, CS, ftp, pub, globe, index.html>. menggunakan resolusi nama rekursif juga, ini server berikutnya akan menyelesaikan path lengkap dan akhirnya mengembalikan index.html file ke root server, yang, pada gilirannya, akan lulus file itu ke resolver nama klien.

Resolusi nama Rekursif ditunjukkan pada Gambar. 5-16. Seperti dalam iteratif resolusi nama, langkah terakhir resolusi (menghubungi server FTP dan meminta untuk mentransfer file ditunjukkan) umumnya dilakukan sebagai proses terpisah oleh klien.

Kelemahan utama dari resolusi nama rekursif adalah bahwa hal itu menempatkan kinerja yang lebih tinggi demand pada setiap server nama. Pada dasarnya, server nama diperlukan untuk menangani resolusi lengkap dari nama jalan, meskipun mungkin melakukannya dalam kerjasama dengan server nama lain. Ini beban tambahan umumnya begitu tinggi sehingga Nama server di lapisan global dukungan ruang nama hanya iteratif resolusi nama.

Ada dua keuntungan penting untuk resolusi nama rekursif. yang pertama Keuntungan adalah bahwa caching hasil lebih efektif dibandingkan dengan iteratif nama resolusi. Keuntungan kedua adalah bahwa biaya komunikasi dapat dikurangi. Untuk  menjelaskan keuntungan, menganggap bahwa resolver nama klien akan menerima path nama mengacu hanya untuk node pada lapisan global atau administrasi dari nama ruang. Untuk mengatasi itu ofa bagian nama path yang sesuai dengan node dalam manajerial lapisan, klien secara terpisah akan menghubungi server nama dikembalikan oleh namanya resolver.

Resolusi nama Rekursif memungkinkan setiap server nama untuk secara bertahap mempelajari alamat masing-masing nama server bertanggung jawab untuk menerapkan tingkat rendah node. Sebagai Hasilnya, caching dapat digunakan secara efektif untuk meningkatkan kinerja. Misalnya, ketika server akar diminta untuk menyelesaikan akar nama path: <nl, vu, cs, ftp>, akhirnya akan mendapatkan alamat dari server nama menerapkan node disebut dengan nama itu jalan. Untuk datang ke titik itu, server nama untuk nl simpul harus mencari alamat server nama untuk node vu, sedangkan kedua harus mencari alamat server nama menangani node cs.

Karena perubahan node di lapisan global dan administrasi tidak sering terjadi, server nama akar efektif bisa cache alamat kembali. Selain itu, karena alamat tersebut juga dikembalikan, dengan rekursi, ke server nama bertanggung jawab untuk melaksanakan node vu dan yang melaksanakan nl node, mungkin juga di-cache pada server-server tersebut juga. Demikian pula, hasil pencarian nama antara juga dapat dikembalikan dan
cache. Sebagai contoh, server untuk node nl akan harus mencari alamat server simpul vu. Alamat yang dapat dikembalikan ke server akar ketika nl Server mengembalikan hasil dari pencarian nama asli. Sebuah gambaran lengkap dari Resolusi proses, dan hasil yang dapat di-cache oleh masing-masing name server ditunjukkan pada Gambar.

Server for node	Should resolve	Looks up	Passes to child	Receives and caches	Returns to requester
cs	<ftp>	#<ftp>	--	--	#<ftp>
vu	<cs,ftp>	#<cs>	<ftp>	#<ftp>	#<cs> #<cs, ftp>
ni	<vu,cs,ftp>	#<vu>	<cs,ftp>	#<cs> #<cs,ftp>	#<vu> #<vu,cs> #<vu,cs,ftp>

Manfaat utama dari pendekatan ini adalah bahwa, pada akhirnya. operasi lookup dapat ditangani cukup efisien. Misalnya, bahwa klien lain kemudian permintaan resolusi akar nama path: <nl, Vii, cs, flits>. Nama ini akan diteruskan ke akar, yang segera bisa meneruskannya ke server nama untuk node cs, dan permintaan untuk menyelesaikan nama path cs tersisa: <jlits>.

Dengan berulang resolusi nama, caching tentu terbatas pada klien nama resolver. Akibatnya, jika klien A permintaan resolusi nama, dan lain B client kemudian meminta agar nama yang sama untuk diselesaikan, resolusi nama akan harus melewati server nama yang sama seperti yang dilakukan untuk klien A. Sebagai kompromi, banyak organisasi menggunakan server, nama lokal antara yang dibagi oleh semua klien. Ini nama server lokal menangani semua permintaan penamaan dan hasil cache. Seperti server menengah juga nyaman dari segi manajemen melihat. Misalnya, hanya server yang perlu tahu di mana server nama root adalah terletak, mesin lain tidak memerlukan informasi ini.

Keuntungan kedua dari resolusi nama rekursif adalah bahwa hal itu sering lebih murah sehubungan dengan komunikasi. Sekali lagi, mempertimbangkan resolusi nama jalan root: <nl, vu, cs, ftp> dan menganggap klien terletak di San Francisco. Dengan asumsi bahwa klien mengetahui alamat server untuk node nl, dengan nama rekursif Resolusi, komunikasi mengikuti rute dari host klien di San Francisco ke server nl di Belanda, ditampilkan sebagai R 1 pada Gambar. 5-18. dari sana pada, komunikasi selanjutnya diperlukan antara server nl dan nama server dari Vrije Universiteit di kampus universitas di Amsterdam, Belanda. Komunikasi ini ditampilkan sebagai R 2. Akhirnya, komunikasi diperlukan antara server vu dan name server di Ilmu Komputer Departemen, ditampilkan sebagai R 3. Rute untuk jawabannya adalah sama, tetapi dalam berlawanan arah. Jelas, biaya komunikasi yang ditentukan oleh pertukaran pesan antar klien host dan server . Sebaliknya, dengan berulang resolusi nama, host klien harus berkomunikasi secara terpisah dengan server nl, server vu, dan server cs, di mana total biaya mungkin sekitar tiga kali lipat dari resolusi nama rekursif. Itu panah pada Gambar.  berlabel / 1, / 2, dan / 3 menunjukkan jalur komunikasi untuk iteratif resolusi nama.

4.1.4 Contoh: Sistem Nama Domain

Salah satu jasa terbesar penamaan terdistribusi yang digunakan saat ini adalah Internet Domain Name System (DNS). DNS terutama digunakan untuk mencari alamat IP dari host dan server mail. Pada halaman berikut, kami berkonsentrasi pada organisasi dari ruang nama DNS, dan informasi yang disimpan dalam node nya. Juga, kita mengambil melihat lebih dekat pada pelaksanaan sebenarnya DNS. Informasi lebih lanjut dapat ditemukan di Mockapetris dan Albitz dan Liu. Sebuah penilaian baru-baru ini DNS, terutama mengenai apakah masih sesuai dengan kebutuhan internet saat ini, dapat ditemukan di Levien. Dari laporan ini, seseorang dapat menarik agak mengejutkan kesimpulan bahwa bahkan setelah lebih dari 30 tahun, DNS memberikan indikasi bahwa perlu diganti. Kami akan berpendapat bahwa penyebab utama terletak pada desainer mendalam pemahaman tentang bagaimana untuk menjaga hal-hal sederhana. Praktek di bidang lain didistribusikan sistem menunjukkan bahwa tidak banyak yang berbakat dengan pemahaman seperti.

Space Nama DNS

Ruang nama DNS adalah hirarki terorganisir sebagai pohon berakar. Label adalah case-insensitive string yang terdiri dari karakter alfanumerik. Label sudah maksimal panjang 63 karakter, panjang nama path lengkap dibatasi 255 karakter. Representasi string dari nama jalan terdiri dari daftar label nya, dimulai dengan satu paling kanan, dan memisahkan label oleh sebuah titik (H. "). The root diwakili oleh sebuah titik. Jadi, misalnya, akar nama path: <nl, VU, cs, berpindah>, diwakili oleh flits.cs string. vu.nl., yang mencakup titik paling kanan untuk menunjukkan simpul akar. Kita umumnya menghilangkan titik ini untuk dibaca. Karena setiap node dalam ruang nama DNS memiliki tepat satu ujung masuk (dengan pengecualian dari simpul akar, yang tidak memiliki tepi yang masuk), label terpasang tepi masuk toa node juga digunakan sebagai nama untuk simpul tersebut. Sebuah subtree disebut domain, nama path ke node akar disebut nama domain. Catatan itu, seperti nama jalan, nama domain dapat berupa absolut atau relatif.

Isi simpul terbentuk oleh kumpulan catatan sumber daya. Sebuah simpul dalam ruang nama DNS akan sering mewakili beberapa entitas di waktu yang sama. Sebagai contoh, nama domain seperti vu.nl digunakan untuk mewakili domain dan zona. Dalam hal ini, domain diimplementasikan melalui beberapa (nonoverlapping) zona. Sebuah SOA (start otoritas) catatan sumber daya berisi informasi seperti e-mail dari administrator sistem bertanggung jawab untuk zona diwakili. nama host mana data pada zona dapat diambil, dan sebagainya.

Jenis catatan	Associated entity	Description
SOA	Zone	Memegang informasi mengenai zona
A	Host	Berisi alamat IP dari host
MX	Domain	Mengacu pada sebuah mail server untuk menangani surat yang ditujukan ke node ini
SRV	Domain	Mengacu ke server menangani layanan tertentu

A (alamat) record, merupakan host tertentu di Internet. A record berisi alamat IP untuk itu host untuk memungkinkan komunikasi. Jika host memiliki beberapa alamat IP, seperti halnya dengan multi-homed mesin, node akan berisi Sebuah catatan untuk alamat masing-masing. Tipe lain dari record adalah MX (mail exchange) catatan, yang seperti simbolik link ke sebuah node yang mewakili sebuah mail server. Sebagai contoh, node mewakili yang cs.vu.nl domain memiliki sebuah MX record yang berisi zephyr.cs.vu.nl nama, yang mengacu pada sebuah mail server. Server yang akan menangani semua surat masuk yang ditujukan kepada pengguna di cs. vu.nl domain. Mungkin ada catatan MX beberapa disimpan dalam node.

Terkait dengan catatan MX adalah catatan SRV, yang berisi nama server
untuk layanan tertentu. Catatan SRV didefinisikan dalam Gulbrandsen. Layanan sendiri diidentifikasi dengan menggunakan nama bersama dengan nama protokol. Untuk Sebagai contoh, server web di cs. vu.nl domain bisa diberi nama dengan cara yang Data SRV seperti. Jutp.ctcp.cs.vu.nl, rekaman ini kemudian akan mengacu pada aktual nama server (yang soling.cs. vu.nl). Keuntungan penting dari SRV catatan adalah bahwa klien tidak perlu lagi tahu nama DNS dari tuan rumah menyediakan layanan tertentu. Sebaliknya, hanya nama layanan perlu dibakukan, setelah itu tuan rumah menyediakan dapat mendongak. Node yang mewakili zona, mengandung satu atau lebih NS (name server) catatan. Seperti MX record, catatan NS berisi nama nama server yang mengimplementasikan zona diwakili oleh node.

Pada prinsipnya, setiap node dalam ruang nama dapat menyimpan catatan NS mengacu ke server nama yang mengimplementasikannya. Namun, seperti yang kita bahas di bawah ini, pelaksanaan ruang nama DNS adalah sedemikian rupa sehingga hanya node yang mewakili zona perlu menyimpan catatan NS. DNS alias membedakan dari apa yang disebut nama kanonik. setiap host diasumsikan memiliki nama kanonik, atau primer. Alias diimplementasikan olehsarana simpul menyimpan data CNAME berisi nama kanonik dari sebuah host. Nama node menyimpan catatan seperti demikian sama dengan link simbolik, sebagaimana ditunjukkan pada Gambar. DNS mempertahankan pemetaan invers alamat IP ke nama host dengan cara PTR (pointer) catatan. Untuk mengakomodasi pencarian dari nama host ketika diberi hanya alamat IP, DNS mempertahankan domain bernama in-addr.arpa, yang berisi node yang mewakili host Internet dan yang ditunjuk oleh alamat IP mewakili tuan rumah. Misalnya, tuan tVww.cs. \ 'u.nl memiliki alamat IP 130.37.20.20. DNS menciptakan simpul bernama 20.20.37.130.in-addr.mpa, yang digunakan untuk menyimpan Nama kanonik bahwa tuan rumah (yang kebetulan soling.cs. vu.nl i dalam catatan PTR.

Dua yang terakhir adalah jenis catatan catatan HINFO dan catatan TXT. sebuah HINFO (Info host) record digunakan untuk menyimpan informasi tambahan pada host seperti mesin nya jenis dan sistem operasi. Dalam cara yang sama, TXT catatan yang digunakan untuk jenis lain dari data yang pengguna menemukan berguna untuk menyimpan sekitar entitas diwakili oleh node.

DNS Implementasi

Pada dasarnya, ruang nama DNS dapat dibagi menjadi lapisan global dan administrasi lapisan. Lapisan manajerial, yang umumnya dibentuk oleh sistem file lokal, secara resmi bukan bagian dari DNS dan karena itu juga tidak dikelola olehnya. Sebuah database DNS diimplementasikan sebagai kumpulan (kecil) dari file, dari mana salah satu yang paling penting berisi semua catatan sumber daya untuk semua node dalam tertentu zona. Pendekatan ini memungkinkan node dapat diidentifikasi hanya dengan cara domain mereka Nama, di mana gagasan pengenal simpul mengurangi ke index (implisit) ke dalam sebuah file.

Untuk lebih memahami isu-isu implementasi ini menunjukkan kecil bagian dari file yang berisi sebagian besar informasi untuk domain cs.vu.nl (yang file telah diedit untuk kesederhanaan). File menunjukkan isi dari beberapa node yang merupakan bagian dari cs. vu.nl domain, di mana setiap node diidentifikasi dengan cara yang nama domain.

cs.vu.nl simpul merupakan domain serta zona. Its SOA sumber daya catatan berisi informasi spesifik tentang validitas file ini. yang tidak akan perhatian kita lebih lanjut. Ada empat nama server untuk zona ini, disebut oleh mereka kanonik nama host dalam catatan NS. Catatan TXT digunakan untuk memberikan beberapa informasi tambahan mengenai zona ini, tetapi tidak dapat secara otomatis diproses oleh nama server. Selain itu, ada mail server tunggal yang dapat menangani masuk surat yang ditujukan bagi pengguna di domain ini. Jumlah sebelum nama mail Server menentukan prioritas pemilihan. Sebuah mail server mengirimkan selalu upaya harus pertama untuk menghubungi server mail dengan angka terendah.

Tuan rumah star.cs. vu.nl beroperasi sebagai server nama untuk zona ini. Nama server sangat penting untuk setiap layanan penamaan. Apa yang bisa dilihat tentang server nama adalah bahwa ketahanan tambahan telah dibuat dengan memberikan dua antarmuka jaringan yang terpisah, masing-masing diwakili oleh rekor Sebuah sumber daya yang terpisah. Dengan cara ini, efek dari patah link jaringan dapat agak dikurangi sebagai server akan tetap dapat diakses.

Empat baris berikutnya (untuk zephyr.cs. Vu.nl) memberikan informasi yang diperlukan tentang salah satu dari server mail departemen. Perhatikan bahwa ini mail server juga didukung oleh orang lain mail server, yang jalan adalah tornado.cs. vu.nl. Enam baris berikutnya menunjukkan konfigurasi yang khas di mana departemen Web server, serta server FTP departemen dilaksanakan oleh satu mesin, disebut soling. cs. vu. nl. Dengan melaksanakan kedua server pada mesin yang sama (dan pada dasarnya menggunakan mesin yang hanya untuk layanan internet dan tidak apa-apa lain), sistem manajemen menjadi lebih mudah. Misalnya, kedua server akan memiliki pandangan yang sama dari sistem file, dan untuk efisiensi, bagian dari sistem file mungkin diimplementasikan pada soling.cs.vu.nl, pendekatan ini sering diterapkan dalam kasus WWW dan FTP jasa.

Dua baris berikut menampilkan informasi pada salah satu departemen yang lebih tua server cluster. Dalam kasus ini, ia memberitahu kita bahwa alamat 130.37.198.0 dikaitkan dengan nama host vucs-dasl.cs.vu.nl, Empat baris berikutnya menampilkan informasi pada dua printer utama terhubung ke jaringan lokal. Perhatikan bahwa alamat dalam kisaran 192.168.0.0 sampai 192.168.255.255 adalah swasta: mereka hanya dapat diakses dari dalam jaringan lokal dan tidak diakses dari host Internet yang sewenang-wenang.

Karena domain cs.vu.nl diimplementasikan sebagai zona tunggal. Gambar. 5-20 tidak tidak termasuk referensi ke zona lain. Cara untuk merujuk pada node di subdomain yang dilaksanakan di zona yang berbeda ditunjukkan pada Gambar. 5-21. Apa yang perlu dilakukan adalah untuk menentukan server nama untuk subdomain dengan hanya memberikan domainnya nama dan alamat IP. Ketika menyelesaikan nama untuk node yang terletak di cs.vu.nl domain, resolusi nama akan berlanjut pada titik tertentu dengan membaca database DNS disimpan oleh server nama untuk cs. vu.nl domain.

Name	Record type	Record value
cs.vu.nl	NIS	solo.cs.vu.nl
solo.cs.vu.nl	A	130.37.21.1

4.1.5 Example : X.500

DNS adalah contoh dari layanan penamaan tradisional: ketika diberi nama (mungkin terstruktur secara hierarkis), DNS menjelaskan nama ke sebuah node dalam grafik penamaan dan mengembalikan isi dari simpul dalam bentuk catatan sumber daya. Dalam pengertian ini, DNS dapat dikatakan sebanding dengan buku telepon untuk mencari nomor telepon.

Pendekatan yang berbeda diambil oleh apa yang disebut layanan direktori. Sebuah layanan direktori adalah jenis khusus dari layanan penamaan di mana klien dapat mencari suatu entitas berdasarkan deskripsi sifat bukan nama lengkap. Pendekatan ini sangat mirip dengan cara orang menggunakan halaman kuning ketika mereka butuhkan, misalnya, seseorang untuk memperbaiki jendela yang pecah. dalam kasus itu, pengguna dapat melihat di bawah "perbaikan jendela" pos untuk mendapatkan daftar (nama) perusahaan yang mengganti jendela.

Dalam bagian ini, kita melihat singkat di layanan direktori X.500 OSI. meskipun layanan direktori telah tersedia selama satu dekade lebih, hanya baru-baru ini mendapatkan popularitas lebih sebagai versi ringan sedang diimplementasikan sebagai layanan internet. Informasi lengkap mengenai X.500 dapat ditemukan dalam (Chadwick, 1994; Radicati, 1994). Informasi praktis mengenai berbagai layanan direktori, termasuk X.500, dapat ditemukan dalam (Sheresh dan Sheresh, 2000).

Space Name X.500

Secara konseptual, layanan direktori X.500 terdiri dari sejumlah catatan, biasanya disebut sebagai entri direktori. Sebuah entri direktori X.500 sebanding dengan catatan sumber daya dalam DNS. Setiap record terdiri dari kumpulan (atribut, value) pasangan, di mana setiap atribut memiliki tipe yang terkait. Sebuah perbedaan dibuat antara nilai-tunggal atribut. Yang terakhir ini biasanya mewakili array dan daftar. Sebagai contoh, entri direktori sederhana mengidentifikasi jaringan alamat dari beberapa server umum dari Gambar. 4-13 ditunjukkan pada Gambar. 4-15.

Dalam contoh kita, kita telah menggunakan konvensi penamaan dijelaskan dalam standar X.500, yang berlaku untuk lima atribut pertama. Organisasi atribut dan OrganizationUnit menjelaskan, masing-masing, organisasi dan departemen terkait dengan data yang disimpan dalam catatan. Demikian juga, Locality atribut dan Negara memberikan informasi tambahan di mana entri disimpan. Atribut CommonName sering digunakan sebagai nama (ambigu) untuk mengidentifikasi

masuk dalam bagian terbatas dari direktori. Misalnya, nama "server utama" mungkin cukup untuk menemukan entri contoh kita diberi nilai-nilai tertentu untuk empat lainnya atribut Negara, Locality, Organisasi OrganizationalUnit, dan. Dalam contoh kita, hanya atribut Mail_Servers memiliki beberapa nilai yang terkait dengannya. Semua atribut lainnya hanya memiliki nilai tunggal.

Pengumpulan semua entri direktori dalam layanan direktori X.500 disebut Informasi Direktori Dasar (DIB). Sebuah aspek penting dari DIB adalah bahwa setiap record secara unik bernama sehingga dapat mendongak. Seperti nama unik secara global muncul sebagai urutan penamaan atribut dalam setiap record. Setiap atribut penamaan disebut Nama Distinguished Relatif, atau RDN untuk pendek. Dalam contoh kita di Gambar. 4-15, lima pertama atribut semua atribut penamaan. Menggunakan singkatan konvensional untuk mewakili atribut penamaan dalam X.500 seperti yang ditunjukkan pada Gbr.4-15, Negara atribut, Organisasi, dan OrganizationalUnit dapat digunakan untuk membentuk nama unik secara global analog dengan nama DNS nl.vu.cs.

            /C=NL/O=Vrijie Universiteit/OU=Math. & Comp.Sc.

Seperti di DNS, penggunaan nama unik secara global oleh rDNS daftar secara berurutan, mengarah ke sebuah struktur dari koleksi entri direktori, yang disebut sebagai Pohon Information Directory (DIT). Sebuah Dit dasarnya membentuk grafik penamaan layanan direktori X.500 di mana setiap node merupakan entri direktori. Selain itu, node juga dapat bertindak sebagai direktori dalam arti tradisional, karena mungkin ada beberapa anak yang node bertindak sebagai orang tua ke sejumlah entri direktori lain yang memiliki HOST_NAME penamaan atribut tambahan yang digunakan sebagai RDN. Misalnya, entri tersebut dapat digunakan untuk mewakili tuan rumah seperti yang ditunjukkan pada Gambar. 4-16 (b).

Gambar 4-16. (a) Bagian dari pohon informasi direktori. (b) Dua entri direktori yang memiliki HOST_NAME sebagai RDN.

Sebuah node dalam sebuah grafik penamaan X.500 sehingga dapat secara bersamaan merupakan sebuah direktori dalam pengertian tradisional seperti yang kita bahas sebelumnya, serta catatan X.500. Perbedaan ini didukung oleh dua operasi pencarian yang berbeda. Operasi baca digunakan untuk membaca satu catatan data diberi nama path dalam Dit. Sebaliknya, operasi list digunakan untuk membuat daftar nama-nama semua tepi keluar dari node yang diberikan di Dit. Setiap nama sesuai dengan node anak dari node yang diberikan. Perhatikan bahwa daftar operasi tidak mengembalikan catatan, melainkan hanya mengembalikan nama. Dengan kata lain, membaca dengan calling masukan nama

            /C=NL/O=Vrije Universiteit/OU=Math. & Comp. Sc./CN=Main server

akan kembali di catatan yang ditunjukkan pada Gbr.4-15, sedangkan memanggil daftar akan mengembalikan Bintang nama dan zephyr dari entri yang ditunjukkan dalam Gbr.4-16 (b) serta nama-nama host lain yang telah terdaftar dalam yang sama cara.

X.500 Implementation

Menerapkan hasil direktori X.500 layanan dalam banyak cara yang sama seperti menerapkan layanan penamaan seperti DNS, kecuali X.500 yang mendukung operasi yang lebih lookup seperti yang akan kita bahas segera. Ketika berhadapan dengan direktori besar-besaran, yang Dit biasanya dipartisi dan didistribusikan di beberapa server, dikenal sebagai Agen Layanan direktori (DSA) dalam X.500Vterminology. setiap bagian dari Dit dipartisi sehingga sesuai dengan zona dalam DNS. Demikian juga, masing-masing DSA berperilaku sangat banyak yang sama sebagai server nama normal, kecuali bahwa ia menerapkan sejumlah serrvices direktori yang khas, seperti operasi pencarian lanjutan.

Klien yang diwakili oleh apa yang disebut direktori agen pengguna, atau hanya Duas. Sebuah DUA adalah mirip dengan penyelesai nama dalam layanan penamaan tradisional, A DUA pertukaran informasi dengan DSA menurut accessprotocol standar.

Apa yang membuat sebuah implementasi X.500 berbeda dari implementasi DNS adalah facilitics untuk mencari melalui DIB. Secara khusus, fasilitas yang disediakan entri harus untuk entri direktori diberi satu set critcria yang atribut dari entri mencari entri direktori tertentu seperangkat kriteria bahwa atribut dari entri dicari harus bertemu. Sebagai contoh, misalkan kita ingin daftar server utama ail di Vrije universiteit. Menggunakan notasi didefinisikan dalam (Howes, 1997), daftar tersebut dapat dikembalikan dengan menggunakan operasi pencarian seperti

Answer = search(“&(C=NL)(O=Vrije Universiteit)((OU=*)(CN=Main server)”)

Dalam contoh ini, kami telah menetapkan bahwa tempat untuk mencari server utama adalah organisasi bernama Vrije Universiteit di negara NL, tetapi bahwa kita tidak tertarik pada unit organisasi tertentu. Namun, masing-masing kembali eresult harus havee atribut CN sama dengan server utama.

Sebuah pengamatan penting adalah bahwa dalam mencari layanan direktori umumnya merupakan operasi yang mahal. Sebagai contoh, untuk menemukan semua server utama di Vrije Universiteit membutuhkan mencari semua entri di departemen masing-masing dan menggabungkan hasil dalam satu jawaban. Dalam wotds lain, kita umumnya akan perlu untuk mengakses beberapa node daun dari Dit untuk mendapatkan jawaban, dalam prakteknya, hal ini juga berarti bahwa beberapa DSAs perlu diakses. Dalam kontrak, layanan penamaan sering dapat diimplementasikan sedemikian rupa sehingga operasi pencarian membutuhkan mengakses hanya simpul daun tunggal.

Tinggal di sejalan dengan banyak protokol OSI lainnya, accesing sebuah direktori X.500 menurut aturan resmi tidak sepele. Untuk mengakomodasi layanan direktori X.500 di internet, sebuah protokol sederhana telah dirancang, dikenal sebagai protokol akses direktori ringan (LDAP)

LDAP adalah protokol level aplikasi yang diimplementasikan langsung di atas TCP (Yeong et al, 1995;.. Whal et al, 1997), yang sendiri memberikan kontribusi kesederhanaan dibandingkan dengan protokol OSI akses resmi. Selain itu, parameter pencarian dan operasi update hanya dapat lulus sebagai string, daripada menggunakan pengkodean yang terpisah seperti yang dipersyaratkan oleh protokol OSI. LDAP secara bertahap menjadi standar de facto untuk internet berbasis layanan direktori. Hal ini sedang intgered ke dalam sistem terdistribusi, termasuk, misalnya, Windows 2000, yang kita bahas dalam Chap.9. Informasi praktis tentang LDAP dapat ditemukan di (Johner et al., 1998).

4.2 LOCATING MOBILE ENTITIES

Layanan penamaan dibahas sejauh ini, terutama digunakan untuk penamaan entitas yang memiliki lokasi tetap. Secara alami mereka, sistem penamaan tradisional tidak cocok untuk mendukung nama ke alamat pemetaan yang berubah secara teratur, seperti halnya dengan entitas mobile. Isuue ini dibahas dalam bagian ini, bersama dengan solusi untuk mencari entitas mobile.

4.2.1 Naming versus Locating Entities

Seperti dijelaskan di bagian sebelumnya, entitas diberi nama sehingga mereka dapat mendongak dan kemudian accesed. Ada jenis yang dibedakan nama: nama ramah manusia, identifier, dan alamat. Karena sistem terdistribusi dibangun untuk digunakan oleh manusia dan karena itu perlu untuk memiliki alamat anentity untuk mengaksesnya, hampir semua sistem penamaan mempertahankan pemetaan nama ke alamat yang ramah manusia.

Seperti yang kita juga menjelaskan, untuk secara efektif menerapkan ruang nama skala besar seperti di DNS, hal ini berguna untuk partisi ruang nama menjadi tiga lapisan. Lapisan global dan lapisan administrasi dicirikan oleh kenyataan bahwa nama tidak berubah sering. Lebih tepatnya, isi node di bagian-bagian dari ruang nama relatif stabil. Akibatnya, implementasi yang efisien dapat dicapai melalui replikasi dan caching.

Node di lapisan manajerial sering berubah-ubah. Oleh karena itu, kinerja update dan pencarian menjadi penting. Dalam prakteknya, tuntutan kinerja dapat dipenuhi dengan menerapkan node pada server, kinerja nama lokal yang tinggi.

Mari kita lihat lebih dekat di mana asumsi yang sebenarnya dibuat, dan mengapa pendekatan ini menuju implementasi skala besar penamaan kerja sistem. Pertama mempertimbangkan lagi mencari alamat host (remote) ftp.cs.vu.nl. Dengan asumsi bahwa isi dari node di lapisan global dan administrasi yang stabil, besar kemungkinan bahwa klien dapat menemukan alamat server nama untuk domain cs.vu.nl dalam cache lokal. Akibatnya, hanya satu permintaan harus dikirim ke server nama untuk menemukan alamat ftp.cs.vu.nl.

Selanjutnya, pertimbangkan memperbarui alamat ftp.cs.vu.nl. Misalnya karena server FTP yang akan pindah ke mesin yang berbeda. Selama server dipindahkan ke mesin dalam domain cs.vu.nl, update bisa dilakukan secara efisien. Dalam hal ini, hanya database DNS dari server nama untuk cs.vu.nl harus diubah. Pencarian akan seefisien mereka sebelumnya.

Akibatnya, dengan assurning bahwa node di lapisan global dan administrasi tidak sering berubah-ubah dan juga dengan asumsi bahwa update umumnya terbatas pada server nama tunggal, penamaan sistem seperti DNS dapat dibuat sangat efisien.

Sekarang perhatikan apa yang terjadi jika ftp.cs.vu.nl adalah untuk pindah ke sebuah mesin bernama ftp.cs.unisa.edu.au, yang terletak di domain yang sama sekali berbeda. Pengamatan pertama untuk membuat, adalah bahwa ftp.cs.vu.nl nama sebaiknya tidak berubah, karena dapat diharapkan bahwa banyak aplikasi dan pengguna akan memiliki link simbolik untuk itu. Dengan kata lain, nama ini mungkin digunakan sebagai identifier. Perubahan itu akan menyebabkan semua link itu menjadi tidak valid.

Sekarang ada dasarnya dua solusi. Salah satu solusi untuk merekam Apakah alamat mesin baru dalam database DNS untuk cs.vu.nl. solusi alternatif adalah untuk mencatat nama mesin baru, bukan alamatnya, efektif mengubah ftp.cs.vu.nl menjadi link simbolik. Kedua solusi memiliki kelemahan yang serius.

Pertama, mari kita merekam alamat dari mesin baru. Jelas, operasi pencarian tidak terpengaruh oleh pendekatan ini. Namun, setiap kali ftp.cs.vu.nl bergerak sekali lagi ke komputer lain, masuk dalam database DNS di cs.vu.nl harus diperbarui juga. Penting untuk diperhatikan bahwa update ini lagi operasi lokal tetapi sebenarnya dapat mengambil ratusan milidetik untuk menyelesaikan. Dengan kata lain, pendekatan ini melanggar asumsi bahwa operasi pada node di lapisan manajerial yang efisien.

Kelemahan utama menggunakan symbolic link adalah bahwa operasi pencarian menjadi kurang efisien. Akibatnya, pencarian masing-masing dibagi menjadi dua langkah:

1. Cari nama dari mesin baru.

2. Carilah alamat yang terkait dengan nama itu.

Namun, ftp.cs.vu.nl adalah untuk bergerak lagi, katakan kepada ftp.cs.berkeley.edu, kita dapat melakukan operasi update lokal dengan memutar ftp.cs.unisa.edu.au nama menjadi link simbolik ke ftp cs.berkeley.edu,. dan meninggalkan entri dalam database DNS untuk cs.vu.nl. seperti itu. Kekurangannya adalah bahwa kami telah menambahkan langkah lain untuk operasi pencarian.

Untuk entitas yang sangat mobile, masalah hanya menjadi lebih buruk. Setiap kali suatu entitas bergerak, baik operasi update nonlokal perlu dilakukan atau langkah lain yang ditambahkan untuk pencarian operasi.

Masalah lain yang serius dengan pendekatan yang disebutkan sejauh ini, adalah bahwa ftp.cs.vu.nl nama tidak diperbolehkan untuk mengubah. Akibatnya, akan menjadi sangat penting untuk memilih nama-nama yang dapat diharapkan tidak berubah untuk seumur hidup dari entitas yang mereka wakili. Selain itu, nama itu tidak dapat digunakan untuk setiap entitas lainnya. Dalam prakteknya, memilih nama-nama tersebut, terutama untuk entitas hidup yang sangat panjang, sulit, seperti yang ditunjukkan oleh penamaan di World Wide Web. Secara khusus, banyak entitas yang dikenal dengan nama yang berbeda, dan semua nama harus tetap berlaku, yaitu, selalu mengacu pada entitas yang sama, bahkan dalam menghadapi mobilitas.

Untuk alasan ini, layanan penamaan tradisional seperti DNS tidak bisa mengatasi dengan baik dengan entitas mobile, dan solusi yang berbeda diperlukan. Pada dasarnya, masalah timbul karena layanan penamaan tradisional mempertahankan pemetaan langsung antara nama ramah manusia dan alamat dari entitas. Setiap kali nama atau perubahan alamat, pemetaan perlu berubah juga, seperti yang ditunjukkan pada gambar. 4 - 17 (a).

a) Langsung, pemetaan tingkat satu antara nama dan alamat.

b) Dua tingkat pemetaan menggunakan pengidentifikasi.

Sebuah Solusi Yang lebih BAIK adalah Artikel Baru memisahkan penamaan bahasa Dari entitas KBLI Artikel Baru memperkenalkan pengidentifikasi, seperti Yang ditunjukkan PADA GAMBAR 4 - 17 (b). ingat bahwa identifier tidak pernah berubah, bahwa masing-masing entitas memiliki tepat Satu identifier, Dan bahwa sebuah identifier tidak pernah ditugaskan untuk entitas Yang berbeda (Wieringa Dan de Jonge, 1995). Secara Umum, sebuah identifier tidak dimaksudkan untuk memiliki representasi Rama manusia. Baru kata Lain, ITU dioptimalkan untuk Saja machineprocessing.

Ketika mencari sebuah entitas dengan cara layanan penamaan, layanan yang mengembalikan sebuah identifier. Identifier dapat disimpan secara lokal untuk diperlukan karena diketahui tidak pernah merujuk pada entitas yang berbeda, dan tidak akan pernah berubah. Di mana nama disimpan secara lokal, tidak penting. Akibatnya, ketika identifier yang diperlukan waktu berikutnya, itu hanya dapat diambil secara lokal tanpa harus mencarinya dengan cara layanan penamaan.

Mencari entitas ditangani dengan cara layanan lokasi yang terpisah. Sebuah layanan lokasi pada dasarnya menerima pengenal sebagai input, dan mengembalikan alamat saat entitas diidentifikasi. Jika beberapa salinan exict, maka beberapa alamat dapat dikembalikan. Pada bagian ini, kita hanya berkonsentrasi pada masalah pelaksanaan layanan lokasi yang efisien.

4.2.2 Simple Solution

Kami pertama mempertimbangkan dua solusi sederhana untuk menemukan suatu entitas. Kedua solusi ini hanya berlaku untuk jaringan area lokal. Namun demikian, dalam lingkungan tersebut, mereka sering melakukan pekerjaan dengan baik, membuat kesederhanaan mereka sangat menarik.

Penyiaran dan multicasting.

Pertimbangkan sebuah system terdistribusi yang dibangun pada jaringan komputer yang menawarkan fasilitas penyiaran yang efisien. Biasanya, fasilitas seperti yang ditawarkan oleh local-areanet-karya di mana semua mesin yang terhubung ke kabel tunggal. Juga jaringan area local nirkabel termasuk dalam kategori ini.

Mencari entitas di lingkungan seperti sederhana: pesan yang berisi identifier dari entitas yang disiarkan ke setiap mesin dan mesin masing-masing diminta untuk memeriksa apakah ia memiliki entitas itu. Hanya mesin yang dapat menawarkan jalur akses untuk entitas mengirim pesan balasan yang berisi alamat dari titik akses.

Prinsip ini digunakan dalam alamat internet Resolution Protocol (ARP) untuk menemukan alamat data-link dari mesin ketika hanya diberi alamat IP (Plummer, 1982). Pada dasarnya, mesin menyiarkan paket pada jaringan local bertanya siapa pemilik dari alamat IP yang diberikan. Ketika pesan sampai di mesin, penerima memeriksa apakah mendengarkan alamat IP yang diminta. Jika demikian, ia akan mengirimkan paket balasanyang berisi, misalnya, alamat Ethernet.

Penyiaran menjadi tidak efisien ketika jaringan tumbuh. Tidak hanya bandwidth jaringan terbuang oleh pesan permintaan, namun, lebih, serius, host terlalu banyak dapat terganggu oleh permintaan mereka tidak bisa menjawab. Salah satu solusi yang mungkin adalah untuk beralih ke multicasting, dimana hanya kelompok terbatas dari host menerima permintaan. Misalnya, Ethernet jaringan dukungan data-link level multicasting langsung di hardware.

Multicasting juga dapat digunakan untuk mencari entitas dalam point-to-point jaringan. Misalnya, internet mendukung jaringan-tingkat multicasting dengan memungkinkan host untuk bergabung dengan grup multicast tertentu. Kelompok tersebut diidentifikasi dengan alamat multicast. Ketika tuan rumah mengirimkan pesan ke alamat multicast, lapisan jaringan menyediakan layanan terbaik-upaya untuk menyampaikan pesan itu kepada semua anggota kelompok. Implementasi yang efisien untuk multicasting di internet dibahas dalam (Deering dan Cheriton, 1990;. Deeringetal, 1996).

Sebuah alamat multicast dapat digunakan sebagai layanan lokasi umum untuk beberapa entitas. Sebagai contoh, pertimbangkan sebuah organisasi di mana setiap karyawan memiliki nya atau komputer sendiri mobile-nya. Ketika seperti komputer terhubung ke jaringan yang tersedia secara lokal, itu ditetapkan secara dinamis alamat IP. Selain itu, bergabung dengan kelompok multicast tertentu. Ketika sebuah proses ingin mencari komputer A, ia akan mengirimkan "di mana adalah A?" Permintaan untuk kelompok multicast. Jika A adalah terhubung, akan meresponnya dengan Alamat IP-nya saat ini. 

Cara lain untuk menggunakan addresss multicast adalah mengasosiasikannya dengan entitas direplikasi, dan menggunakan multicasting untuk mencari replika terdekat. Saat mengirim permintaan ke alamat multicast, setiap replika merespon dengan saat ini alamatnya (normal) IP. Sebuah cara sederhana untuk memilih replika terdekat adalah untuk memilih salah satu yang yg pertama datang. Pendekatan yang lebih akurat dijelaskan dalam (Guyton dan Schwartz, 1995). Ternyata, memilih replika terdekat umumnya tidak mudah.

Forwarding Pointer

Pendekatan anothers populer untuk mencari entitas mobile untuk menggunakan untuk menangkal-pointer (Flowler, 1985). Prinsipnya sederhana: ketika entitas bergerak dari A ke B, itu meninggalkan referensi ke lokasi baru di B. Keuntungan utama dari pendekatan ini adalah kesederhanaannya: secepat entitas telah ditemukan, misalnya dengan menggunakan layanan penamaan tradisional, klien dapat mencari alamat saat ini dengan mengikuti rantai pointer forwarding.

Ada juga sejumlah kelemahan penting. Pertama, jika tidak ada tindakan khusus dilakukan, rantai bisa menjadi begitu lama bahwa menemukan sebuah entitas yang mahal. Kedua, semua lokasi antara dalam rantai harus mempertahankan bagian mereka untuk rantai forwarding pointer selama diperlukan. Kelemahan ketiga, dan yang terkait, adalah kerentanan terhadap link yang rusak. Segera setelah pointer forwarding hilang untuk alasan apa pun, entitas tidak dapat lagi dihubungi. Suatu hal yang penting adalah, oleh karena itu, untuk menjaga rantai yang relatif pendek, dan untuk memastikan bahwa pointer forwarding yang kuat.

Untuk lebih memahami bagaimana forthe menangkal pointer kerja, condiser penggunaannya dengan repsepct ke objek didistribusikan. Mengikuti pendekatan dalam rantai SSP (Shapiro et al, 1992., Setiap pointer forwarding diimplementasikan sebagai sepasang (proxy, kerangka) seperti yang ditunjukkan pada Gbr.4-18 (di SSP, proxy disebut stub dan kerangka keturunan seorang, mengarah ke (rintisan, sction) pasangan, yang menjelaskan singkatan SSP) kerangka scion, memimpin sisi server stub) mengandung baik referensi lokal untuk objek yang sebenarnya atau referensi lokal untuk proxy (yaitu, klien - rintisan. ) untuk objek tersebut. Untuk menekankan bahwa tindakan kerangka sebagai barang masuk untuk referensi terpencil dan proxy sebagai barang keluar, kita menggunakan notasi seperti yang ditunjukkan pada Gambar 4-18.

Setiap kali sebuah benda bergerak dari ruang adderess A ke B. itu meninggalkan proxy di tempatnya di A dan menginstal kerangka yang referens untuk itu dalam B. aspek menarik dari pendekatan ini adalah bahwa migrasi benar-benar transparan kepada klien. Satu-satunya melihat obyek, adalah proxy, bagaimana dan dimana lokasi yang meneruskan proksi doa yang tersembunyi dari klien. Sedap dicatat bahwa ini penggunaan pointer forwarding tidak sama dengan lookingup alamat. Sebaliknya permintaan klien penyampaian sepanjang rantai ke objek yang sebenarnya.

Untuk pendek memotong rantai (proxy, kerangka) pasang sebuah doa membawa identifikasi proxy dari mana doa yang diprakarsai. Sebuah identifikasi Proxy terdiri dari transportasi-tuas alamat klien, dikombinasikan dengan nomor alocally dihasilkan untuk mengidentifikasi proxy. Ketika doa mencapai obyek di lokasi saat ini, respon yang dikirim kembali ke proxy mana doa itu dimulai. Lokasi saat ini piggybacked dengan tanggapan dan proxy menyesuaikan kerangka pendamping kepada salah satu di lokasi objek saat ini. Prinsip ini ditunjukkan pada Gambar 4-19

            Ada trade-off antara mengirimkan respon langsung ke proxy memulai, atau sepanjang jalan kebalikan dari pointer forwarding. Dalam kasus yang pertama, komunikasi lebih cepat karena proses sedikit mungkin perlu disetujui. Di sisi lain, hanya proxy mengawali dapat disesuaikan, sedangkan mengirimkan reponses sepanjang jalan reverse memungkinkan penyesuaian semua proxy menengah.

            Ketika kerangka tidak lagi disebut oleh proxy apapun. Hal ini dapat dihapus. Bagaimana hal ini dapat dilakukan secara otomatis, dibahas dalam sec 4.3

            Seperti yang kita dijelaskan dalam bab 2, referensi objek di terdistribusi - sistem objek dapat diimplementasikan sebagai proxy yang dikirimkan sebagai parameter dalam pemanggilan menthod. Skema ini masih bekerja dengan pointer forwarding. Misalkan p1 proses ara 4-18 melewati objek refence nya 0 sampai lewat proses p2.references dilakukan dengan memasang salinan p 'dari p proxy dalam ruang alamat dari proses p2. Proxy 'p mengacu pada kerangka yang sama seperti p sehingga mekanisme doa forwarding bekerja sama seperti sebelumnya.

Masalah timbul ketika proses rantai (proxy, kerangka) pasang crash atau menjadi lain tidak bisa dijangkau. Beberapa solusi yang mungkin. Salah satu kemungkinan yang diikuti di zamrud (Juli et al, 1988.) Dan dalam sistem LII (Hitam dan Artsy. 19900 adalah untuk membiarkan mesin mana objek diciptakan (disebut lokasi rumah obyek), selalu menjaga refernces ke lokasi saat ini referensi Itu. disimpan dan dipelihara dengan cara kesalahan-toleran. Ketika rantai rusak, lokasi rumah benda tersebut akan bertanya di mana benda-benda sekarang. untuk memungkinkan sebuah lokasi rumah obyek untuk mengubah, layanan penamaan tradisional dapat digunakan untuk catatan lokasi rumah saat ini. pendekatan berbasis rumah tersebut akan kita diskusikan nanti.