NAMING TERSTRUKTUR

Nama datar baik untuk mesin, tetapi umumnya tidak terlalu nyaman untuk digunakan manusia. Sebagai
alternatif, sistem penamaan umumnya mendukung nama terstruktur yang terdiri dari nama-nama
sederhana yang dapat dibaca manusia. Tidak hanya penamaan file, tetapi juga penamaan host di Internet
ikuti pendekatan ini. Di bagian ini, kami berkonsentrasi pada nama terstruktur dan cara nama-nama ini
diselesaikan ke alamat.

5.3.1 Ruang Nama

Nama-nama biasanya disusun dalam apa yang disebut ruang nama. Ruang nama untuk nama terstruktur
dapat direpresentasikan sebagai graf berarah berlabel dengan dua jenis node. Node daun mewakili entitas
bernama dan memiliki properti yang tidak memiliki tepi keluar. Node daun umumnya menyimpan
informasi tentang entitas yang diwakilinya misalnya, alamatnya - sehingga klien dapat mengaksesnya.
Atau, ia dapat menyimpan keadaan entitas itu, seperti dalam kasus sistem file di mana node daun benar-
benar berisi file lengkap yang diwakilinya. Kami kembali ke isi node di bawah ini.

Berbeda dengan node daun, node direktori memiliki sejumlah tepi keluar, masing-masing diberi label
dengan nama, seperti yang ditunjukkan pada Gambar. 5-9. Setiap node dalam grafik penamaan dianggap
sebagai entitas lain dalam sistem terdistribusi, dan, khususnya, memiliki pengidentifikasi terkait. Node
direktori menyimpan tabel di mana tepi keluar direpresentasikan sebagai pasangan (label tepi,
pengidentifikasi node). Tabel seperti ini disebut tabel direktori.

Gambar 5-9. Grafik penamaan umum dengan node akar tunggal

Grafik penamaan yang ditunjukkan pada Gambar 5-9 memiliki satu node, yaitu tidak, yang hanya memiliki
tepi keluar dan tidak ada yang masuk. Node seperti itu disebut root (node) dari grafik penamaan.
Meskipun dimungkinkan untuk grafik penamaan untuk memiliki beberapa node root, untuk
kesederhanaan, banyak sistem penamaan hanya memiliki satu. Setiap jalur dalam grafik penamaan dapat
dirujuk dengan urutan label yang sesuai dengan tepi di jalur itu, seperti :

Nt-clabel-I, label-2, ..., label-n>

Di mana N merujuk ke node pertama di jalur. Urutan seperti itu disebut nama jalur. Jika node pertama
dalam nama path adalah akar dari grafik penamaan, itu disebut "nama path absolut. Jika tidak, itu disebut
nama path relatif.

Penting untuk disadari bahwa nama selalu diatur dalam ruang nama. Sebagai akibatnya, nama selalu
didefinisikan relatif hanya untuk node direktori. Dalam pengertian ini, istilah "nama absolut" agak
menyesatkan. Demikian juga, perbedaan antara nama global dan lokal seringkali membingungkan. Nama
global adalah nama yang menunjukkan entitas yang sama, di mana pun nama itu digunakan dalam suatu
sistem. Dengan kata lain, nama global selalu ditafsirkan sehubungan dengan node direktori yang sama.
Sebaliknya, nama lokal adalah nama yang interpretasinya tergantung pada di mana nama itu digunakan.
Dengan kata lain, nama lokal pada dasarnya adalah nama relatif yang direktori tempat isinya diketahui
(secara implisit) diketahui. Kami kembali ke masalah ini nanti ketika kami membahas resolusi nama.

Deskripsi grafik penamaan ini mendekati apa yang diterapkan di banyak sistem file. Namun, alih-alih
menulis urutan label tepi untuk merepresentasikan nama jalur, nama jalur dalam sistem file umumnya
direpresentasikan sebagai string tunggal di mana label dipisahkan oleh karakter pemisah khusus, seperti
garis miring ("1"). Karakter ini juga digunakan untuk menunjukkan apakah nama jalur mutlak. Sebagai
contoh, pada Gambar 5-9, alih-alih menggunakan no: <home, steen, mbox>, yaitu, nama path aktual,
adalah praktik umum untuk menggunakan representasi string-nya Ihome / steen / mbox. Perhatikan juga
bahwa ketika ada beberapa jalur yang mengarah ke node yang sama, node itu dapat diwakili oleh nama
jalur yang berbeda. Sebagai contoh, node n 5 pada Gambar. 5-9 dapat dirujuk oleh Ihome / steenlkeys
serta / keys. Representasi string dari nama path dapat juga diterapkan dengan baik pada grafik penamaan
selain yang digunakan untuk sistem file saja. Dalam Plan 9 (Pike et al., 1995), semua sumber daya, seperti
proses, host, perangkat I / O, dan antarmuka jaringan, dinamai dengan cara yang sama seperti file
tradisional. Pendekatan ini analog dengan implementasi grafik penamaan tunggal untuk semua sumber
daya dalam sistem terdistribusi.

Ada banyak cara berbeda untuk mengatur ruang nama. Seperti yang kami sebutkan, sebagian besar ruang
nama hanya memiliki satu node root. Dalam banyak kasus, ruang nama juga sangat hierarkis dalam arti
bahwa grafik penamaan diatur sebagai pohon. Ini berarti bahwa setiap node kecuali root memiliki tepat
satu tepi yang masuk; root tidak memiliki tepi yang masuk. Sebagai konsekuensinya, setiap node juga
memiliki persis satu nama path terkait (absolut).

Grafik penamaan yang ditunjukkan pada Gambar 5-9 adalah contoh grafik asiklik terarah. Dalam
organisasi seperti itu, sebuah node dapat memiliki lebih dari satu sisi yang masuk, tetapi grafik tidak
diizinkan memiliki siklus. Ada juga ruang nama yang tidak memiliki batasan ini.

Untuk membuat masalah lebih konkret, pertimbangkan cara nama file dalam sistem file UNIX tradisional
dinamai. Dalam grafik penamaan untuk UNIX, node direktori mewakili direktori file, sedangkan node leaf
mewakili file. Ada direktori root tunggal, diwakili dalam grafik penamaan oleh node root. Implementasi
grafik penamaan merupakan bagian integral dari implementasi lengkap sistem file. Implementasi itu
terdiri dari serangkaian blok yang berdekatan dari disk logis, umumnya dibagi menjadi blok boot,
superblock, serangkaian node indeks (disebut inode), dan file blok data. Lihat juga Crowley (1997),
Silberschatz et al. (2005), dan Tanenbaum dan Woodhull (2006). Organisasi ini ditunjukkan pada Gambar.
5-10.
 Gambar 5 · 10. Organisasi umum implementasi sistem file UNIX pada disk logis dari blok disk yang berdekatan.

Blok boot adalah blok khusus data dan instruksi yang secara otomatis dimuat ke dalam memori utama
ketika sistem di-boot. Blok boot digunakan untuk memuat sistem operasi ke dalam memori utama.

Superblock berisi informasi tentang keseluruhan sistem file. seperti ukurannya, blok mana pada disk yang
belum dialokasikan, inode mana yang belum digunakan, dan sebagainya. Inode dirujuk oleh nomor indeks,
mulai dari angka nol, yang dicadangkan untuk inode yang mewakili direktori root.

Setiap inode berisi informasi di mana data file terkait dapat ditemukan pada disk. Selain itu, sebuah inode
berisi informasi tentang pemiliknya, waktu pembuatan dan modifikasi terakhir, perlindungan, dan
sejenisnya. Akibatnya, ketika diberi nomor indeks suatu inode, dimungkinkan untuk mengakses file yang
terkait. Setiap direktori juga diimplementasikan sebagai file. Ini juga merupakan kasus untuk direktori
root, yang berisi pemetaan antara nama file dan nomor indeks inode. Dengan demikian terlihat bahwa
nomor indeks dari inode sesuai dengan pengidentifikasi node dalam grafik penamaan.

5.3.2 Resolusi Nama

Ruang nama menawarkan mekanisme yang nyaman untuk menyimpan dan mengambil informasi tentang
entitas melalui nama. Secara lebih umum, diberi nama jalur, harus dimungkinkan untuk mencari informasi
apa pun yang disimpan dalam node yang disebut dengan nama itu. Proses mencari nama disebut resolusi
nama.

Untuk menjelaskan cara kerja resolusi nama, mari kita pertimbangkan nama jalur seperti Ni <label v.label
g, ... .label; ». Resolusi nama ini dimulai pada node N dari grafik penamaan, tempat label nama} terlihat
dalam tabel direktori, dan yang mengembalikan pengidentifikasi node yang merujuk label}. Resolusi
kemudian berlanjut pada node yang diidentifikasi dengan mencari label nama-. dalam tabel direktori, dan
sebagainya. Dengan asumsi bahwa path bernama benar-benar ada, resolusi berhenti pada node terakhir
yang disebut oleh label; dengan mengembalikan konten node itu.

Pencarian nama mengembalikan pengidentifikasi node dari tempat proses resolusi nama berlanjut. Secara
khusus, perlu untuk mengakses tabel direktori dari node yang diidentifikasi. Pertimbangkan lagi grafik
penamaan untuk sistem file UNIX. Seperti disebutkan, pengidentifikasi node diimplementasikan sebagai
nomor indeks dari inode. Mengakses tabel direktori berarti bahwa inode pertama harus dibaca untuk
mengetahui di mana data aktual disimpan pada disk, dan kemudian membaca blok data yang berisi tabel
direktori.
Mekanisme Penutupan

Resolusi nama hanya dapat terjadi jika kita tahu bagaimana dan di mana memulainya. Dalam contoh kami,
node awal diberikan, dan kami menganggap kami memiliki akses ke tabel direktori. Mengetahui
bagaimana dan di mana memulai resolusi nama biasanya disebut sebagai mekanisme penutupan. Pada
dasarnya, mekanisme penutupan berkaitan dengan pemilihan node awal dalam ruang nama dari mana
resolusi nama akan dimulai (Radia, 1989). Apa yang membuat mekanisme penutupan kadang-kadang sulit
untuk dipahami adalah bahwa mereka harus sebagian implisit dan mungkin sangat berbeda ketika
membandingkan satu sama lain.

Sebagai contoh. resolusi nama dalam grafik penamaan untuk sistem file UNIX memanfaatkan fakta bahwa
inode dari direktori root adalah inode pertama dalam disk logis yang mewakili sistem file. Byte byte
sebenarnya dihitung dari nilai-nilai di bidang lain dari superblock, bersama dengan informasi yang
dikodekan dalam sistem operasi itu sendiri pada organisasi internal superblock.

Untuk memperjelas hal ini, pertimbangkan representasi string dari nama file seperti Ihomelsteenlmbox.
Untuk mengatasi nama ini, Anda harus sudah memiliki akses ke tabel direktori dari node akar dari grafik
penamaan yang sesuai. Menjadi node akar, node itu sendiri tidak dapat dilihat kecuali diimplementasikan
sebagai node yang berbeda dalam grafik penamaan lain, katakan G. Tetapi dalam kasus itu, sudah perlu
memiliki akses ke node akar G Oleh karena itu, penyelesaian nama file mensyaratkan bahwa beberapa
mekanisme telah dilaksanakan dimana proses resolusi dapat dimulai.

Contoh yang sangat berbeda adalah penggunaan string "0031204430784". Banyak orang tidak akan tahu
apa yang harus dilakukan dengan angka-angka ini, kecuali mereka diberitahu bahwa urutannya adalah
nomor telepon. Informasi itu cukup untuk memulai proses resolusi, khususnya, dengan menekan nomor.
Sistem telepon selanjutnya melakukan sisanya.

Sebagai contoh terakhir, pertimbangkan penggunaan nama global dan lokal dalam sistem terdistribusi.
Contoh khas dari nama lokal adalah variabel lingkungan. Misalnya, dalam sistem UNIX, variabel bernama
HOME digunakan untuk merujuk ke direktori home pengguna. Setiap pengguna memiliki salinan variabel
ini sendiri, yang diinisialisasi ke nama global, seluruh sistem yang sesuai dengan direktori home pengguna.
Mekanisme penutupan yang terkait dengan variabel lingkungan memastikan bahwa nama variabel
diselesaikan dengan benar dengan mencarinya di tabel khusus pengguna.

Menghubungkan dan Memasang

Sangat terkait dengan resolusi nama adalah penggunaan alias. Alias adalah nama lain untuk entitas yang
sama. Variabel lingkungan adalah contoh alias. Dalam hal penamaan grafik, pada dasarnya ada dua cara
berbeda untuk mengimplementasikan alias. Pendekatan pertama adalah memungkinkan beberapa nama
path absolut untuk merujuk ke node yang sama dalam grafik penamaan. Pendekatan ini diilustrasikan
pada Gambar 5-9, di mana node n s dapat dirujuk oleh dua nama jalur yang berbeda. Dalam
UNIXterminology, nama path / kunci dan / homelsteen / kunci pada Gambar 5-9 disebut hard link ke node
ns.

Pendekatan kedua adalah untuk mewakili suatu entitas dengan node daun, katakan N, tetapi alih-alih
menyimpan alamat atau keadaan entitas itu, node menyimpan nama jalur absolut. Saat pertama kali
menyelesaikan nama jalur absolut yang mengarah ke N, resolusi nama akan mengembalikan nama jalur
yang disimpan di N, di mana titik itu dapat dilanjutkan dengan menyelesaikan nama jalur baru itu. Prinsip
ini sesuai dengan penggunaan tautan simbolik dalam sistem file UNIX, dan diilustrasikan pada Gambar 5-
11. Dalam contoh ini, nama path / home / steen / keys, yang merujuk ke sebuah node yang mengandung
nama path absolut / kunci, adalah tautan simbolik ke node n5.

Gambar 5-11. Konsep tautan simbolik dijelaskan dalam grafik penamaan.

Resolusi nama seperti yang dijelaskan sejauh ini terjadi sepenuhnya dalam ruang nama tunggal. Namun,
resolusi nama juga dapat digunakan untuk menggabungkan ruang nama yang berbeda secara transparan.
Mari kita pertimbangkan sistem file yang dipasang. Dalam hal model penamaan kami, sistem file yang
dipasang berhubungan dengan membiarkan node direktori menyimpan pengidentifikasi node direktori
dari ruang nama yang berbeda, yang kami sebut sebagai ruang nama asing. Node direktori yang
menyimpan pengenal node disebut titik mount. Dengan demikian, node direktori dalam ruang nama asing
disebut titik pemasangan. Biasanya, titik pemasangan adalah akar dari ruang nama. Selama resolusi nama,
titik pemasangan adalah, melihat ke atas dan resolusi berlanjut dengan mengakses tabel direktori.

Prinsip pemasangan dapat digeneralisasikan ke ruang nama lain juga. Secara khusus, yang diperlukan
adalah node direktori yang bertindak sebagai titik mount dan menyimpan semua informasi yang
diperlukan untuk mengidentifikasi dan mengakses titik pemasangan di ruang nama asing. Pendekatan ini
diikuti dalam banyak sistem file terdistribusi.

Pertimbangkan kumpulan ruang nama yang didistribusikan di berbagai mesin. Secara khusus, setiap ruang
nama diimplementasikan oleh server yang berbeda, masing-masing kemungkinan berjalan pada mesin
yang terpisah. Karena itu. jika kita ingin me-mount ruang nama asing NS 2 ke ruang nama NS 1, mungkin
perlu untuk berkomunikasi melalui jaringan dengan server NS 2, karena server itu dapat berjalan pada
mesin yang berbeda dari server untuk NS i - Untuk memasang ruang nama asing di sistem terdistribusi
memerlukan setidaknya informasi berikut :

1. Nama protokol akses.

2. Nama server.
3. Nama titik pemasangan di ruang nama asing.
Perhatikan bahwa masing-masing nama ini perlu diselesaikan. Nama protokol akses perlu diselesaikan
untuk implementasi protokol dimana komunikasi dengan server ruang nama asing dapat terjadi. Nama
server harus diselesaikan ke alamat di mana server itu dapat dihubungi. Sebagai bagian terakhir dalam
resolusi nama, nama titik pemasangan harus diselesaikan ke pengidentifikasi node di ruang nama asing.

Dalam sistem yang tidak terdistribusi, tidak satu pun dari tiga poin yang benar-benar diperlukan. Misalnya,
di UNIX, tidak ada protokol akses dan tidak ada server. Juga, nama titik pemasangan tidak perlu, karena
itu hanyalah direktori root dari ruang nama asing.

Nama titik pemasangan harus diselesaikan oleh server ruang nama asing. Namun, kami juga
membutuhkan ruang nama dan implementasi untuk protokol akses dan nama server. Satu kemungkinan
adalah untuk mewakili tiga nama yang tercantum di atas sebagai URL.

Untuk membuat masalah ini nyata, pertimbangkan situasi di mana pengguna dengan komputer laptop
ingin mengakses file yang disimpan di server file jarak jauh. Mesin klien dan server file dikonfigurasikan
dengan Sun's Network File System (NFS), yang akan kita bahas secara terperinci dalam Bab. 11. NFS adalah
sistem file terdistribusi yang dilengkapi dengan protokol yang menjelaskan dengan tepat bagaimana klien
dapat mengakses file yang disimpan pada server file NFS (jarak jauh). Secara khusus, untuk memungkinkan
NFS bekerja di Internet, klien dapat menentukan dengan pasti file mana yang ingin diakses dengan
menggunakan URL NFS, misalnya, nfs: l / flits.cs. vu.nl//homelsteen. URL ini menamai file (yang kebetulan
merupakan direktori) bernama / home / steen pada file NFS serverflits.cs. vu.nl, yang dapat diakses oleh
klien melalui protokol NFS (Shepler et aI., 2003).

Nama nfs adalah nama yang terkenal dalam arti bahwa ada kesepakatan di seluruh dunia tentang
bagaimana menafsirkan nama itu. Mengingat bahwa kami berurusan dengan URL, nama nfs akan
diselesaikan untuk implementasi protokol NFS. Nama server diselesaikan ke alamatnya menggunakan
DNS, yang dibahas di bagian selanjutnya. Seperti yang kami katakan, / home / steen diselesaikan oleh
server ruang nama asing.

Organisasi sistem file pada mesin klien sebagian ditunjukkan pada Gambar. 5-12. Direktori root memiliki
sejumlah entri yang ditentukan pengguna, termasuk subdirektori bernama Iremote. Subdirektori ini
dimaksudkan untuk menyertakan titik mount untuk ruang nama asing seperti direktori home pengguna
di Vrije Universiteit. Untuk tujuan ini, node direktori bernama Iremote / vu digunakan untuk menyimpan
URL nfs: l / flits.cs. vu.nll / homelsteen.

Sekarang perhatikan nama / remotelvulmbox. Nama ini diselesaikan dengan memulai di direktori root
pada mesin klien dan berlanjut sampai node Iremote / vu tercapai. Proses resolusi nama kemudian
dilanjutkan dengan mengembalikan URL nfs: l / flits.cs. vu.nl//homelsteen, pada gilirannya memimpin
mesin klien untuk menghubungi file server flits.cs. vu.nl melalui protokol NFS, dan untuk selanjutnya
mengakses direktori / home / steen. Resolusi nama kemudian dapat dilanjutkan dengan membaca file
bernama mbox di direktori itu, setelah itu proses resolusi berhenti.
 Gambar 5-12. Memasang ruang nama jarak jauh melalui protokol akses tertentu.

Sistem terdistribusi yang memungkinkan pemasangan sistem file jarak jauh seperti yang baru saja
dijelaskan memungkinkan mesin klien untuk, misalnya, menjalankan perintah berikut :

cd /remote/vu
Is –I

yang selanjutnya mencantumkan file dalam direktori / home / steen pada server file jarak jauh.
Keindahan dari semua ini adalah bahwa pengguna terhindar dari rincian akses aktual ke server
jarak jauh. Idealnya, hanya beberapa kerugian dalam kinerja yang terlihat dibandingkan dengan
mengakses file yang tersedia secara lokal. Akibatnya, bagi klien tampak bahwa ruang nama
berakar pada mesin lokal, dan yang berakar di / home / steen pada mesin jarak jauh, membentuk
ruang nama tunggal.

5.3.3 Implementasi Space Nama

Ruang nama membentuk jantung dari layanan penamaan, yaitu layanan yang memungkinkan
pengguna dan proses untuk menambah, menghapus, dan mencari nama. Layanan penamaan
diterapkan oleh server nama. Jika sistem terdistribusi dibatasi untuk jaringan localarea, seringkali
layak untuk mengimplementasikan layanan penamaan dengan hanya menggunakan server nama
tunggal. Namun, dalam sistem terdistribusi skala besar dengan banyak entitas, mungkin tersebar
di wilayah geografis yang luas, perlu untuk mendistribusikan implementasi ruang nama di
beberapa server nama.

Beri Nama Distribusi Ruang

Ruang nama untuk skala besar, mungkin sistem terdistribusi di seluruh dunia, biasanya diatur
secara hierarkis. Seperti sebelumnya, anggap ruang nama tersebut hanya memiliki satu node
akar tunggal. Untuk secara efektif mengimplementasikan ruang nama seperti itu, lebih mudah
untuk mempartisi menjadi lapisan logis. Cheriton dan Mann (1989) membedakan tiga lapisan
berikut.

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

Lapisan administrasi dibentuk oleh node direktori yang bersama-sama dikelola dalam satu
organisasi. Fitur karakteristik dari node direktori di lapisan administrasi adalah bahwa mereka
mewakili kelompok entitas yang termasuk dalam organisasi atau unit administrasi yang sama.
Misalnya, mungkin ada node direktori untuk setiap departemen dalam suatu organisasi, atau
node direktori tempat semua host dapat ditemukan. Node direktori lain dapat digunakan sebagai
titik awal untuk memberi nama semua pengguna, dan sebagainya. Node di lapisan administrasi
relatif stabil, meskipun perubahan umumnya terjadi lebih sering daripada node di lapisan global.

Akhirnya, lapisan manajerial terdiri dari node yang biasanya dapat berubah secara teratur.
Misalnya, node yang mewakili host di jaringan lokal milik lapisan ini. Untuk alasan yang sama,
layer tersebut mencakup node yang mewakili file bersama seperti yang untuk perpustakaan atau
binari. Kelas node penting lainnya termasuk yang mewakili direktori dan file yang ditentukan
pengguna. Berbeda dengan lapisan global dan administrasi, node di lapisan manajerial dikelola
tidak hanya oleh administrator sistem, tetapi juga oleh pengguna akhir individu dari sistem
terdistribusi.

Untuk membuat masalah lebih konkret, Gbr. 5-13 memperlihatkan contoh partisi bagian ruang
nama DNS, termasuk nama file dalam organisasi yang dapat diakses melalui Internet, misalnya,
halaman Web dan file yang dapat ditransfer. Ruang nama dibagi menjadi bagian yang tidak
tumpang tindih, yang disebut zona dalam DNS (Mockapetris, 1987). Zona adalah bagian dari
ruang nama yang diimplementasikan oleh server nama yang terpisah. Beberapa zona ini
diilustrasikan pada Gambar. 5 13.

Jika kita melihat ketersediaan dan kinerja, server nama di setiap lapisan harus memenuhi
persyaratan yang berbeda. Ketersediaan tinggi sangat penting untuk server nama di lapisan
global. Jika server nama gagal, sebagian besar ruang nama tidak dapat dijangkau karena resolusi
nama tidak dapat dilanjutkan di luar server yang gagal.

Performanya agak halus. Karena tingkat perubahan node yang rendah di lapisan global, hasil
operasi pencarian umumnya tetap berlaku untuk waktu yang lama. Akibatnya, hasil tersebut
dapat di-cache secara efektif (mis., Disimpan secara lokal) oleh klien.
 Gambar 5-13. Contoh partisi ruang nama DNS, termasuk file yang dapat diakses Internet, menjadi tiga
lapisan.

Lain kali operasi pencarian yang sama dilakukan, hasilnya dapat diambil dari cache klien alih-alih
membiarkan server nama mengembalikan hasilnya. Akibatnya, server nama di lapisan global
tidak harus merespons dengan cepat ke permintaan pencarian tunggal. Di sisi lain, throughput
mungkin penting, terutama dalam sistem skala besar dengan jutaan pengguna.

Persyaratan ketersediaan dan kinerja untuk server nama di lapisan global dapat dipenuhi dengan
mereplikasi server, dalam kombinasi dengan caching sisi klien. Seperti yang kita bahas dalam Bab.
7, pembaruan pada lapisan ini umumnya tidak harus berlaku segera, membuatnya lebih mudah
untuk menjaga replika konsisten.

Ketersediaan untuk server nama di lapisan administrasi terutama penting untuk klien di
organisasi yang sama dengan server nama. Jika server nama gagal, banyak sumber daya dalam
organisasi menjadi tidak dapat dijangkau karena tidak dapat dicari. Di sisi lain, mungkin kurang
penting bahwa sumber daya di suatu organisasi sementara tidak dapat dijangkau oleh pengguna
di luar organisasi itu.

Sehubungan dengan kinerja, server nama di lapisan administrasi memiliki karakteristik yang sama
dengan yang ada di lapisan global. Karena perubahan pada node tidak sering terjadi, hasil
pencarian caching bisa sangat efektif, membuat kinerja menjadi kurang penting. Namun, berbeda
dengan lapisan global, semua administrasi harus berhati-hati bahwa hasil pencarian
dikembalikan dalam beberapa milidetik, baik langsung dari server atau dari cache lokal klien.
Demikian juga, pembaruan umumnya harus diproses lebih cepat daripada yang ada di lapisan
global. Misalnya, tidak dapat diterima bahwa akun untuk pengguna baru memerlukan waktu
berjam-jam untuk menjadi efektif.

Persyaratan ini seringkali dapat dipenuhi dengan menggunakan mesin berperforma tinggi untuk
menjalankan server nama. Selain itu, caching sisi klien harus diterapkan, dikombinasikan dengan
replikasi untuk meningkatkan ketersediaan keseluruhan.

Persyaratan ketersediaan untuk server nama di tingkat manajerial umumnya kurang menuntut.
Secara khusus, seringkali cukup untuk menggunakan mesin tunggal (khusus) untuk menjalankan
server nama dengan risiko tidak tersedianya sementara. Namun, kinerja sangat penting.
Pengguna mengharapkan operasi segera dilakukan. Karena pembaruan terjadi secara teratur,
caching di sisi klien sering kali kurang efektif, kecuali jika tindakan khusus diambil, yang kami
bahas dalam Bab. 7.

Gambar 5-14. Perbandingan antara server nama untuk mengimplementasikan node dari ruang nama
skala besar yang dipartisi ke dalam lapisan global, lapisan administrasi, dan lapisan manajerial.

Perbandingan antara server nama pada lapisan yang berbeda ditunjukkan pada Gambar. 5-14.
Dalam sistem terdistribusi, server nama di lapisan global dan administrasi adalah yang paling sulit
diimplementasikan. Kesulitan disebabkan oleh replikasi dan caching, yang diperlukan untuk
ketersediaan dan kinerja, tetapi yang juga menimbulkan masalah konsistensi. Beberapa masalah
diperburuk oleh fakta bahwa cache dan replika tersebar di jaringan area luas, yang menyebabkan
penundaan komunikasi yang lama sehingga membuat sinkronisasi menjadi lebih sulit. Replikasi
dan caching dibahas secara luas dalam Bab. 7.

Implementasi Resolusi Nama

Distribusi ruang nama di beberapa server nama mempengaruhi implementasi resolusi nama.
Untuk menjelaskan implementasi resolusi nama dalam layanan nama skala besar, kami
menganggap untuk saat ini bahwa server nama tidak direplikasi dan bahwa tidak ada cache sisi
klien yang digunakan. Setiap klien memiliki akses ke penyelesai nama lokal, yang bertanggung
jawab untuk memastikan bahwa proses resolusi nama dilakukan. Mengacu pada Gambar 5-13,
asumsikan nama path (absolut)

root: «nl, VU, CS, ftp, pub, globe, index.html>

harus diselesaikan. Menggunakan notasi URL, nama jalur ini akan sesuai dengan ftp: //ftp.cs.
vu.nl/pub/globe/index.html. Sekarang ada dua cara untuk mengimplementasikan resolusi nama.

Dalam resolusi nama berulang, pemecah nama menyerahkan nama lengkap ke server nama root.
Diasumsikan bahwa alamat di mana server root dapat dihubungi sudah dikenal luas. Root server
akan menyelesaikan nama jalur sejauh mungkin, dan mengembalikan hasilnya ke klien. Dalam
contoh kami, server root hanya dapat menyelesaikan label nl, yang akan mengembalikan alamat
server nama terkait.

Pada titik itu. klien melewati nama path yang tersisa (yaitu, nl: <VU, cs, jtp, pub, globe,
index.html> ke server nama itu. Server ini hanya dapat menyelesaikan label VU, dan
mengembalikan alamat server nama yang terkait , bersama dengan sisa nama path vu: <cs, ftp,
pub, globe, index.html>.

Penyelesai nama klien kemudian akan menghubungi server nama berikutnya ini, yang merespons
dengan menyelesaikan label cs, dan kemudian alsoftp, mengembalikan alamat server FTP
bersama dengan nama path ftp <pub, globe, index.html>. Klien kemudian menghubungi server
FTP, memintanya untuk menyelesaikan bagian terakhir dari nama jalur asli. Server FTP
selanjutnya akan menyelesaikan pub label. globe, dan index.html, dan transfer file yang diminta
(dalam hal ini menggunakan FTP). Proses resolusi nama berulang ini ditunjukkan pada Gambar.
5-15. (Notasi # <cs> digunakan untuk menunjukkan alamat server yang bertanggung jawab untuk
menangani node yang dirujuk oleh <cs>.)
 Gambar 5-15. Prinsip resolusi nama berulang.

Dalam praktiknya, langkah terakhir, yaitu menghubungi server FTP dan memintanya untuk
mentransfer file dengan nama jalur ftp i-cpub, globe, index.himl », dilakukan secara terpisah oleh
proses klien. Dengan kata lain, klien biasanya hanya menyerahkan root nama path: «nl, VU, CS,
ftp> ke resolver nama, dari mana ia akan mengharapkan alamat di mana ia dapat menghubungi
server FTP, seperti juga ditunjukkan pada Gambar 5-15.

Alternatif untuk resolusi nama berulang adalah dengan menggunakan rekursi selama resolusi
nama. Alih-alih mengembalikan setiap hasil antara kembali ke pemecah nama klien, dengan
resolusi nama rekursif, server nama meneruskan hasilnya ke server nama berikutnya yang
ditemukannya. Jadi, misalnya, ketika server nama root menemukan alamat server nama yang
mengimplementasikan node bernama nl, ia meminta server nama itu untuk menyelesaikan nama
jalur nl: <vu, CS, ftp, pub, globe, index.html> . Menggunakan resolusi nama rekursif juga, server
berikutnya ini akan menyelesaikan jalur lengkap dan akhirnya mengembalikan file index.html ke
server root, yang, pada gilirannya, akan meneruskan file itu ke pemecah nama klien.

Resolusi nama rekursif ditunjukkan pada Gambar 5-16. Seperti dalam resolusi nama berulang,
langkah resolusi terakhir (menghubungi server FTP dan memintanya untuk mentransfer file yang
ditunjukkan) umumnya dilakukan sebagai proses terpisah oleh klien.
 Gambar 5-16. Prinsip resolusi nama rekursif.

Kelemahan utama dari resolusi nama rekursif adalah bahwa ia menempatkan permintaan kinerja
yang lebih tinggi pada setiap server nama. Pada dasarnya, server nama diperlukan untuk
menangani resolusi lengkap dari nama jalur, meskipun dapat bekerja sama dengan server nama
lain. Beban tambahan ini umumnya sangat tinggi sehingga server nama di lapisan global ruang
nama hanya mendukung resolusi nama iteratif.

Ada dua keuntungan penting untuk resolusi nama rekursif. Keuntungan pertama adalah bahwa
hasil caching lebih efektif dibandingkan dengan resolusi nama berulang. Keuntungan kedua
adalah bahwa biaya komunikasi dapat dikurangi. Untuk menjelaskan keuntungan ini, asumsikan
bahwa resolver nama klien akan menerima nama path yang hanya merujuk ke node di lapisan
global atau administrasi ruang nama. Untuk menyelesaikan bagian dari nama jalur yang sesuai
dengan node di lapisan manajerial, klien akan secara terpisah menghubungi server nama yang
dikembalikan oleh penyelesai namanya, seperti yang kita bahas di atas.

Resolusi nama rekursif memungkinkan setiap server nama untuk secara bertahap mempelajari
alamat masing-masing server nama yang bertanggung jawab untuk mengimplementasikan node
tingkat bawah. Akibatnya, caching dapat digunakan secara efektif untuk meningkatkan kinerja.
Misalnya, ketika server root diminta untuk menyelesaikan root nama path: <nl, vu, cs, ftp>, ia
akhirnya akan mendapatkan alamat server nama yang mengimplementasikan node yang dirujuk
oleh nama path itu. Untuk sampai ke titik itu, server nama untuk node nl harus mencari alamat
server nama untuk node vu, sedangkan yang terakhir harus mencari alamat server nama yang
menangani node cs.

Karena perubahan node di lapisan global dan administrasi tidak sering terjadi, root name server
dapat secara efektif men-cache alamat yang dikembalikan. Selain itu, karena alamat tersebut
juga dikembalikan, dengan rekursi, ke server nama yang bertanggung jawab untuk
mengimplementasikan vu node dan ke yang mengimplementasikan node nl, mungkin juga akan
di-cache di server-server itu juga.

Demikian juga, hasil pencarian nama perantara juga dapat dikembalikan dan di-cache. Sebagai
contoh, server untuk node nl harus mencari alamat server vu node. Alamat itu dapat
dikembalikan ke server root ketika server nl mengembalikan hasil pencarian nama asli. Gambaran
lengkap dari proses resolusi, dan hasil yang dapat di-cache oleh setiap server nama ditunjukkan
pada Gambar. 5-17.

Gambar 5-17. Resolusi nama rekursif dari «nl, l'U, CS. jtp>. Beri nama server cache hasil sementara
untuk pencarian berikutnya.

Manfaat utama dari pendekatan ini adalah pada akhirnya. operasi pencarian dapat ditangani
dengan cukup efisien. Sebagai contoh, misalkan klien lain kemudian meminta resolusi root nama
path: <nl, Vii, cs, flits>. Nama ini diteruskan ke root, yang dapat segera meneruskannya ke server
nama untuk node cs, dan memintanya untuk menyelesaikan nama jalur yang tersisa cs: <jlits>.

Dengan resolusi nama berulang, caching harus dibatasi untuk penyelesai nama klien. Akibatnya,
jika klien A meminta resolusi nama, dan klien lain B kemudian meminta nama yang sama untuk
diselesaikan, resolusi nama harus melewati server nama yang sama seperti yang dilakukan untuk
klien A. Sebagai kompromi, banyak organisasi menggunakan server nama lokal dan menengah
yang dibagikan oleh semua klien. Server nama lokal ini menangani semua permintaan penamaan
dan hasil cache. Server perantara semacam itu juga nyaman dari sudut pandang manajemen.
Sebagai contoh, hanya server yang perlu tahu di mana server nama root berada; mesin lain tidak
memerlukan informasi ini.

Keuntungan kedua dari resolusi nama rekursif adalah bahwa seringkali lebih murah sehubungan
dengan komunikasi. Sekali lagi, pertimbangkan resolusi root nama path: <nl, vu, cs, ftp> dan
anggap klien berada di San Francisco. Dengan asumsi bahwa klien mengetahui alamat server
untuk node nl, dengan resolusi nama rekursif, komunikasi mengikuti rute dari host klien di San
Francisco ke server nl di Belanda, ditunjukkan sebagai R 1 pada Gambar 5 18. Dari Oleh karena
itu, komunikasi selanjutnya dibutuhkan antara server nl dan server nama Vrije Universiteit di
kampus universitas di Amsterdam, Belanda. Komunikasi ini ditampilkan sebagai R 2. Akhirnya,
komunikasi diperlukan antara server vu dan server nama di Departemen Ilmu Komputer,
ditampilkan sebagai R 3. Rute untuk balasannya sama, tetapi dalam arah yang berlawanan. Jelas,
biaya komunikasi ditentukan oleh pertukaran pesan antara host klien dan server nl.

Sebaliknya, dengan resolusi nama berulang, host klien harus berkomunikasi secara terpisah
dengan server nl, server vu, dan server cs, di mana total biaya mungkin kira-kira tiga kali lipat dari
resolusi nama rekursif. Panah pada Gambar. 5-18 berlabel / 1, / 2, dan / 3 menunjukkan jalur
komunikasi untuk resolusi nama berulang.

5.3.4 Contoh : Sistem Nama Domain

Salah satu layanan penamaan terdistribusi terbesar yang digunakan saat ini adalah Internet
Domain Name System (DNS). DNS terutama digunakan untuk mencari alamat IP host dan server
mail. Di halaman-halaman berikut, kami berkonsentrasi pada organisasi ruang nama DNS, dan
informasi yang disimpan dalam node-node tersebut. Kami juga memperhatikan implementasi
DNS yang sebenarnya. Informasi lebih lanjut dapat ditemukan di Mockapetris (1987) dan Albitz
dan Liu (2001). Penilaian DNS baru-baru ini, terutama mengenai apakah masih sesuai dengan
kebutuhan Internet saat ini, dapat ditemukan dalam Levien (2005). Dari laporan ini, orang dapat
menarik kenodean yang agak mengejutkan bahwa bahkan setelah lebih dari 30 tahun, DNS tidak
memberikan indikasi bahwa itu perlu diganti. Kami berpendapat bahwa penyebab utama terletak
pada pemahaman mendalam desainer tentang bagaimana menjaga hal-hal sederhana. Praktek
di bidang lain dari sistem terdistribusi menunjukkan bahwa tidak banyak yang berbakat dengan
pemahaman seperti itu.

Gambar 5-18. Perbandingan antara resolusi nama rekursif dan iteratif sehubungan dengan biaya
komunikasi.

Ruang Nama DNS

Ruang nama DNS diatur secara hierarkis sebagai pohon yang di-root. Label adalah string case-
insensitive yang terdiri dari karakter alfanumerik. Label memiliki panjang maksimum 63 karakter;
panjang nama jalur lengkap dibatasi hingga 255 karakter. Representasi string dari nama path
terdiri dari daftar labelnya, dimulai dengan yang paling kanan, dan memisahkan label dengan
sebuah titik (H. "). Root diwakili oleh sebuah titik. Jadi, misalnya, path name root: <nl, VU, cs,
flits>, diwakili oleh string flits.cs. vu.nl., yang mencakup titik paling kanan untuk menunjukkan
node root. Kami biasanya menghilangkan titik ini agar mudah dibaca.

Karena setiap node dalam ruang nama DNS memiliki tepat satu tepi masuk (dengan pengecualian
dari node akar, yang tidak memiliki tepi masuk), label yang melekat pada tepi masuk node juga
digunakan sebagai nama untuk node tersebut. Subtree disebut domain; nama jalur ke node akar
disebut nama domain. Perhatikan bahwa, sama seperti nama jalur, nama domain dapat berupa
absolut atau relatif. Isi node dibentuk oleh kumpulan catatan sumber daya. Ada berbagai jenis
catatan sumber daya. Yang utama ditunjukkan pada Gambar. 5-19.

Node dalam ruang nama DNS sering kali akan mewakili beberapa entitas secara bersamaan.
Misalnya, nama domain seperti vu.nl digunakan untuk mewakili domain dan zona. Dalam hal ini,
domain diimplementasikan melalui beberapa zona (yang tidak tumpang tindih).

Catatan sumber daya SOA (awal otoritas) berisi informasi seperti alamat email administrator
sistem yang bertanggung jawab atas zona yang diwakili. nama host tempat data pada zona dapat
diambil, dan sebagainya.

Gambar 5-19. Tipe paling penting dari catatan sumber daya yang membentuk konten node dalam ruang
nama DNS.
Catatan A (alamat), mewakili host tertentu di Internet. Catatan A berisi alamat IP untuk host
tersebut untuk memungkinkan komunikasi. Jika sebuah host memiliki beberapa alamat IP,
seperti halnya dengan mesin multi-homed, node akan berisi catatan A untuk setiap alamat.

Jenis rekaman lain adalah catatan MX (pertukaran email), yang seperti tautan simbolis ke node
yang mewakili server email. Misalnya, node yang mewakili domain cs.vu.nl memiliki catatan MX
yang berisi nama zephyr.cs.vu.nl, yang merujuk ke server mail. Server itu akan menangani semua
surat masuk yang ditujukan kepada pengguna di cs. domain vu.nl. Mungkin ada beberapa catatan
MX yang disimpan dalam sebuah node.

Terkait dengan catatan MX adalah catatan SRV, yang berisi nama server untuk layanan tertentu.
Catatan SRV didefinisikan dalam Gulbrandsen (2000). Layanan itu sendiri diidentifikasi dengan
menggunakan nama bersama dengan nama protokol. Misalnya, server Web di cs. domain vu.nl
dapat dinamai dengan menggunakan catatan SRV seperti .Jutp.ctcp.cs.vu.nl, Catatan ini
kemudian merujuk ke nama sebenarnya dari server (yang soling.cs. vu.nl). Keuntungan penting
dari catatan SRV adalah bahwa klien tidak perlu lagi mengetahui nama DNS dari host yang
menyediakan layanan tertentu. Sebagai gantinya, hanya nama layanan yang perlu distandarisasi,
setelah itu host penyedia dapat dicari.

Node yang mewakili zona, berisi satu atau lebih catatan NS (server nama). Seperti catatan MX,
catatan NS berisi nama server nama yang mengimplementasikan zona yang diwakili oleh node.
Pada prinsipnya, setiap node dalam ruang nama dapat menyimpan catatan NS yang merujuk ke
server nama yang mengimplementasikannya. Namun, seperti yang kita diskusikan di bawah ini,
implementasi ruang nama DNS sedemikian rupa sehingga hanya node yang mewakili zona yang
perlu menyimpan catatan NS.

DNS membedakan alias dari apa yang disebut nama kanonik. Setiap host diasumsikan memiliki
nama kanonik, atau utama. Alias diimplementasikan melalui node yang menyimpan catatan
CNAME yang berisi nama kanonik suatu host. Nama node yang menyimpan catatan seperti itu
sama dengan tautan simbolik, seperti yang ditunjukkan pada Gambar. 5- J J.

DNS memelihara pemetaan terbalik dari alamat IP ke nama host dengan menggunakan catatan
PTR (pointer). Untuk mengakomodasi pencarian nama host ketika hanya diberikan alamat IP, DNS
mempertahankan domain bernama in-addr.arpa, yang berisi node yang mewakili host Internet
dan yang dinamai dengan alamat IP host yang diwakili. Misalnya, host tVww.cs. \ 'U.nl memiliki
alamat IP 130.37.20.20. DNS membuat node bernama 20.20.37.130.in-addr.mpa, yang
digunakan untuk menyimpan nama kanonik host tersebut (yang kebetulan soling.cs.vu.nl i dalam
catatan PTR.

Dua tipe catatan terakhir adalah catatan HINFO dan catatan TXT. Catatan HINFO (info host)
digunakan untuk menyimpan informasi tambahan pada host seperti jenis mesin dan sistem
operasinya. Dengan cara yang serupa, catatan TXT digunakan untuk semua jenis data lain yang
menurut pengguna berguna untuk disimpan tentang entitas yang diwakili oleh node.

Implementasi DNS

Intinya, ruang nama DNS dapat dibagi menjadi lapisan global dan lapisan administrasi seperti
yang ditunjukkan pada Gambar. 5-13. Lapisan manajerial, yang umumnya dibentuk oleh sistem
file lokal, secara formal bukan bagian dari DNS dan karenanya juga tidak dikelola olehnya.

Setiap zona diimplementasikan oleh server nama, yang secara virtual selalu direplikasi untuk
ketersediaan. Pembaruan untuk suatu zona biasanya ditangani oleh server nama utama.
Pembaruan terjadi dengan memodifikasi database DNS lokal ke server utama. Server nama
sekunder tidak mengakses database secara langsung, tetapi, sebaliknya, meminta server utama
untuk mentransfer kontennya. Yang terakhir disebut transfer zona dalam terminologi DNS.

Database DNS diimplementasikan sebagai kumpulan file (kecil), yang terpenting adalah berisi
semua catatan sumber daya untuk semua node di zona tertentu. Pendekatan ini memungkinkan
node untuk secara sederhana diidentifikasi dengan menggunakan nama domain mereka, di mana
gagasan pengidentifikasi node dikurangi menjadi indeks (implisit) ke dalam file.

Untuk lebih memahami masalah implementasi ini, Gbr. 5-20 memperlihatkan sebagian kecil file
yang berisi sebagian besar informasi untuk domain cs.vu.nl (file tersebut telah diedit untuk
kesederhanaan). File menunjukkan isi beberapa node yang merupakan bagian dari cs. vu.nl
domain, di mana setiap node diidentifikasi dengan menggunakan nama domainnya.

Node cs.vu.nl mewakili domain dan juga zona. Catatan sumber daya SOA-nya berisi informasi
spesifik tentang validitas file ini. yang tidak akan menjadi perhatian kita lebih lanjut. Ada empat
server nama untuk zona ini, dirujuk oleh nama host kanonik mereka di catatan NS. Catatan TXT
digunakan untuk memberikan beberapa informasi tambahan tentang zona ini, tetapi tidak dapat
secara otomatis diproses oleh server nama apa pun. Selain itu, ada satu server surat yang dapat
menangani surat masuk yang ditujukan kepada pengguna di domain ini. Nomor sebelum nama
server surat menentukan prioritas pemilihan. Server email pengirim harus selalu berusaha
terlebih dahulu untuk menghubungi server email dengan nomor terendah.
Gambar 5-20. Kutipan dari database DNS untuk zona cs. vU.1l1.
Host star.cs. vu.nl beroperasi sebagai server nama untuk zona ini. Server nama sangat penting
untuk layanan penamaan apa pun. Apa yang dapat dilihat tentang server nama ini adalah bahwa
ketahanan tambahan telah dibuat dengan memberikan dua antarmuka jaringan yang terpisah,
masing-masing diwakili oleh catatan sumber daya A yang terpisah. Dengan cara ini, efek dari
tautan jaringan yang rusak dapat sedikit dikurangi karena server akan tetap dapat diakses.

Empat baris berikutnya (untuk zephyr.cs. Vu.nl) memberikan informasi yang diperlukan tentang
salah satu server surat departemen. Perhatikan bahwa server email ini juga didukung oleh server
email lain, yang jalurnya adalah tornado.cs. vu.nl ,.

Enam baris berikutnya menunjukkan konfigurasi khas di mana server Web departemen, serta
server FTP departemen diimplementasikan oleh satu mesin, yang disebut soling. cs. vu. nl.
Dengan mengeksekusi kedua server pada mesin yang sama (dan pada dasarnya menggunakan
mesin itu hanya untuk layanan Internet dan bukan yang lainnya), manajemen sistem menjadi
lebih mudah. Sebagai contoh, kedua server akan memiliki pandangan yang sama tentang sistem
file, dan untuk efisiensi, bagian dari sistem file dapat diimplementasikan pada soling.cs.vu.nl,
pendekatan ini sering diterapkan dalam kasus WWW dan layanan FTP.

Dua baris berikut menunjukkan informasi pada salah satu cluster server lama departemen. Dalam
hal ini, ia memberi tahu kita bahwa alamat 130.37.198.0 dikaitkan dengan nama host vucs-
dasl.cs.vu.nl,

Empat baris berikutnya menunjukkan informasi tentang dua printer utama yang terhubung ke
jaringan lokal. Perhatikan bahwa alamat dalam kisaran 192.168.0.0 hingga 192.168.255.255
bersifat pribadi: alamat tersebut hanya dapat diakses dari dalam jaringan lokal dan tidak dapat
diakses dari host Internet sewenang-wenang.

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

Implementasi DNS Terdesentralisasi

Implementasi DNS yang kami jelaskan sejauh ini adalah yang standar. Ini mengikuti hierarki
server dengan 13 server root terkenal dan berakhir pada jutaan server di daun. Pengamatan
penting adalah bahwa node tingkat yang lebih tinggi menerima lebih banyak permintaan
daripada node tingkat yang lebih rendah. Hanya dengan men-caching ikatan nama-alamat dari
tingkat yang lebih tinggi ini adalah mungkin untuk menghindari mengirim permintaan kepada
mereka dan dengan demikian membanjiri mereka.

Masalah skalabilitas ini dapat dihindari selain dengan solusi yang sepenuhnya terdesentralisasi.
Secara khusus, kita dapat menghitung hash dari nama DNS, dan kemudian menganggap hash itu
sebagai nilai kunci untuk dilihat dalam tabel hash terdistribusi atau layanan lokasi hierarkis
dengan node root yang sepenuhnya dipartisi. Kelemahan yang jelas dari pendekatan ini adalah
kita kehilangan struktur nama aslinya. Kehilangan ini dapat mencegah implementasi yang efisien,
misalnya, menemukan anak-anak di domain tertentu.

Di sisi lain, ada banyak keuntungan untuk memetakan DNS ke implementasi berbasis DHT,
terutama skalabilitasnya. Seperti yang dikemukakan oleh Walfish et al. (2004), ketika ada
kebutuhan untuk banyak nama, menggunakan pengidentifikasi sebagai cara semantik-bebas
mengakses data akan memungkinkan sistem yang berbeda untuk menggunakan sistem
penamaan tunggal. Alasannya sederhana: saat ini sudah dipahami dengan baik bagaimana
koleksi besar nama (flat) dapat didukung secara efisien. Yang perlu dilakukan adalah menjaga
pemetaan informasi pengenal-ke-nama, di mana dalam hal ini nama dapat berasal dari ruang
DNS, menjadi URL, dan sebagainya. Menggunakan pengidentifikasi dapat dibuat lebih mudah
dengan membiarkan pengguna atau organisasi menggunakan ruang nama lokal yang ketat. Yang
terakhir ini sepenuhnya analog dengan mempertahankan pengaturan variabel lingkungan pribadi
pada komputer.

Memetakan DNS ke sistem peer-to-peer berbasis DHT telah dieksplorasi dalam CoDoNS
(Ramasubramanian dan Sirer, 2004a). Mereka menggunakan sistem berbasis DHT di mana
awalan kunci digunakan untuk merutekan ke sebuah node. Untuk menjelaskan, pertimbangkan
kasus bahwa setiap digit dari pengenal diambil dari set {0, ..., b-l}, di mana b adalah angka dasar.
Sebagai contoh, dalam Chord, b = 2. Jika kita mengasumsikan bahwa b = 4, maka pertimbangkan
sebuah node yang pengenalnya 3210. Dalam sistem mereka, node ini diasumsikan menyimpan
tabel routing node yang memiliki pengidentifikasi berikut :

no: node yang pengenalnya memiliki awalan 0

n 1: node yang pengenalnya memiliki awalan 1

n 2: node yang pengenalnya memiliki awalan 2

n 30: node yang pengenalnya memiliki awalan 30

n 31: sebuah node yang pengenalnya memiliki awalan 31

n 33: sebuah node yang pengenalnya memiliki awalan 33

n 320: sebuah node yang pengenalnya memiliki awalan320

n 322: node yang pengenalnya memiliki awalan 322

n 323: node yang pengenalnya memiliki awalan 323

Node 3210 bertanggung jawab untuk menangani kunci yang memiliki awalan 321. Jika ia
menerima permintaan pencarian untuk kunci 3123, itu akan meneruskannya ke node 113b yang,
pada gilirannya, akan melihat apakah perlu meneruskannya ke node yang pengenalnya memiliki
awalan 312 (Kita harus mencatat bahwa setiap node memelihara dua daftar lain yang dapat
digunakan untuk routing jika melewatkan entri dalam tabel routingnya.) Detail dari pendekatan
ini dapat ditemukan untuk Pastry (Rowstron dan Druschel, 2001) dan Tapestry (Zhao et al., 2004).

Kembali ke CoDoNS, node yang bertanggung jawab untuk kunci k menyimpan catatan sumber
daya DNS yang terkait dengan nama domain yang hash ke k. Bagian yang menarik,
bagaimanapun, adalah bahwa CoDoNS berusaha untuk meminimalkan jumlah hop dalam
merutekan permintaan dengan mereplikasi catatan sumber daya. Strategi prinsipnya sederhana:
node 3210 akan mereplikasi kontennya ke node yang memiliki awalan 321. Replikasi seperti itu
akan mengurangi setiap jalur routing yang berakhir pada node 3210 dengan satu hop. Tentu saja,
replikasi ini dapat diterapkan lagi ke semua node yang memiliki awalan 32, dan seterusnya.

Ketika catatan DNS direplikasi ke semua node dengan awalan yang cocok, dikatakan direplikasi
di level i. Perhatikan bahwa catatan yang direplikasi pada level i (umumnya) mengharuskan saya
mencari langkah-langkah untuk ditemukan. Namun, ada trade-off antara tingkat replikasi dan
penggunaan sumber daya jaringan dan node. Apa yang dilakukan CoDoNS adalah meniru sejauh
bahwa latensi pencarian agregat yang dihasilkan kurang dari konstanta yang diberikan C.

Lebih khusus lagi, pikirkan sejenak tentang distribusi frekuensi kueri. Bayangkan peringkat
pencarian kueri dengan seberapa sering kunci tertentu diminta menempatkan kunci yang paling
diminta di posisi pertama. Distribusi pencarian dikatakan seperti Zipf jika frekuensi item peringkat
ke-n sebanding dengan l / na, dengan hampir 1. George Zipf adalah ahli bahasa Harvard yang
menemukan distribusi ini ketika mempelajari penggunaan kata. frekuensi dalam bahasa alami.
Namun, ternyata, hal itu juga berlaku di antara banyak hal lain, pada populasi kota, ukuran gempa
bumi, distribusi berpenghasilan tinggi, pendapatan korporasi, dan, mungkin tidak lagi
mengejutkan, permintaan DNS (Jung et al., 2002 ).

Sekarang, jika Xi adalah sebagian kecil dari catatan paling populer yang akan di -licep di tingkat i,
maka Ramasubramanian dan Sirer (2004b) menunjukkan bahwa Xi dapat diekspresikan dengan
rumus berikut (untuk tujuan kita, hanya fakta bahwa rumus ini ada sebenarnya adalah penting;
kita akan melihat bagaimana menggunakannya segera) :

di mana N adalah jumlah node dalam jaringan dan a adalah parameter dalam distribusi Zipf.

Formula ini memungkinkan untuk mengambil keputusan berdasarkan informasi tentang catatan
DNS mana yang harus direplikasi. Untuk membuat masalah menjadi konkret, pertimbangkan
kasus yang b = 32 dan a = 0,9. Kemudian, dalam jaringan dengan 10.000 node dan 1.000.000
catatan DNS, dan mencoba mencapai rata-rata C = 1 hop hanya ketika melakukan pencarian, kita
akan memiliki Xo = 0,0000701674, yang berarti bahwa hanya 70 catatan DNS paling populer yang
harus direplikasi dimana mana. Demikian juga, dengan x I = 0,00330605, 3306 catatan paling
populer berikutnya harus direplikasi di level 1. Tentu saja, diperlukan bahwa Xi <1. Dalam contoh
ini, Xl = 0,155769 dan X3> 1, sehingga hanya yang paling berikutnya 155.769 catatan populer
dapat direplikasi dan yang lainnya atau tidak. Namun demikian, secara rata-rata, satu hop cukup
untuk menemukan catatan DNS yang diminta.

S.4 PENAMBAHAN BERBASIS ATTRIBUT

Nama datar dan terstruktur umumnya memberikan cara yang unik dan independen untuk
merujuk entitas. Selain itu, nama terstruktur telah sebagian dirancang untuk memberikan cara
yang ramah manusia untuk menamai entitas sehingga mereka dapat diakses dengan mudah.
Dalam kebanyakan kasus, diasumsikan bahwa nama hanya merujuk pada satu entitas. Namun,
independensi lokasi dan keramahan manusia bukan satu-satunya kriteria untuk penamaan
entitas. Secara khusus, karena semakin banyak informasi tersedia, penting untuk secara efektif
mencari entitas. Pendekatan ini mensyaratkan bahwa pengguna hanya dapat memberikan
deskripsi tentang apa yang ia cari.

Ada banyak cara di mana deskripsi dapat diberikan, tetapi yang populer di sistem terdistribusi
adalah untuk menggambarkan suatu entitas dalam hal (atribut, nilai) pasangan, umumnya
disebut sebagai penamaan berbasis atribut. Dalam pendekatan ini, suatu entitas diasumsikan
memiliki koleksi atribut yang terkait. Setiap atribut mengatakan sesuatu tentang entitas itu.
Dengan menentukan nilai mana yang harus dimiliki atribut tertentu, pengguna pada dasarnya
membatasi sekumpulan entitas yang ia minati. Terserah sistem penamaan untuk mengembalikan
satu atau lebih entitas yang memenuhi deskripsi pengguna. Pada bagian ini kita akan melihat
lebih dekat pada sistem penamaan berbasis atribut.