Bersama dengan lapisan jaringan, lapisan transport adalah jantung dari hirarki protokol.

Lapisan jaringan
menyediakan pengiriman paket end-to-end menggunakan datagrams atau sirkuit virtual. Lapisan
transport dibangun di atas lapisan jaringan untuk menyediakan transportasi data dari suatu proses pada
mesin sumber ke suatu proses pada mesin tujuan dengan tingkat keandalan yang diinginkan yang tidak
bergantung pada jaringan fisik yang sedang digunakan. Ini menyediakan abstraksi bahwa aplikasi perlu
menggunakan jaringan. Tanpa lapisan transport, seluruh konsep protokol berlapis tidak masuk akal.
Dalam bab ini, kita akan mempelajari lapisan transport secara rinci, termasuk layanan dan pilihan desain
API untuk mengatasi masalah keandalan, koneksi dan kontrol kemacetan, protokol seperti TCP dan UDP,
dan kinerja.
6.1 LAYANAN TRANSPORTASI
Pada bagian berikut, kami akan memberikan pengantar untuk layanan transportasi. Kami melihat jenis
layanan apa yang disediakan untuk lapisan aplikasi. Untuk membuat masalah layanan transportasi lebih
konkrit, kami akan memeriksa dua set lapisan transport primitif. Pertama datang yang sederhana (tetapi
hipotetis) untuk menunjukkan ide-ide dasar. Kemudian muncul antarmuka yang biasa digunakan di
Internet.
6.1.1 Layanan Disediakan ke Lapisan Atas
Tujuan akhir dari lapisan transport adalah untuk menyediakan layanan transmisi data yang efisien,
andal, dan hemat biaya kepada penggunanya, biasanya proses dalam lapisan aplikasi. Untuk mencapai
hal ini, lapisan transport menggunakan layanan yang disediakan oleh lapisan jaringan. Perangkat lunak
dan / atau perangkat keras dalam lapisan transport yang melakukan pekerjaan ini disebut entitas
transportasi. Entitas transportasi dapat ditemukan di kernel sistem operasi, dalam paket perpustakaan
yang terikat ke dalam aplikasi jaringan, dalam proses pengguna yang terpisah, atau bahkan pada kartu
antarmuka jaringan. Dua opsi pertama adalah yang paling umum di Internet. Hubungan (logis) dari
jaringan, transportasi, dan lapisan aplikasi diilustrasikan pada Gambar. 6-1.

Sama seperti ada dua jenis layanan jaringan, connection-oriented dan connectionless, ada juga dua jenis
layanan transportasi. Layanan transportasi berorientasi koneksi mirip dengan layanan jaringan
berorientasi koneksi dalam banyak cara. Dalam kedua kasus, koneksi memiliki tiga fase: pembentukan,
transfer data, dan rilis. Pengalamatan dan kontrol aliran juga serupa di kedua lapisan. Selain itu, layanan
transportasi tanpa sambungan juga sangat mirip dengan layanan jaringan tanpa sambungan. Namun,
perhatikan bahwa mungkin sulit untuk menyediakan layanan transportasi tanpa sambungan di atas
layanan jaringan berorientasi koneksi, karena tidak efisien untuk mengatur koneksi untuk mengirim
paket tunggal dan kemudian merobeknya segera setelah itu. Pertanyaan yang jelas adalah ini: jika
layanan lapisan transport sangat mirip dengan layanan lapisan jaringan, mengapa ada dua lapisan yang
berbeda? Mengapa satu layer tidak memadai? Jawabannya halus, tetapi sangat penting. Kode
transportasi berjalan sepenuhnya pada mesin pengguna, tetapi lapisan jaringan sebagian besar berjalan
pada router, yang dioperasikan oleh operator (setidaknya untuk jaringan area luas). Apa yang terjadi jika
lapisan jaringan menawarkan layanan yang tidak memadai? Bagaimana jika sering kehilangan paket?
Apa yang terjadi jika router crash dari waktu ke waktu? Masalah terjadi, itulah yang terjadi. Pengguna
tidak memiliki kontrol nyata atas lapisan jaringan, sehingga mereka tidak dapat menyelesaikan masalah
layanan yang buruk dengan menggunakan router yang lebih baik atau menempatkan lebih banyak
penanganan kesalahan di lapisan tautan data karena mereka tidak memiliki router. Satu-satunya
kemungkinan adalah meletakkan di atas lapisan jaringan lapisan lain yang meningkatkan kualitas
layanan. Jika, dalam jaringan tanpa sambungan, paket hilang atau rusak, entitas transportasi dapat
mendeteksi masalah dan mengimbanginya dengan menggunakan transmisi ulang. Jika, dalam jaringan
yang berorientasi koneksi, entitas transportasi diinformasikan di tengah-tengah transmisi yang panjang
bahwa koneksi jaringannya telah dihentikan secara tiba-tiba, tanpa indikasi apa yang telah terjadi pada
data yang saat ini sedang transit, dapat mengatur koneksi jaringan baru ke entitas transportasi jarak
jauh. Menggunakan koneksi jaringan baru ini, ia dapat mengirim permintaan ke rekannya yang
menanyakan data mana yang datang dan mana yang tidak, dan mengetahui di mana itu, mengambil dari
mana ia tinggalkan. Intinya, keberadaan lapisan transportasi memungkinkan layanan transportasi
menjadi lebih andal daripada jaringan yang mendasarinya. Selanjutnya, primitif transportasi dapat
diimplementasikan sebagai panggilan ke prosedur perpustakaan untuk membuat mereka independen
dari primitif jaringan. Panggilan layanan jaringan dapat bervariasi dari satu jaringan ke jaringan lainnya
(misalnya, panggilan berdasarkan Ethernet connectionless mungkin sangat berbeda dari panggilan pada
jaringan WiMAX yang berorientasi koneksi). Menyembunyikan layanan jaringan di belakang sekumpulan
layanan transportasi primitif memastikan bahwa mengubah jaringan hanya membutuhkan penggantian
satu set prosedur perpustakaan dengan yang lain yang melakukan hal yang sama dengan layanan dasar
yang berbeda. Berkat lapisan transport, pemrogram aplikasi dapat menulis kode sesuai dengan
seperangkat standar primitif dan memiliki program-program ini bekerja di berbagai jaringan, tanpa
harus khawatir tentang berurusan dengan antarmuka jaringan dan tingkat keandalan yang berbeda. Jika
semua jaringan nyata sempurna dan semua memiliki layanan primitif yang sama dan dijamin tidak
pernah, pernah berubah, lapisan transport mungkin tidak diperlukan. Namun, di dunia nyata itu
memenuhi fungsi kunci mengisolasi lapisan atas dari teknologi, desain, dan ketidaksempurnaan jaringan.
Untuk alasan ini, banyak orang telah membuat perbedaan kualitatif antara lapisan 1 hingga 4 di satu sisi
dan lapisan di atas 4 di sisi lain. Empat lapisan bawah dapat dilihat sebagai penyedia layanan
transportasi, sedangkan lapisan atas (s) adalah pengguna jasa transportasi. Perbedaan antara penyedia
dan pengguna ini memiliki dampak yang besar terhadap desain lapisan dan menempatkan lapisan
transport dalam posisi kunci, karena ini membentuk batas utama antara penyedia dan pengguna
layanan transmisi data yang dapat diandalkan. Ini adalah level yang dilihat oleh aplikasi.

6.1.2 Prinsip Layanan Transportasi

Untuk memungkinkan pengguna mengakses layanan transportasi, lapisan transport harus
menyediakan beberapa operasi untuk program aplikasi, yaitu antarmuka layanan transportasi.
Setiap layanan transportasi memiliki antarmuka sendiri. Pada bagian ini, pertama-tama kita akan
memeriksa layanan transportasi sederhana (hipotetis) dan antarmukanya untuk melihat hal-hal
penting. Pada bagian berikutnya, kita akan melihat contoh nyata. Layanan transportasi mirip
dengan layanan jaringan, tetapi ada juga beberapa perbedaan penting. Perbedaan utama adalah
bahwa layanan jaringan dimaksudkan untuk memodelkan layanan yang ditawarkan oleh jaringan
nyata, warts dan semua. Jaringan nyata dapat kehilangan paket, sehingga layanan jaringan
umumnya tidak dapat diandalkan. Layanan transportasi berorientasi koneksi, sebaliknya, dapat
diandalkan. Tentu saja, jaringan nyata tidak bebas dari kesalahan, tetapi itulah tujuan dari lapisan
transport — untuk menyediakan layanan yang andal di atas jaringan yang tidak dapat diandalkan.
Sebagai contoh, pertimbangkan dua proses pada satu mesin yang dihubungkan oleh pipa di
UNIX (atau fasilitas komunikasi interprocess lainnya). Mereka menganggap koneksi di antara
mereka 100% sempurna. Mereka tidak ingin tahu tentang ucapan terima kasih, paket yang
hilang, kemacetan, atau apa pun yang seperti itu. Apa yang mereka inginkan adalah koneksi yang
100% andal. Proses A menempatkan data ke dalam satu ujung pipa, dan memproses B
mengambilnya dari yang lain. Inilah yang dimaksud dengan layanan transportasi berorientasi-
koneksi - menyembunyikan ketidaksempurnaan layanan jaringan sehingga proses pengguna
hanya dapat mengasumsikan keberadaan aliran bit bebas kesalahan bahkan ketika mereka berada
di mesin yang berbeda. Sebagai tambahan, lapisan transport juga dapat menyediakan layanan
tidak dapat diandalkan (datagram). Namun, ada relatif sedikit untuk mengatakan tentang itu
selain '‘itu datagram,’ jadi kami terutama akan berkonsentrasi pada layanan transportasi
berorientasi koneksi di bab ini. Namun demikian, ada beberapa aplikasi, seperti komputasi
client-server dan streaming multimedia, yang dibangun pada layanan transportasi tanpa
sambungan, dan kami akan mengatakan sedikit tentang itu nanti. Perbedaan kedua antara layanan
jaringan dan layanan transportasi yang ditujukan untuk layanan tersebut. Layanan jaringan hanya
digunakan oleh entitas transportasi. Beberapa pengguna menulis entitas transportasi mereka
sendiri, dan dengan demikian beberapa pengguna atau program pernah melihat layanan jaringan
telanjang. Sebaliknya, banyak program (dan dengan demikian programmer) melihat primitif
transportasi. Akibatnya, layanan transportasi harus nyaman dan mudah digunakan. Untuk
mendapatkan gambaran tentang seperti apa layanan transportasi itu, perhatikan lima primitif
yang tercantum pada Gambar 6-2. Antarmuka transportasi ini benar-benar telanjang tulang,
tetapi memberikan rasa esensial dari apa yang harus dilakukan oleh antarmuka transportasi
berorientasi koneksi. Ini memungkinkan program aplikasi untuk membuat, menggunakan, dan
kemudian melepaskan koneksi, yang cukup untuk banyak aplikasi. Untuk melihat bagaimana
primitif ini dapat digunakan, pertimbangkan aplikasi dengan server dan sejumlah klien jarak
jauh. Untuk mulai dengan, server mengeksekusi LISTEN primitif, biasanya dengan memanggil
prosedur pustaka yang membuat panggilan sistem itu
memblokir server sampai klien muncul. Ketika seorang klien ingin berbicara dengan server, ia
mengeksekusi primitif CONNECT. Entitas transportasi melakukan hal ini dengan memblokir penelepon
dan mengirim paket ke server. Terenkapsulasi dalam muatan paket ini adalah pesan lapisan transport
untuk entitas transportasi server. Catatan singkat tentang terminologi sekarang dalam urutan. Karena
tidak ada istilah yang lebih baik, kami akan menggunakan segmen istilah untuk pesan yang dikirim dari
entitas transportasi ke entitas transportasi. TCP, UDP dan protokol Internet lainnya menggunakan istilah
ini. Beberapa protokol yang lebih tua menggunakan nama tungau TPDU (Transport Protocol Data Unit).
Istilah itu tidak digunakan lagi sekarang tetapi Anda mungkin melihatnya di koran dan buku yang lebih
tua. Dengan demikian, segmen (ditukar oleh lapisan transport) terkandung dalam paket (dipertukarkan
oleh lapisan jaringan). Pada gilirannya, paket-paket ini terkandung dalam frame (dipertukarkan oleh
layer link data). Ketika sebuah frame tiba, lapisan data link memproses header frame dan, jika alamat
tujuan cocok untuk pengiriman lokal, melewati isi bidang payload frame hingga entitas jaringan. Entitas
jaringan yang sama memproses header paket dan kemudian meneruskan isi dari muatan paket ke
entitas transport. Sarang ini diilustrasikan pada Gambar 6-3.

Kembali ke contoh server klien kami, panggilan CONNECT klien menyebabkan segmen
CONNECTION REQUEST yang akan dikirim ke server. Ketika tiba, itu pemeriksaan entitas
transportasi untuk melihat bahwa server diblokir pada LISTEN (yaitu, tertarik dalam menangani
permintaan). Jika demikian, itu kemudian membuka blokir server dan mengirim segmen
CONNECTION ACCEPTED kembali ke klien. Ketika segmen ini tiba, klien diblokir dan
koneksi dibuat. Data sekarang dapat ditukar menggunakan KIRIM dan MENERIMA primitif.
Dalam bentuk yang paling sederhana, salah satu pihak dapat melakukan (memblokir)
MENERIMA untuk menunggu pihak lain melakukan SEND. Ketika segmen tiba, penerima tidak
diblokir. Kemudian dapat memproses segmen dan mengirim balasan. Selama kedua belah pihak
dapat melacak giliran siapa yang dikirim, skema ini berfungsi dengan baik. Perhatikan bahwa
dalam lapisan transport, bahkan pertukaran data searah sederhana lebih rumit daripada di lapisan
jaringan. Setiap paket data yang dikirim juga akan diakui (akhirnya). Paket-paket yang
mengandung segmen kontrol juga diakui, secara implisit atau eksplisit. Ucapan terima kasih ini
dikelola oleh entitas transportasi, menggunakan protokol lapisan jaringan, dan tidak terlihat oleh
pengguna transportasi. Demikian pula, entitas transportasi perlu khawatir tentang timer dan
transmisi ulang. Tak satu pun dari mesin ini terlihat oleh pengguna transportasi. Untuk pengguna
transportasi, koneksi adalah bit pipe yang dapat diandalkan: satu bit barang pengguna dan secara
ajaib muncul dalam urutan yang sama di ujung yang lain. Kemampuan untuk menyembunyikan
kerumitan ini adalah alasan mengapa protokol berlapis adalah alat yang sangat kuat. Ketika
koneksi tidak lagi diperlukan, itu harus dilepaskan untuk membebaskan ruang tabel dalam dua
entitas transportasi. Disconnection memiliki dua varian: asimetris dan simetris. Pada varian
asimetris, pengguna transportasi dapat mengeluarkan primitif DISCONNECT, yang
menghasilkan segmen DISCONNECT yang dikirim ke entitas transport jarak jauh. Setelah
kedatangannya, koneksi dilepaskan. Dalam varian simetris, setiap arah ditutup secara terpisah,
terlepas dari yang lain. Ketika satu pihak melakukan DISCONNECT, itu berarti ia tidak
memiliki lebih banyak data untuk dikirim tetapi masih bersedia menerima data dari mitranya.
Dalam model ini, koneksi dilepaskan ketika kedua pihak telah melakukan DISCONNECT.
Diagram keadaan untuk pembentukan koneksi dan pelepasan untuk primitif sederhana ini
diberikan pada Gambar 6-4. Setiap transisi dipicu oleh beberapa peristiwa, baik primitif yang
dijalankan oleh pengguna transportasi lokal atau paket masuk. Untuk kesederhanaan, kita
asumsikan di sini bahwa setiap segmen secara terpisah diakui. Kami juga berasumsi bahwa
model pemutusan simetrik digunakan, dengan klien pergi pertama. Harap dicatat bahwa model
ini cukup sederhana. Kami akan melihat model yang lebih realistis nantinya ketika kami
menjelaskan cara kerja TCP.
6.1.3 Soket Berkeley
Mari kita sekarang memeriksa sekumpulan primitif transportasi, soket primitif sebagaimana
mereka digunakan untuk TCP. Soket pertama kali dirilis sebagai bagian dari distribusi perangkat
lunak UNIX 4.2BSD Berkeley pada tahun 1983. Mereka dengan cepat menjadi populer. Primitif
sekarang banyak digunakan untuk pemrograman Internet pada banyak operasi

sistem, terutama sistem berbasis UNIX, dan ada API bergaya soket untuk Windows yang disebut
'winsocks'. 'Primitif tercantum pada Gambar 6-5. Secara kasar, mereka mengikuti model contoh pertama
kami tetapi menawarkan lebih banyak fitur dan fleksibilitas. Kami tidak akan melihat segmen yang sesuai
di sini. Diskusi itu akan datang nanti.

Empat primitif pertama dalam daftar dieksekusi dalam urutan itu oleh server. SOCKET primitive
menciptakan titik akhir baru dan mengalokasikan ruang tabel untuk itu dalam entitas transportasi.
Parameter panggilan menentukan format pengalamatan yang akan digunakan, jenis layanan yang
diinginkan (misalnya, aliran byte yang dapat diandalkan), dan protokol. Panggilan SOCKET yang sukses
mengembalikan deskriptor file biasa untuk digunakan dalam panggilan berikutnya, sama seperti
panggilan OPEN pada file. Soket yang baru dibuat tidak memiliki alamat jaringan. Ini ditugaskan
menggunakan primitif BIND. Setelah server mengikat alamat ke soket, klien jarak jauh dapat
menyambungkannya. Alasan tidak memiliki panggilan SOCKET membuat alamat secara langsung adalah
bahwa beberapa proses peduli dengan alamat mereka (misalnya, mereka telah menggunakan alamat
yang sama selama bertahun-tahun dan semua orang tahu alamat ini), sedangkan yang lain tidak.
Selanjutnya muncul panggilan DENGARKAN, yang mengalokasikan ruang untuk mengantri panggilan
masuk untuk kasus yang beberapa klien coba hubungkan pada saat yang bersamaan. Berbeda dengan
MENDENGARKAN dalam contoh pertama kami, dalam model soket DENGARKAN bukan panggilan
memblokir. Untuk memblokir menunggu koneksi masuk, server mengeksekusi primitif ACCEPT. Ketika
sebuah segmen yang meminta koneksi tiba, entitas transport menciptakan soket baru dengan properti
yang sama seperti yang asli dan mengembalikan deskriptor file untuknya. Server kemudian dapat
melakukan proses atau thread untuk menangani koneksi pada soket baru dan kembali untuk menunggu
koneksi berikutnya pada soket asli. SETUJU mengembalikan deskriptor file, yang dapat digunakan untuk
membaca dan menulis dengan cara standar, sama seperti untuk file. Sekarang mari kita lihat sisi klien. Di
sini juga, soket harus dibuat terlebih dahulu menggunakan SOCKET primitif, tetapi BIND tidak diperlukan
karena alamat yang digunakan tidak menjadi masalah bagi server. The CONNECT primitive memblok
pemanggil dan secara aktif memulai proses koneksi. Ketika selesai (yaitu, ketika segmen yang tepat
diterima dari server), proses klien tidak diblokir dan koneksi dibuat. Kedua belah pihak sekarang dapat
menggunakan KIRIM dan MENERIMA untuk mengirim dan menerima data melalui koneksi full-duplex.
Panggilan sistem UNIX READ dan WRITE standar juga dapat digunakan jika tidak ada opsi khusus dari
SEND dan RECEIVE yang diperlukan. Pelepasan koneksi dengan soket simetris. Ketika kedua belah pihak
telah melakukan CLOSE primitive, koneksi dilepaskan. Soket telah terbukti sangat populer dan
merupakan standar de facto untuk mengabstraksikan layanan transportasi ke aplikasi. Soket API sering
digunakan dengan protokol TCP untuk menyediakan layanan berorientasi koneksi yang disebut aliran
byte yang dapat diandalkan, yang hanya merupakan pipa bit yang dapat diandalkan yang kami jelaskan.
Namun, protokol lain dapat digunakan untuk mengimplementasikan layanan ini menggunakan API yang
sama. Itu semua harus sama untuk pengguna layanan transportasi. Kekuatan soket API adalah yang
dapat digunakan oleh aplikasi untuk layanan transportasi lainnya. Misalnya, soket dapat digunakan
dengan layanan transportasi tanpa sambungan. Dalam hal ini, CONNECT menyetel alamat peer
transportasi jarak jauh dan KIRIM dan MENERIMA mengirim dan menerima datagram ke dan dari peer
jarak jauh.
(Hal ini juga umum untuk menggunakan seperangkat panggilan diperluas, misalnya, SENDTO
dan RECEIVEFROM, yang menekankan pesan dan tidak membatasi aplikasi ke peer transportasi
tunggal.) Soket juga dapat digunakan dengan protokol transport yang menyediakan aliran pesan
lebih dari aliran byte dan yang melakukan atau tidak memiliki kontrol kemacetan. Sebagai
contoh, DCCP (Datagram Congestion Controlled Protocol) adalah versi UDP dengan kontrol
kemacetan (Kohler et al., 2006). Terserah pengguna transportasi untuk memahami layanan apa
yang mereka dapatkan. Namun, soket tidak mungkin menjadi kata akhir pada antarmuka
transportasi. Sebagai contoh, aplikasi sering bekerja dengan sekelompok aliran terkait, seperti
browser Web yang meminta beberapa objek dari server yang sama. Dengan soket, fit yang paling
alami adalah untuk program aplikasi untuk menggunakan satu aliran per objek. Struktur ini
berarti bahwa kontrol kemacetan diterapkan secara terpisah untuk setiap aliran, tidak melintasi
grup, yang suboptimal. Ini memberi beban pada aplikasi beban mengelola set. Protokol dan
antarmuka yang lebih baru telah dirancang untuk mendukung kelompok-kelompok aliran terkait
secara lebih efektif dan sederhana untuk aplikasi. Dua contohnya adalah SCTP (Stream Control
Transmission Protocol) yang didefinisikan dalam RFC 4960 dan SST (Structured Stream
Transport) (Ford, 2007). Protokol ini harus mengubah soket API sedikit untuk mendapatkan
manfaat dari kelompok aliran terkait, dan mereka juga mendukung fitur seperti campuran lalu
lintas berorientasi koneksi dan tanpa sambungan dan bahkan beberapa jalur jaringan. Waktu
akan memberi tahu apakah mereka berhasil.
6.1.4 Sebuah Contoh Pemrograman Socket: Sebuah File Server Internet
Sebagai contoh dari seluk-beluk bagaimana panggilan socket nyata dibuat, pertimbangkan klien
dan kode server Gambar 6-6. Di sini kami memiliki file server Internet yang sangat primitif
bersama dengan contoh klien yang menggunakannya. Kode ini memiliki banyak keterbatasan
(dibahas di bawah), tetapi pada prinsipnya kode server dapat dikompilasi dan dijalankan pada
sistem UNIX yang terhubung ke Internet. Kode klien dapat dikompilasi dan dijalankan pada
mesin UNIX lainnya di Internet, di mana pun di dunia. Kode klien dapat dieksekusi dengan
parameter yang tepat untuk mengambil file yang diakses server pada mesinnya. File ditulis ke
output standar, yang tentu saja dapat dialihkan ke file atau pipa. Mari kita lihat kode server
terlebih dahulu. Ini dimulai dengan memasukkan beberapa header standar, tiga yang terakhir
berisi definisi dan struktur data terkait Internet yang utama. Berikutnya muncul definisi
SERVER PORT sebagai 12345. Nomor ini dipilih secara sewenang-wenang. Setiap angka antara
1024 dan 65535 juga akan berfungsi, asalkan tidak digunakan oleh beberapa proses lain; port di
bawah 1023 dicadangkan untuk pengguna istimewa. Dua baris berikutnya di server
mendefinisikan dua konstanta yang diperlukan. Yang pertama menentukan ukuran chunk dalam
byte yang digunakan untuk transfer file. Yang kedua menentukan berapa banyak koneksi yang
tertunda dapat diadakan sebelum yang lain dibuang pada saat kedatangan.

Setelah deklarasi variabel lokal, kode server dimulai. Ini dimulai dengan menginisialisasi struktur data
yang akan menyimpan alamat IP server. Struktur data ini akan segera terikat ke soket server. Panggilan
untuk memset mengatur struktur data ke semua 0s. Tiga tugas berikut ini mengisi tiga bidangnya. Yang
terakhir ini berisi port server. Fungsi htonl dan htons harus dilakukan dengan mengkonversi nilai ke
format standar sehingga kode berjalan dengan benar pada kedua mesin little-endian (mis., Intel x86)
dan mesin big-endian (mis., SPARC). Semantik yang tepat tidak relevan di sini. Selanjutnya, server
membuat soket dan memeriksa kesalahan (ditunjukkan oleh s <0). Dalam versi produksi kode, pesan
kesalahan bisa menjadi sedikit lebih jelas. Panggilan ke setockopt diperlukan untuk memungkinkan port
untuk digunakan kembali sehingga server dapat berjalan tanpa batas, mengajukan permintaan setelah
permintaan. Sekarang alamat IP terikat ke soket dan pemeriksaan dilakukan untuk melihat apakah
panggilan untuk mengikat berhasil. Langkah terakhir dalam inisialisasi adalah panggilan untuk
mendengarkan mengumumkan kemauan server untuk menerima panggilan masuk dan memberi tahu
sistem untuk menahan hingga RATU SIZE dari mereka jika ada permintaan baru ketika server masih
memproses yang saat ini. Jika antrian sudah penuh dan permintaan tambahan datang, mereka diam-
diam dibuang. Pada titik ini, server memasuki loop utamanya, yang tidak pernah keluar. Satu-satunya
cara untuk menghentikannya adalah dengan membunuhnya dari luar. Panggilan untuk menerima blok
server sampai beberapa klien mencoba untuk membuat koneksi dengannya. Jika menerima panggilan
berhasil, ia mengembalikan deskriptor soket yang dapat digunakan untuk membaca dan menulis, analog
dengan bagaimana deskriptor file dapat digunakan untuk membaca dari dan menulis ke pipa. Namun,
tidak seperti pipa, yang tidak searah, soket bersifat dua arah, jadi sa (soket yang diterima) dapat
digunakan untuk membaca dari koneksi dan juga untuk menulis ke sana. Sebuah deskriptor file pipa
untuk membaca atau menulis tetapi tidak keduanya. Setelah koneksi dibuat, server membaca nama file
dari itu. Jika nama itu belum tersedia, server menunggu untuk itu. Setelah mendapatkan nama file,
server membuka file dan memasuki loop yang secara bergantian membaca blok dari file dan menulisnya
ke soket sampai seluruh file telah disalin. Kemudian server menutup file dan koneksi dan menunggu
koneksi berikutnya muncul. Ini mengulangi loop ini selamanya. Sekarang mari kita lihat kode klien.
Untuk memahami cara kerjanya, penting untuk memahami cara kerjanya. Dengan asumsi itu disebut
klien, panggilan yang khas adalah klien flits.cs.vu.nl / usr / tom / filename> f Panggilan ini hanya
berfungsi jika server sudah berjalan di flits.cs.vu.nl dan file / usr / tom / filename ada dan server telah
membaca akses ke sana. Jika panggilan berhasil, file ditransfer melalui Internet dan ditulis ke f, setelah
itu program klien keluar. Karena server berlanjut setelah transfer, klien dapat dimulai lagi dan lagi untuk
 mendapatkan file lain. Kode klien dimulai dengan beberapa termasuk dan deklarasi. Eksekusi dimulai
dengan memeriksa untuk melihat apakah telah dipanggil dengan jumlah argumen yang tepat (argc = 3
berarti nama program ditambah dua argumen). Perhatikan bahwa argv [1] berisi

nama server (mis., flits.cs.vu.nl) dan diubah menjadi alamat IP oleh gethostbyname. Fungsi ini
menggunakan DNS untuk mencari nama. Kami akan mempelajari DNS di Chap.7. Selanjutnya,
soket dibuat dan diinisialisasi. Setelah itu, klien mencoba untuk membuat koneksi TCP ke server,
menggunakan koneksi. Jika server berjalan dan berjalan pada mesin yang dinamai dan
dilampirkan ke SERVER PORT dan tidak aktif atau memiliki ruang di antrean
mendengarkannya, koneksi akan (akhirnya) dibuat. Menggunakan koneksi, klien mengirim nama
file dengan menulis di soket. Jumlah byte yang dikirim adalah satu lebih besar dari nama yang
tepat, karena 0 byte yang mengakhiri nama juga harus dikirim untuk memberi tahu server tempat
nama itu berakhir. Sekarang klien memasuki satu lingkaran, membaca blok file dengan blok dari
soket dan menyalinnya ke output standar. Ketika selesai, itu hanya keluar. Prosedur fatal
mencetak pesan kesalahan dan keluar. Server memerlukan prosedur yang sama, tetapi
dihilangkan karena kurangnya ruang pada halaman. Karena klien dan server dikompilasi secara
terpisah dan biasanya dijalankan di komputer yang berbeda, mereka tidak dapat berbagi kode
fatal. Kedua program ini (serta materi lain yang terkait dengan buku ini) dapat diambil dari situs
web buku http://www.pearsonhighered.com/tanenbaum Hanya untuk catatan, server ini bukan
kata terakhir di serverdom. Pemeriksaan kesalahannya sedikit dan pelaporan kesalahannya biasa-
biasa saja. Karena menangani semua permintaan secara ketat secara berurutan (karena hanya
memiliki satu utas), kinerjanya buruk. Jelas tidak pernah mendengar tentang keamanan, dan
menggunakan sistem panggilan UNIX yang telanjang bukanlah cara untuk mendapatkan
kemandirian platform. Ini juga membuat beberapa asumsi yang secara teknis ilegal, seperti
mengasumsikan bahwa nama file cocok dalam buffer dan ditransmisikan secara atom.
Kekurangan ini meskipun, itu adalah server file Internet yang berfungsi. Dalam latihan, pembaca
diundang untuk memperbaikinya. Untuk informasi lebih lanjut tentang pemrograman dengan
soket, lihat Donahoo dan Calvert (2008, 2009).
6.2 UNSUR PROTOKOL TRANSPORTASI
Layanan transportasi dilaksanakan oleh protokol transportasi yang digunakan antara dua entitas
transportasi. Dalam beberapa hal, protokol transport menyerupai protokol data link yang kami
pelajari secara detail di Chap. 3. Keduanya harus berurusan dengan kontrol kesalahan,
pengurutan, dan kontrol aliran, di antara isu-isu lainnya. Namun, perbedaan signifikan antara
keduanya juga ada. Perbedaan-perbedaan ini disebabkan perbedaan utama antara lingkungan di
mana dua protokol beroperasi, seperti yang ditunjukkan pada Gambar 6-7. Pada layer data link,
dua router