3.

SERVER Mari kita sekarang melihat lebih dekat pada organisasi server. Pada halaman berikut, pertama kita berkonsentrasi pada sejumlah isu desain umum untuk server, yang akan dilanjutkan dengan diskusi server objek. Objek server penting karena dari blok bangunan untuk melaksanakan obyek terdistribusi. 3.3.1 General Design Issues Server adalah sebuah proses impiementing layanan specifie atas nama koleksi clients.pada dasarnya, setiap server diatur dengan cara yang sama itu menunggu permintaan yang masuk dari clien dan subsequndy memastikan bahwa permintaan tersebut diurus, setelah itu itu menunggu permintaan masuk berikutnya. Ada beberapa cara ke server organizer. Dalam kasus iteratif server, server itu sendiri menangani permintaan dan, jika perlu, mengembalikan respon ke klien meminta. Sebuah server konkuren tidak menangani permintaan itu sendiri , tapi lolos ke thread terpisah atau proses lain, setelah itu segera menunggu untuk requet masuk berikutnya. Sebuah server multithreaded adalah contoh dari sebuah server bersamaan. Implementasi alternatif dari server bersamaan adalah untuk garpu proses baru untuk cach permintaan yang masuk baru. Pendekatan ini diikuti di banyak sistem UNIX. Thread atau proses yang menangani permintaan bertanggung jawab untuk mengembalikan respon ke klien requsting . Masalah lainnya adalah di mana klien menghubungi server. Dalam semua kasus, klien mengirim permintaan ke endpoint, juga disebut pelabuhan, di mana mesin server adalah server yang running. Beberapa mendengarkan titik akhir tertentu. Bagaimana klien mengetahui titik akhir dari layanan? Satu pendekatan adalah untuk menetapkan global endpoint untuk layanan terkenal. Sebagai contoh, server yang menangani internet FTP permintaan selalu mendengarkan TCP port 21. Demikian juga, sebuah HTTP server untuk world wide web akan selalu mendengarkan TCP port 80. Ini endpoint telah ditetapkan oleh internet diberi nomor otoritas (IANA), dan didokumentasikan dalam (Reynolds postel dan, 1994). Dengan titik akhir yang ditetapkan, klien hanya perlu menemukan alamat jaringan dari mesin dimana server berjalan. Seperti kami jelaskan dalam bab berikutnya, jasa nama dapat digunakan untuk tujuan itu .

Ada banyak layanan yang tidak memerlukan titik akhir preassigned. Misalnya, waktu sehari server yang dapat menggunakan titik akhir yang dinamis ditugaskan oleh sistem operasi lokal. Dalam hal ini, klien pertama akan harus mencari titik akhir. Salah satu solusi, seperti yang kita lihat di DCE, adalah memiliki daemon khusus yang berjalan pada setiap mesin yang menjalankan server. Deamon ini melacak titik akhir saat ini setiap pelayanan yang diterapkan oleh server collocated. Daemon sendiri mendengarkan endpoint terkenal. Seorang klien pertama akan menghubungi daemon, meminta titik akhir, dan kontak server tertentu, seperti yang ditunjukkan pada gambar. Hal ini umum untuk mengasosiasikan titik akhir dengan layanan tertentu. Namun, benar-benar menerapkan setiap layanan melalui suatu servis terpisah mungkin membuang-buang sumber daya.

A ) . client -server mengikat menggunakan daemon seperti di DCE . B ) . klien-ke -server mengikat menggunakan superserver seperti dalam UNIX .

Sebagai contoh, dalam sistem yang khas UNIX, biasanya telah kehilangan server berjalan secara bersamaan, dengan sebagian besar dari mereka pasif menunggu sampai permintaan klien masuk daripada harus melacak begitu banyak proses pasif, seringkali lebih efisien memiliki superserver tunggal mendengarkan masing-masing endpoint terkait dengan layanan tertentu, seperti yang ditunjukkan pada Gbr.3-7 (b). ini adalah pendekatan yang diambil, misalnya, dengan daemon inetd di UNIX. Inetd mendengarkan sejumlah port terkenal untuk layanan internet. Proses itu akan keluar setelah selesai. Isu lain yang perlu dipertimbangkan ketika merancang server, adalah apakah dan bagaimana server dapat terganggu. Misalnya, coasider pengguna yang baru saja memutuskan untuk meng-upload file besar ke server FTP. Lalu, tiba-tiba menyadari bahwa itu adalah file yang salah, dia ingin terganggu server untuk membatalkan transmisi data lanjut. Ada beberapa cara untuk melakukan pendekatan this.one yang bekerja dengan sangat baik di internet saat ini (dan kadang-kadang satu-satunya alternatif), adalah bagi pengguna untuk tiba-tiba keluar dari aplikasi client (yang secara otomatis akan merusak sambungan ke server), segera restart, dan berpura-pura tidak ada yang terjadi. Server akhirnya akan meruntuhkan sambungan tua, berpikir klien telah jatuh. Sebuah pendekatan yang lebih baik untuk menangani interupsi komunikasi, adalah untuk mengembangkan klien dan server seperti bahwa adalah mungkin untuk mengirim data keluar - ofband, di TCP misalnya, adalah mungkin untuk mengirimkan data mendesak data.Ketika mendesak yang diterima di server yang terakhir ini terganggu (misalnya melalui sinyal dalam sistem UNIX), setelah whitch di dapat memeriksa data dan menanganinya mereka sesuai. Pada akhirnya, yang penting adalah ada atau tidak server adalah stateless . Sebuah server stateless tidak ada menyimpan informasi tentang keadaan itu adalah klien, dan dapat mengubah keadaan sendiri tanpa harus menginformasikan klien (Birman, 1996). Juga, koleksi file yang mengelola web server (mungkin bekerja sama dengan mengajukan Server), dapat diubah tanpa klien harus diberitahu.

Sebaliknya, server stateful tidak memelihara informasi klien. Sebuah contoh sederhana adalah sebuah file server yang memungkinkan klien untuk menyimpan salinan lokal file, bahkan untuk melakukan update opetions . Secara umum server stateful perlu untuk memulihkan seluruh keadaan seperti itu hanya sebelum kecelakaan. Seperti yang kita bahas dalam bab pemulihan 7 enabling dapat interoduce kompleksitas yang cukup. Dalam desain stateless ada tindakan khusus perlu diambil sama sekali untuk server crash untuk pulih. Ini hanya mulai berjalan lagi, dan menunggu permintaan klien untuk masuk. Ketika merancang server pilihan untuk desain stateless atau stateful seharusnya tidak affet layanan yang diberikan oleh server. Misalnya apakah file harus dibuka sebelum mereka dapat dibaca dari atau ditulis untuk kemudian server stateless mestinya pada cara atau yang dapat dibaca dari atau ditulis , dan segera menutup file lagi. Dalam kasus lain, server saya ingin menyimpan rekam pada perilaku klien sehingga dapat lebih efektif menanggapi permintaan tersebut. Sebagai contoh, server web kadang-kadang menawarkan kemungkinan untuk segera mengarahkan klien ke halaman favoritnya. Pendekatan Tesalonika hanya mungkin jika server memiliki informasi sejarah pada klien thet. Solusi umum adalah untuk membiarkan klien mengirim sepanjang informasi tambahan mengenai akses sebelumnya. Informasi ini sering transparan disimpan oleh browser klien dalam apa yang disebut cookie, yang merupakan bagian kecil data yang berisi informasi klien khusus yang menarik ke server. Cookie tidak pernah dijalankan oleh browser, mereka hanya disimpan.

3.3.1

Object Server Setelah teken melihat beberapa masalah desain umum, kita sekarang mempertimbangkan jenis khusus dari server yang menjadi semakin penting. Server objek adalah server dirancang untuk mendukung objek terdistribusi. Perbedaan penting antara server objek umum dan lainnya (lebih tradisional) server, adalah bahwa objek server dengan sendirinya tidak benar-benar memberikan layanan khusus. Jasa yang dilaksanakan oleh benda-benda yang

berada dalam memutuskan ini. Akibatnya, relatif mudah untuk mengubah layanan hanya dengan menambahkan dan menghapus objek. Server objek demikian bertindak sebagai tempat di mana benda-benda hidup. Sebuah objek terdiri dari dua bagian data yang mewakili negara dan kode membentuk pelaksanaan methods.also, terdapat perbedaan dalam cara server objek memanggil objeknya. Misalnya, dalam multithreaded server, masingmasing objek saya ditugaskan thread terpisah, atau thread terpisah saya digunakan untuk setiap permintaan doa. Ini dan isu-isu lainnya yang dibahas berikutnya.

Alternative For Invoking Objects Untuk objek yang akan dipanggil, server objek perlu tahu kode yang mengeksekusi, di mana data harus beroperasi, apakah harus memulai pembagian thread untuk melakukan pemanggilan, dan sebagainya. Pendekatan sederhana adalah dengan mengasumsikan bahwa semua benda mirip dan bahwa ada satu cara untuk memanggil esensi object.in, ini adalah apa DCE does.ubfortunately, pendekatan semacam ini umumnya inflex ible dan sering perlu membatasi pengembang objek terdistribusi. Pendekatan yang lebih baik adalah untuk server untuk mendukung kebijakan yang berbeda. Perhatikan, misalnya, objek transient. Ingat bahwa objek transien adalah obyek yang ada hanya selama server ada, tapi mungkin untuk waktu yang lebih singkat. Sebuah in-memory, read-only copy file dapat biasanya diimplementasikan sebagai objek sementara. Demikian juga, kalkulator (mungkin berjalan pada server kinerja tinggi ), juga bisa diimplementasikan sebagai objek sementara. Oleh karena itu, kebijakan alternatif kadang-kadang untuk membuat semua benda sementara pada saat server diinisialisasi, pada biaya mengkonsumsi sumber daya bahkan ketika ada klien diinisialisasi, pada biaya mengkonsumsi sumber daya bahkan ketika tidak ada klien memanfaatkan objek. Dalam cara yang sama server bisa mengikuti kebijakan bahwa setiap benda yang diletakkan dalam segmen memori sendiri. Misalnya sebuah database yang berisi benda-benda yang termasuk dalam kelas yang sama dapat diimplementasikan dengan efisien memuat pelaksanaan kelas hanya sekali ke server. Ketika permintaan untuk sebuah doa objek datang dalam server hanya perlu mengambil menyatakan bahwa objek dari database dan mengeksekusi metode requsted.

Demikian juga, ada banyak kebijakan yang berbeda sehubungan dengan threading. Pendekatan paling sederhana adalah dengan menerapkan server dengan hanya satu thread kontrol. Atau server mungkin memiliki beberapa thread, satu untuk objek server lewat permintaan ke thread bertanggung jawab untuk object. Tentu, juga memungkinkan untuk menggunakan pemanggilan request terpisah untuk setiap permintaan, dengan syarat bahwa obyek harus sudah dilindungi terhadap akses konkuren. Independen menggunakan thread per objek atau thread per metode adalah pilihan apakah thread diciptakan pada permintaan atau server mempertahankan kolam thread. Umumnya tidak ada kebijakan tunggal terbaik.