TUGAS INDIVIDU

DOSEN : Dr. Harifudddin. M.Pd

HASIL TERJEMAHAN

6.3 CONGESTION CONTROL, 530

6.4 THE INTERNET TRANSPORT PROTOCOLS: UDP, 541

7.4 STREAMING AUDIO AND VIDEO, 697

OLEH :

NAMA : SYAMSAM ARDU. S

NIM : 15B20046

KELAS PTIK B
PROGRAM PASCASARJANA (S2)
PENDIDIKAN TEKNOLOGI DAN KEJURUAN
UNIVERSITAS NEGERI MAKASSAR
2016
 BAB 6
THE TRANSPORT LAYER

Membuat sebuah protokol yang lebih rumit. Jika klien dan server
bertukar beberapa segmen sebelum server mencoba untuk menulis, sehingga klien
tahu persis apa yang akan terjadi, klien tidak memiliki cara untuk mengetahui
apakah kecelakaan terjadi sebelum atau sesudah menulis. Kesimpulannya adalah
tak terhindarkan: di bawah aturan-aturan dasar kami ada kegiatan-yang simultan adalah, terpisah
Peristiwa terjadi satu demi satu tidak pada kecelakaan saat-host yang sama dan pemulihan
tidak dapat dimasukkan ke dalam istilah yang lebih umum, hasil ini bias dibuat transparan ke
lapisan yang lebih tinggi.

Dimasukkan ke dalam istilah yang lebih umum, hasil ini dapat disajikan kembali sebagai ''
pemulihan dari Lapisan N kecelakaan hanya dapat dilakukan oleh lapisan N + 1, '' dan kemudian
hanya jika lapisan yang lebih tinggi mempertahankan informasi status yang cukup untuk
merekonstruksi mana itu sebelum masalah terjadi. Hal ini sesuai dengan kasus yang disebutkan
di atas bahwa transportasi Lapisan dapat pulih dari kegagalan di lapisan jaringan, asalkan setiap
akhir dari koneksi melacak di mana itu.

Masalah ini membuat kita menjadi isu apa yang disebut pengakuan end-to-end atau benar-benar
berarti. Pada prinsipnya, protokol transport adalah end-to-end dan tidak dirantai seperti lapisan
bawah. Sekarang perhatikan kasus permintaan pengguna masuk untuk transaksi terhadap basis
data jauh. Misalkan entitas transportasi jarak jauh diprogram untuk segmen lulus pertama ke
lapisan berikutnya dan kemudian mengakui. Bahkan dalam hal ini, penerimaan pengakuan
kembali pada pengguna Mesin tidak berarti bahwa host remote tinggal cukup lama untuk
sebenarnya memperbarui database. Sebuah pengakuan yang benar-benar end-to-end, yang
diterimanya berarti bahwa pekerjaan sebenarnya sudah dilakukan dan kekurangan itu berarti
mungkin mustahil bahwa ia tidak memilikinya.

6.3 KEMACETAN KONTROL

Jika pada entitas transportasi mesin terlalu banyak mengirim paket ke jaringan terlalu cepat,
jaringan akan menjadi sesak, dengan kinerja terdegradasi sebagai paket yang tertunda dan hilang.
Mengontrol kemacetan untuk menghindari masalah ini adalah menggabungan dari jaringan dan
transportasi lapisan. kemacetan yang terjadi di router, sehingga terdeteksi pada lapisan jaringan.
Namun, kemacetan akhirnya disebabkan oleh lalu lintas dikirim ke jaringan dengan lapisan
transport. Satu-satunya cara yang efektif untuk mengendalikan kemacetan adalah untuk protokol
transport untuk mengirimkan paket ke dalam jaringan lebih lambat.
Dalam BAB 5, kami mempelajari mekanisme kontrol kemacetan di lapisan jaringan. Pada bagian
ini, kita akan mempelajari bagian lain dari masalah, kontrol kongesti mekanisme pada lapisan
transport. Setelah menjelaskan tujuan dari kontrol kongesti, kami akan menjelaskan bagaimana
host dapat mengatur tingkat di mana mereka mengirim paket ke dalam jaringan. Internet sangat
bergantung pada lapisan transport untuk kemacetan kontrol, dan spesifik algoritma yang
dibangun ke dalam TCP dan protokol lainnya.

6.3.1 Alokasi Bandwidth yang diinginkan

Sebelum kami menjelaskan bagaimana mengatur lalu lintas, kita harus memahami apa yang kita
mencoba untuk mencapai dengan menjalankan algoritma kontrol kemacetan. Artinya, kita harus
menentukan keadaan di mana algoritma kontrol kemacetan yang baik akan mengoperasikan
jaringan. Tujuannya adalah lebih dari sekadar menghindari kemacetan. Ini adalah untuk
menemukan alokasi yang baik bandwidth untuk entitas transportasi yang menggunakan jaringan.
Baik Alokasi akan memberikan kinerja yang baik karena menggunakan semua bandwidth yang
tersedia tapi menghindari kemacetan, itu akan adil di seluruh bersaing entitas transportasi, dan
itu akan cepat melacak perubahan dalam tuntutan lalu lintas. Kami akan membuat masing-
masing kriterialebih tepat pada gilirannya.

6.3.2 Mengatur Tingkat Pengiriman

Sekarang saatnya untuk hidangan utama. Bagaimana kita mengatur tarif pengiriman ke
mendapatkan alokasi bandwidth yang diinginkan? Tingkat pengiriman mungkin dibatasi oleh
dua faktor. Yang pertama adalah kontrol aliran, dalam kasus yang ada tidak cukup penyangga di
penerima. Yang kedua adalah kemacetan, dalam hal bahwa ada cukup kapasitas dalam jaringan.
Pada Gambar. 6-22, kita melihat masalah ini digambarkan hidrolik. Di Ara. 6-22 (a), kita melihat
pipa tebal yang mengarah ke penerima berkapasitas kecil. Ini adalah sebuah aliran-kontrol situasi
terbatas. Selama pengirim tidak mengirim lebih banyak air dari ember dapat berisi, tidak ada air
akan hilang. Pada Gambar. 6-22 (b), yang membatasi Faktor tidak ember kapasitas, tapi daya
dukung internal jaringan. Jika terlalu banyak air masuk terlalu cepat, itu akan cadangan dan
beberapa akan hilang (dalam hal ini kasus, oleh meluap corong).

Kasus-kasus ini mungkin tampak mirip dengan pengirim, sebagai transmisi penyebab terlalu
cepat paket akan hilang. Namun, mereka memiliki penyebab yang berbeda dan panggilan untuk
solusi yang berbeda. Kami telah berbicara tentang solusi aliran-kontrol dengan variabel-
berukuran jendela. Sekarang kita akan mempertimbangkan solusi kontrol kemacetan. Sejak salah
satu dari masalah ini dapat terjadi, protokol transport akan membutuhkan umum untuk
menjalankan solusi kedua dan memperlambat jika salah masalah terjadi.
Protokol transport harus mengatur tingkat pengiriman tergantung pada bentuk umpan balik
dikembalikan oleh jaringan. lapisan jaringan yang berbeda mungkin kembali berbagai jenis
umpan balik. umpan balik mungkin eksplisit atau implisit, dan mungkin tepat atau tidak tepat.

Contoh eksplisit, desain yang tepat adalah ketika router memberitahu sumber tingkat di mana
mereka dapat mengirimkan desain dalam literatur seperti XCP (Kemacetan eksplisit Protocol)
beroperasi dengan cara ini (Katabi et al., 2002). Desain Eksplisit, tidak tepat dalam penggunaan
ECN (Explicit Congestion Pemberitahuan) dengan TCP. Di dalam desain, router mengatur bit
pada paket yang mengalami kemacetan untuk memperingatkan pengirim untuk memperlambat,
tapi mereka tidak memberitahu mereka betapa melambat.

Dalam desain lain, tidak ada sinyal eksplisit. TCP mengukur ulang-alik delay dan menggunakan
metrik sebagai sinyal untuk menghindari kemacetan (Wei et al., 2006). Akhirnya, dalam bentuk
kontrol kongesti yang paling umum di Internet saat ini, TCP dengan drop-ekor atau router RED,
packet loss disimpulkan dan digunakan untuk sinyal bahwa jaringan telah menjadi sesak. Ada
banyak varian dari bentuk TCP, termasuk TCP CUBIC, yang digunakan dalam Linux (Ha et al.,
2008). Kombinasi juga mungkin. Misalnya, Windows termasuk TCP Compound yang
menggunakan kedua packet loss dan delay sebagai sinyal umpan balik (Tan et al., 2006). Desain
ini diringkas dalam Gambar. 6-23

Jika sinyal eksplisit dan tepat diberikan, entitas transportasi bisa menggunakan sinyal bahwa
menyesuaikan tingkat ke titik operasi baru. Misalnya, jika XCP memberitahu pengirim
tingkat digunakan, pengirim mungkin hanya menggunakan tingkat itu. Dalam kasus lain,
bagaimanapun, beberapa dugaan terlibat. Dengan tidak adanya sinyal kemacetan, pengirim
harus menurunkan tarif mereka. Ketika sinyal kemacetan diberikan, pengirim harus
menurunkan tarif mereka. Cara di mana persentasenya meningkat atau menurun adalah
diberikan oleh hukum kontrol. Undang-undang ini memiliki pengaruh besar pada kinerja.

Chiu dan Jain (1989) mempelajari kasus umpan balik kemacetan biner dan menyimpulkan
AIMD (Additive Kenaikan multiplikatif Penurunan) adalah tepathukum kontrol untuk tiba di
titik operasi yang efisien dan adil. Berdebat ini kasus, mereka membangun sebuah argumen
grafis untuk kasus sederhana dari dua koneksi bersaing untuk bandwidth link tunggal. Grafik
pada Gambar. 6-24 menunjukkan bandwidth yang dialokasikan untuk pengguna 1 pada sumbu x
dan untuk pengguna 2 pada sumbu y. Ketika alokasi adil, baik pengguna akan menerima jumlah
yang sama bandwidth. Hal ini ditunjukkan oleh garis putus-putus keadilan. Ketika alokasi
berjumlah 100%, yang kapasitas link, alokasi efisien. Hal ini ditunjukkan dengan efisiensi putus-
putus garis. Sebuah sinyal kemacetan diberikan oleh jaringan untuk pengguna ketika Jumlah
alokasi mereka melintasi garis ini. Persimpangan garis-garis ini adalah yang diinginkan titik
operasi, ketika kedua pengguna memiliki bandwidth yang sama dan semua jaringan bandwidth
yang digunakan.

6.3.3 Masalah Wireless

protokol transportasi seperti TCP yang menerapkan kontrol kongesti harus independen dari
jaringan dan link layer yang mendasari teknologi. Yang baik teori, tetapi dalam prakteknya ada
masalah dengan jaringan nirkabel. Masalah utama adalah yang packet loss sering digunakan
sebagai sinyal kemacetan, termasuk oleh TCP seperti yang telah kita hanya dibahas. Jaringan
nirkabel kehilangan paket sepanjang waktu karena kesalahan transmisi.

Dengan hukum kontrol AIMD, throughput yang tinggi membutuhkan tingkat yang sangat kecil
packet loss. Analisis oleh Padhye et al. (1998) menunjukkan bahwa throughput naik sebagai
berbanding terbalik dengan kuadrat-akar tingkat packet loss. ini berarti apa yang ada dalam
praktek adalah bahwa tingkat kerugian untuk koneksi TCP cepat sangat kecil; 1% adalah tingkat
kerugian moderat, dan pada saat tingkat kerugian mencapai 10% sambungan secara efektif
berhenti kerja. Namun, untuk jaringan nirkabel seperti 802.11 LAN, frame rate hilangnya
minimal 10% yang umum. Perbedaan ini berarti bahwa, tindakan perlindungan absen, skema
kontrol kongesti yang menggunakan packet loss sebagai sinyal akan perlu koneksi throttle yang
berjalan lebih dari link nirkabel untuk harga yang sangat rendah.

Untuk berfungsi dengan baik, satu-satunya kerugian paket bahwa algoritma kontrol kemacetan
harus mengamati adalah kerugian karena bandwidth tidak cukup, tidak kerugian akibat transmisi
kesalahan. Salah satu solusi untuk masalah ini adalah untuk menutupi kerugian nirkabel dengan
menggunakan transmisi ulang melalui link nirkabel. Misalnya, 802.11 menggunakan stopand- a
menunggu protokol untuk menyampaikan setiap frame, transmisi mencoba kembali beberapa
kali jika perlu sebelum melaporkan kerugian paket ke lapisan yang lebih tinggi. Dalam kasus
normal, masing-masing paket disampaikan meskipun kesalahan transmisi sementara yang tidak
terlihat dengan lapisan yang lebih tinggi.

Gambar 6-26 menunjukkan jalan dengan link kabel dan nirkabel yang masking strategi yang
digunakan. Ada dua aspek yang perlu diperhatikan. Pertama, pengirim tidak selalu tahu bahwa
jalan berisi link wireless, karena semua itu melihat adalah link kabel untuk yang terpasang. jalur
internet heterogen dan tidak ada umum metode untuk pengirim untuk memberitahu apa link
terdiri jalan. Hal ini mempersulit masalah kontrol kemacetan, karena tidak ada cara mudah untuk
menggunakan satu protokol untuk link nirkabel dan protokol lain untuk link kabel.
Aspek kedua adalah teka-teki. Angka ini menunjukkan dua mekanisme yang didorong oleh
kerugian: bingkai link layer transmisi ulang, dan transportasi lapisan kemacetan kontrol. teka-
teki adalah bagaimana dua mekanisme tersebut dapat hidup berdampingan tanpa mendapatkan
bingung. Setelah semua, kerugian harus menyebabkan hanya satu mekanisme untuk mengambil
tindakan karena itu adalah salah satu kesalahan transmisi atau sinyal kemacetan. Hal ini tidak
bisa keduanya. Jikakedua mekanisme mengambil tindakan (mentransmisi frame dan
memperlambat mengirimkan rate) maka kita kembali ke masalah asli dari angkutan yang
berjalan jauh terlalu lambat atas link nirkabel. mertimbangkan teka-teki ini sejenak dan lihat
apakah Anda bisa mengatasinya.

Isu kedua dengan kontrol kemacetan lebih dari link nirkabel kapasitas variabel. Artinya,
kapasitas perubahan link wireless dari waktu ke waktu, kadang-kadang tiba-tiba, sebagai node
bergerak dan rasio signal-to-noise bervariasi dengan kondisi saluran berubah. Ini tidak seperti
link kabel yang kapasitas adalah tetap. Protokol transport harus beradaptasi dengan kapasitas
mengubah link nirkabel, jika tidak maka akan baik congest jaringan atau gagal untuk
menggunakan kapasitas yang tersedia.

Strategi ini layak karena algoritma kontrol kemacetan harus sudah menangani kasus pengguna
baru memasuki jaringan atau ada pengguna mengubah mereka mengirim tarif. Meskipun
kapasitas link kabel adalah tetap, perubahan perilakupengguna lain menyajikan dirinya sebagai
variabilitas dalam bandwidth yang tersedia untuk diberikan pengguna. Jadi adalah mungkin
untuk hanya menjalankan TCP jalan dengan 802.11 wireless menghubungkan dan mendapatkan
kinerja yang wajar.

Namun, ketika ada banyak variabilitas nirkabel, protokol transport yang dirancang untuk link
kabel mungkin memiliki kesulitan menjaga dan memberikan kinerja yang buruk. Solusi dalam
hal ini adalah protokol transport yang dirancang untuk link nirkabel. Pengaturan yang sangat
menantang adalah jaringan mesh nirkabel di mana beberapa, campur link nirkabel harus
menyeberang, rute berubah karena mobilitas, dan ada banyak kerugian. Penelitian di bidang ini
sedang berlangsung. Lihat Li et al. (2009) untuk contoh desain protokol transport nirkabel.
6.4 THE PROTOKOL INTERNET TRANSPORT: UDP

Internet memiliki dua protokol utama pada lapisan transport, connectionless sebuah protokol dan
satu berorientasi koneksi. Protokol saling melengkapi. Protokol connectionless adalah UDP. Itu
tidak hampir tidak melampaui pengiriman paket antara aplikasi, aplikasi membiarkan
membangun protokol mereka sendiri di atas sebagai dibutuhkan. Protokol berorientasi koneksi
adalah TCP. Itu tidak hampir semuanya. Saya membuat koneksi dan menambah kehandalan
dengan transmisi ulang, bersama dengan kontrol aliran dan kontrol kemacetan, semua atas nama
aplikasi yang menggunakannya.

Pada bagian berikut, kita akan mempelajari UDP dan TCP. Kami akan mulai dengan UDP
karena sederhana. Kami juga akan melihat dua penggunaan UDP. Sejak UDP adalah protokol
lapisan transport yang biasanya berjalan di sistem operasi dan protokol bahwa penggunaan UDP
biasanya berjalan di ruang pengguna, penggunaan ini mungkin dianggap aplikasi. Namun, teknik
yang mereka gunakan adalah berguna untuk banyak aplikasi dan lebih baik dianggap milik
layanan transportasi, jadi kita akan menutupi mereka di sini.

6.4.1 Pengantar UDP

Protokol internet mendukung protokol transport connectionless disebut UDP (User Datagram
Protocol). UDP menyediakan cara bagi aplikasi untuk mengirim dikemas datagrams IP tanpa
harus membuat sambungan. UDP digambarkan dalam RFC 768.

UDP mengirimkan segmen yang terdiri dari header 8-byte diikuti dengan payload. header
ditunjukkan pada Gambar. 6-27. Dua port berfungsi untuk mengidentifikasi titik akhir dalam
sumber dan tujuan mesin. Ketika paket UDP tiba, payload yang diserahkan ke proses melekat
pada port tujuan. keterikatan ini terjadi ketika BIND primitif atau yang serupa digunakan, seperti
yang kita lihat diAra. 6-6 untuk TCP (proses pengikatan adalah sama untuk UDP). Pikirkan port
sebagai kotak pesan bahwa aplikasi dapat menyewa untuk menerima paket. Kami akan memiliki
lebih banyak untuk mengatakan tentang mereka ketika kita menjelaskan TCP, yang juga
menggunakan port. Bahkan, nilai utama UDP lebih hanya menggunakan IP baku adalah
penambahan sumber dan tujuan pelabuhan. Tanpa bidang pelabuhan, lapisan transport tidak akan
tahu apa yang harus dilakukan dengan masing-masing paket yang masuk. Dengan mereka,
memberikan segmen tertanam untuk aplikasi yang benar.

Port sumber terutama dibutuhkan ketika balasan harus dikirim kembali ke sumber. Dengan
menyalin port bidang Sumber dari segmen yang masuk ke dalam bidang pelabuhan tujuan dari
segmen keluar, proses pengiriman balasan bisa menentukan proses pada mesin pengirim adalah
untuk mendapatkannya. UDP panjang bidang mencakup header 8-byte dan data. Minimum
panjangnya 8 byte, untuk menutupi header. Panjang maksimum adalah 65.515 byte, yang lebih
rendah dari jumlah terbesar yang akan cocok di 16 bit karena batas ukuran pada paket IP. Sebuah
Checksum opsional juga disediakan untuk keandalan ekstra. Ini checksum yang header, data, dan
pseudoheader IP konseptual. Ketika melakukan perhitungan ini, bidang Checksum diatur ke nol
dan bidang data melangkah keluar dengan tambahan nol byte jika panjangnya adalah ganjil.
Algoritma checksum adalah hanya untuk menambahkan semua kata-kata 16-bit untuk
melengkapi seseorang dan mengambil satumelengkapi dari jumlah. Sebagai konsekuensi, ketika
penerima melakukan perhitungan pada seluruh segmen, termasuk bidang Checksum, hasilnya
harus 0. Jika checksum tidak dihitung, itu disimpan sebagai 0, karena dengan kebetulan senang
dari seseorang pelengkap aritmatika benar dihitung 0 disimpan karena semua 1s. Namun,
mengubahnya off adalah bodoh kecuali kualitas data tidak masalah (misalnya, untuk digital
pidato).

6.4.2 Remote Procedure Call

Dalam arti tertentu, mengirim pesan ke host remote dan mendapatkan balasan kembali adalah
banyak seperti membuat panggilan fungsi dalam bahasa pemrograman. Dalam kedua kasus,
Anda mulai dengan satu atau lebih parameter dan Anda mendapatkan kembali hasilnya.
Pengamatan ini memiliki orang yang dipimpin untuk mencoba untuk mengatur interaksi
permintaan-balasan pada jaringan akan dilemparkan dalam bentuk prosedur panggilan.
Pengaturan semacam itu membuat aplikasi jaringan jauh mudah untuk program dan lebih akrab
untuk menangani. Misalnya, hanya membayangkan prosedur bernama get alamat IP (nama host)
yang bekerja dengan mengirimkan UDPpaket ke server DNS dan menunggu jawaban, waktu
keluar dan mencoba lagi jikasatu tidak akan datang cukup cepat. Dengan cara ini, semua rincian
jaringan dapat disembunyikan dari programmer.

Pekerjaan utama di daerah ini dilakukan oleh Birrell dan Nelson (1984). Pendeknya, apa Birrell
dan Nelson menyarankan itu memungkinkan program untuk memanggil prosedur terletak di
remote host. Ketika proses pada mesin 1 panggilan prosedur di mesin 2, proses pemanggilan atas
1 ditangguhkan dan pelaksanaan yang disebut prosedur Dibutuhkan tempat di 2. Informasi dapat
diangkut dari pemanggil ke callee dalam parameter dan dapat datang kembali hasil prosedur.
Tidak ada pesan lewatterlihat untuk programmer aplikasi. Teknik ini dikenal sebagai RPC
(Remote Procedure Call) dan telah menjadi dasar untuk banyak aplikasi jaringan. Secara
tradisional, prosedur panggilan dikenal sebagai klien dan disebut
Prosedur ini dikenal sebagai server, dan kami akan menggunakan nama-nama itu di sini juga.

RPC adalah untuk membuat panggilan prosedur jauh terlihat sebanyak mungkin seperti satu
lokal. Dalam bentuk yang paling sederhana, untuk memanggil prosedur remote, klien Program
harus terikat dengan prosedur perpustakaan kecil, yang disebut client stub, yang merupakan
prosedur server dalam ruang alamat klien. Demikian pula, server terikat dengan prosedur yang
disebut server stub. Prosedur ini menyembunyikan fakta bahwa panggilan prosedur dari klien ke
server tidak lokal. Langkah-langkah yang sebenarnya dalam membuat RPC ditunjukkan pada
Gambar. 6-29. Langkah 1 adalah klien memanggil client stub. panggilan ini adalah panggilan
prosedur lokal, dengan parameter didorong ke stack dengan cara biasa. Langkah 2 adalah rintisan
klien kemasan parameter dalam pesan dan membuat system call untuk mengirim pesan.
Pengepakan parameter disebut marshaling. Langkah 3 adalah sistem operasi mengirimkan pesan
dari mesin klien ke mesin server. Langkah 4 adalah operasi sistem lewat paket yang masuk ke
server stub. Akhirnya, langkah 5 adalah server stub memanggil prosedur server dengan
parameter unmarshaled. Balasan menelusuri jalan yang sama ke arah lain. Item kunci untuk
dicatat di sini adalah bahwa prosedur klien, yang ditulis oleh pengguna, hanya membuat normal
(yaitu, lokal) panggilan prosedur ke client stub, yang memiliki yang samanama sebagai prosedur
Server. Sejak prosedur klien dan stub klien berada di ruang alamat yang sama, parameter yang
lulus dengan cara yang biasa. Demikian pula, Prosedur server disebut dengan prosedur di ruang
alamat dengan parameter mengharapkan. Untuk prosedur Server, tidak ada yang tidak biasa.
Dengan cara ini, bukan I / O yang dilakukan pada soket, jaringan komunikasi dilakukan dengan
berpura-pura normalpanggilan prosedur.

Dalam beberapa kasus, trik dapat digunakan untuk memungkinkan untuk lulus pointer.
Seharusnya bahwa parameter pertama adalah pointer ke integer, k. Klien stub bisak marshal dan
kirimkan bersama ke server. Server stub kemudian menciptakan pointer ke server dan lolos ke
prosedur, hanya karena mengharapkan. Ketika prosedur Server kontrol kembali ke server stub,
yang terakhir mengirim k kembali ke client, di mana baru disalin di atas yang lama, hanya
dalam kasus server berubah. Akibatnya, urutan panggilan standar call-by-referensi telah
digantikan oleh panggilan-bycopy- mengembalikan. Sayangnya, trik ini tidak selalu bekerja,
misalnya, jika pointer menunjuk ke grafik atau struktur data yang kompleks lainnya. Untuk
alasan ini, beberapa pembatasan harus ditempatkan pada parameter untuk prosedur yang disebut
jarak jauh, seperti yang kita akan melihat Masalah kedua adalah bahwa dalam bahasa diketik
lemah, seperti C, itu sempurna hukum untuk menulis prosedur yang menghitung hasil kali dalam
dua vektor (array), tanpa menentukan seberapa besar salah satu adalah. Masing-masing bisa
dihentikan oleh khusus nilai hanya diketahui panggilan dan disebut prosedur. Dalam keadaan ini,
itu pada dasarnya tidak mungkin untuk rintisan klien untuk mengumpulkan parameter: itu tidak
memiliki cara untuk menentukan seberapa besar mereka. Masalah ketiga adalah bahwa hal itu
tidak selalu mungkin untuk menyimpulkan jenis parameter, bahkan dari spesifikasi formal atau
kode itu sendiri. Contohnya adalah printf, yang mungkin memiliki sejumlah parameter
(setidaknya satu), dan parameter bisa menjadi campuran sewenang-wenang dari bilangan bulat,
celana pendek, rindu, karakter, string, floating nomor titik berbagai panjang, dan jenis lainnya.
Mencoba untuk memanggil printf sebagai prosedur remote akan hampir mustahil karena C begitu
permisif. Namun, aturan mengatakan RPC yang dapat digunakan akan menjadi populer asalkan
dengan banyak programmer Anda tidak program di C (atau C ++).

6.4.3 Protokol Transportasi Real-Time

Client-server RPC adalah salah satu daerah di mana UDP banyak digunakan. Satu lagi adalah
untuk aplikasi multimedia real-time. Secara khusus, sebagai radio internet, telepon Internet,
musik-on-demand, videoconferencing, video-on-demand, dan multimedia lainnya aplikasi
menjadi lebih umum, orang telah menemukan bahwa setiap aplikasi yang menciptakan kembali
kurang lebih real-time transport protocol yang sama. Secara bertahap menjadi jelas bahwa
memiliki real-time transport protocol generik untuk beberapa aplikasi akan menjadi idea.s baik

Dengan demikian adalah RTP (Real-time Transport Protocol) lahir. Hal ini dijelaskan dalam
RFC 3550 dan sekarang digunakan secara luas untuk aplikasi multimedia. Kami akan
menjelaskan dua aspek transportasi real-time. Yang pertama adalah protokol RTP untuk
mengangkut data video dalam paket audio dan. yang kedua adalah proses yang terjadi,
sebagian besar pada penerima, untuk bermain keluar audio dan video pada waktu yang tepat. Ini
fungsi masuk ke dalam tumpukan protokol seperti ditunjukkan pada Gambar. 6-30.

RTP biasanya berjalan di ruang pengguna lebih UDP (dalam sistem operasi). beroperasi
sebagai berikut. Aplikasi multimedia terdiri dari beberapa audio, video, teks, dan aliran
kemungkinan lainnya. Ini dimasukkan ke perpustakaan RTP, yang di ruang pengguna bersama
dengan aplikasi. Perpustakaan ini multiplexes sungai dan mengkodekan mereka dalam paket
RTP, yang barang ke soket. Pada sistem operasi sisi soket, paket UDP yang dihasilkan untuk
membungkus paket RTP dan diserahkan kepada IP untuk transmisi melalui link seperti Ethernet.
Proses sebaliknya terjadi pada penerima. Aplikasi multimedia akhirnya menerima multimedia
data dari perpustakaan RTP. Hal ini bertanggung jawab untuk bermain keluar media. Itu
stack protokol untuk situasi ini ditunjukkan pada Gambar. 6-30 (a). Paket bersarang adalah
ditunjukkan pada Gambar. 6-30 (b). Sebagai konsekuensi dari desain ini, agak sulit untuk
mengatakan yang lapisan RTP adalah di. Sejak itu berjalan di ruang pengguna dan terkait dengan
program aplikasi, itu pasti terlihat seperti protokol aplikasi. Di sisi lain, itu adalah generik,
aplikasi dependent protokol yang hanya menyediakan fasilitas transportasi, sehingga juga terlihat
seperti transportasi protokol. Mungkin gambaran terbaik adalah bahwa hal itu adalah protokol
transportyang kebetulan dilaksanakan di lapisan aplikasi, yang mengapa kita menutupinya dalam
bab ini.

RTP-Real-time Transport Protocol

Fungsi dasar dari RTP adalah multipleks beberapa real-time data stream kesatu aliran paket
UDP. Aliran UDP dapat dikirim ke tujuan tunggal (Unicasting) atau ke beberapa tujuan
(multicasting). Karena RTP hanya menggunakan UDP normal, paket yang tidak diperlakukan
khusus oleh router kecuali beberapa yang normal IP kualitas-of-service fitur diaktifkan. Secara
khusus, tidak ada yang istimewa jaminan tentang pengiriman, dan paket bisa hilang, tertunda,
rusak, dll

Format RTP berisi beberapa fitur untuk membantu penerima bekerja dengan multimedia
informasi. Setiap paket yang dikirim dalam aliran RTP diberikan nomor satu lebih tinggi dari
pendahulunya. penomoran ini memungkinkan tujuan untuk menentukan apakah setiap paket
yang hilang. Jika sebuah paket hilang, tindakan terbaik untuk tujuan untuk mengambil sampai ke
aplikasi. Ini mungkin untuk melewatkan frame video jika paket yangmembawa data video, atau
untuk mendekati nilai yang hilang dengan interpolasi jikapaket membawa data audio. Transmisi
bukan pilihan yang praktis sejak paket dikirim ulang mungkin akan datang terlambat untuk
menjadi berguna. Sebagai konsekuensi, RTP tidak memiliki pengakuan, dan tidak ada
mekanisme untuk transmisi ulang permintaan.

DUNIA WEB
HALAMAN 697

Memperluas biaya disk menjatuhkan secara dramatis, sehingga menyimpan seluruh Web
mungkin terus menjadi layak untuk perusahaan besar di masa mendatang. Membuat rasa data ini
adalah masalah lain. Anda dapat menghargai bagaimana XML dapat membantu program
mengekstrak struktur data dengan mudah, sementara ad hoc format akan menyebabkan banyak
dugaan. Ada juga isu konversi antara format, dan bahkan terjemahan antara bahasa. Tetapi
bahkan mengetahui struktur Data ini hanya bagian dari masalah. The agak sulit adalah untuk
memahami apa artinya. Ini adalah di mana banyak nilai dapat dibuka, dimulai dengan halaman
hasil yang lebih relevan untuk permintaan pencarian. Tujuan utamanya adalah untuk dapat
menjawab pertanyaan-pertanyaan, misalnya, mana untuk membeli murah tapi layak oven
pemanggang roti di kota Anda. Aspek ketiga dari pencarian Web adalah bahwa hal itu telah
datang untuk memberikan tingkat yang lebih tinggi dari penamaan. Tidak perlu untuk mengingat
URL yang panjang jika hanya dapat diandalkan (atau mungkin lebih) untuk mencari halaman
web dengan nama seseorang, dengan asumsi bahwa Anda lebih baik mengingat nama dari URL.
Strategi ini semakin sukses.

Dengan cara yang sama bahwa nama DNS diturunkan alamat IP untuk komputer, Web pencarian
relegating URL ke komputer. Juga mendukung pencarian adalah bahwa hal itu mengoreksi ejaan
dan mengetik kesalahan, sedangkan jika Anda mengetik URL yang salah, Anda mendapatkan
Halaman yang salah. Akhirnya, pencarian Web menunjukkan sesuatu yang tak ada hubungannya
dengan desain jaringan tapi banyak yang harus dilakukan dengan pertumbuhan beberapa layanan
Internet: ada banyak uang dalam iklan. Iklan adalah mesin ekonomi yang telah mendorong
pertumbuhan pencarian Web. Perubahan utama dari iklan cetak adalah kemampuan untuk iklan
sasaran tergantung pada apa yang orang mencari, untuk meningkatkan relevansi iklan. Variasi
pada mekanisme lelang digunakan untuk cocok dengan permintaan pencarian ke iklan yang
paling berharga (Edelman et al., 2007).

Model baru ini telah menimbulkan masalah baru, tentu saja, seperti penipuan klik, di yang
program meniru pengguna dan klik pada iklan untuk menyebabkan pembayaran yang belum
cukup diterima.

7.4 STREAMING AUDIO DAN VIDEO

Aplikasi web dan mobile Web tidak hanya perkembangan menarik dalam penggunaan jaringan.
Bagi banyak orang, audio dan video adalah grail suci jaringan. Ketika kata '' multimedia ''
disebutkan, baik propellerheads dan pakaian mulai ngiler seolah aba-aba. Mantan melihat besar
teknis tantangan dalam menyediakan voice over IP dan video-on-demand untuk setiap komputer.
Yang terakhir melihat keuntungan sama besar di dalamnya.

Sebagai samping, multimedia Istilah ini sering digunakan dalam konteks internet berarti video
dan audio. Secara harfiah, multimedia hanya dua atau lebih media yang. Bahwa Definisi
membuat buku ini presentasi multimedia, karena mengandung teks dan grafis (angka). Namun,
itu mungkin bukan apa yang ada dalam pikiran, jadi kami menggunakan istilah '' multimedia ''
menyiratkan dua atau lebih media terus menerus, yaitu, media yang harus dimainkan selama
beberapa interval waktu yang ditentukan. Kedua Media biasanya video dengan audio, yaitu,
gambar dengan suara bergerak. Banyak orang juga merujuk audio murni, seperti telepon Internet
atau radio internet, seperti multimedia juga, yang jelas tidak. Sebenarnya, istilah yang lebih baik
untuk semua ini kasus ini media streaming. Meskipun demikian, kami akan mengikuti kawanan
dan serta mempertimbangkan real-time audio menjadi multimedia.

7.4.1 Digital Audio

Audio (suara) gelombang akustik (tekanan) gelombang satu dimensi. Kapan

gelombang akustik memasuki telinga, bergetar gendang telinga, sehingga menyebabkan tulang
kecil telinga bagian dalam bergetar bersamaan dengan itu, mengirimkan pulsa saraf ke otak. Ini
pulsa dianggap sebagai suara oleh pendengar. Dalam cara yang sama, ketika akustik
gelombang pemogokan mikrofon, mikrofon menghasilkan sinyal listrik, yang mewakili
amplitudo suara sebagai fungsi waktu.

Audio digital adalah representasi digital dari gelombang audio yang dapat digunakan untuk
menciptakan itu. gelombang audio dapat dikonversi ke bentuk digital oleh ADC (Analogto-
Digital Converter). ADC mengambil tegangan listrik sebagai masukan dan menghasilkan
bilangan biner sebagai output. Pada Gambar. 7-42 (a) kita melihat contoh dari gelombang sinus.
7.4.2 Digital Video

Sekarang kita tahu semua tentang telinga, sekarang saatnya untuk beralih ke mata. (Bagian ini
tidak diikuti oleh salah satu di hidung.) Mata manusia memiliki properti yang ketika gambar
muncul pada retina, gambar dipertahankan untuk beberapa jumlah milidetik sebelum membusuk.
Jika urutan gambar diambil pada 50 gambar / detik, mata tidak melihat bahwa itu adalah melihat
gambar diskrit. Semua sistem video mengeksploitasi prinsip ini untuk menghasilkan gambar
bergerak.

Representasi digital sederhana video adalah urutan frame, masing-masing terdiri

dari kotak persegi panjang dari elemen gambar, atau pixel. Setiap pixel bisa menjadi
satu bit, untuk mewakili hitam atau putih. Namun, kualitas sistem tersebut
mengerikan. Coba gunakan editor foto favorit Anda untuk mengkonversi piksel dari warna
gambar untuk (warna dan tidak abu-abu) hitam dan putih.

Kompresi Video

Harus jelas dari diskusi kami video digital yang kompresi penting untuk mengirimkan video
melalui Internet. Bahkan video berkualitas standar dengan 640 dengan frame 480 pixel, 24 bit
informasi warna per pixel, dan 30 frame / sec. Dibutuhkan lebih dari 200 Mbps. Ini jauh
melebihi band width dengan yang sebagian besar kantor perusahaan terhubung ke Internet,
membiarkan pengguna rumah sendirian, dan ini adalah untuk satu streaming video. Sejak
transmisi video terkompresi benar-benar keluar dari pertanyaan, setidaknya lebih dari jaringan
luas, satu-satunya harapan adalah bahwa kompresi besar adalah mungkin. Untungnya, tubuh
besar penelitian selama beberapa dekade terakhir telah menyebabkan banyak teknik kompresi
dan algoritma yang membuat transmisi video layak.

Banyak format yang digunakan untuk video yang dikirimkan melalui Internet, beberapa
proprietary dan beberapa standar. Pengkodean yang paling populer adalah MPEG di nya
berbagai bentuk. Ini merupakan standar terbuka yang ditemukan di file dengan mpg dan mp4
ekstensi, serta seperti dalam format wadah lainnya. Pada bagian ini, kita akan melihat MPEG
untuk mempelajari bagaimana kompresi video dicapai. Untuk memulai, kita akan melihat
kompresi masih gambar dengan format JPEG. Sebuah video hanya urutan gambar (ditambah
suara). Satu cara untuk kompres video untuk mengkodekan setiap gambar dalam suksesi. Untuk
pendekatan pertama, MPEG hanya pengkodean JPEG dari setiap frame, ditambah beberapa fitur
tambahan untuk menghapus redundansi di frame.

7.4.5 Real-Time Conferencing

Sekali waktu, panggilan suara yang dibawa masyarakat beralih telepon jaringan, dan lalu lintas
jaringan terutama suara lalu lintas, dengan sedikit data lalu lintas di sana-sini. Kemudian datang
internet, dan Web. Lalu lintas data tumbuh dan tumbuh, sampai tahun 1999 ada banyak lalu
lintas data trafik suara (voice sejak sekarang didigitalkan, keduanya dapat diukur dalam bit).
Pada tahun 2002, volume lalu lintas data adalah urutan besarnya lebih dari volume lalu lintas
suara dan masih tumbuh secara eksponensial, dengan lalu lintas suara tinggal hampir datar.

H.323

Satu hal yang jelas bagi semua orang sebelum panggilan suara dan video dibuat
melalui Internet adalah bahwa jika masing-masing vendor dirancang protokol stack sendiri,
sistem tidak akan bekerja. Untuk menghindari masalah ini, sejumlah pihak yang berkepentingan
mendapat bersama di bawah naungan ITU untuk bekerja di luar standar. Pada tahun 1996, ITU
mengeluarkan rekomendasi H.323, berjudul '' Sistem Telepon Visual dan Peralatan untuk lokal
Area Networks Yang Menyediakan Kualitas Non-Dijamin Layanan. '' Hanya industri telepon
akan memikirkan nama seperti itu. Itu cepat berubah menjadi '' packet berdasarkan Multimedia
Sistem Komunikasi '' di tahun 1998 revisi. H.323 adalah dasar untuk sistem Internet
conferencing luas pertama. Ini tetap yang paling banyak digunakan solusi, dalam versi ketujuh
pada 2009.

H.323 lebih dari gambaran arsitektur telepon Internet dari tertentu protokol. Itu referensi
sejumlah besar protokol khusus untuk pidato coding, call setup, signaling, transportasi data, dan
daerah lain daripada menetapkan hal ini sendiri. Model umum digambarkan pada Gambar. 7-58.
Di pusat adalah gateway yang menghubungkan Internet untuk jaringan telepon. Ini berbicara
H.323 protokol di sisi Internet dan protokol PSTN di sisi telepon. Itu perangkat berkomunikasi
disebut terminal. Sebuah LAN mungkin memiliki gatekeeper, yang mengontrol titik akhir di
bawah yurisdiksinya, yang disebut zona.

Sebuah jaringan telepon membutuhkan sejumlah protokol. Untuk mulai dengan, ada
protokol untuk encoding dan decoding audio dan video. representasi telepon standar
dari saluran suara tunggal sebagai 64 kbps audio digital (8000 sampel dari 8 bit per detik)
didefinisikan dalam ITU rekomendasi G.711. Semua sistem H.323 harus mendukung G.711.
pengkodean lain yang kompres pidato yang diizinkan, tetapi tidak wajib. Mereka menggunakan
algoritma kompresi yang berbeda dan membuat pengorbanan yang berbeda antara kualitas dan
bandwidth. Untuk video, bentuk MPEG dari kompresi video bahwa kita dijelaskan di atas
didukung, termasuk H.264.

Sejak beberapa algoritma kompresi yang diizinkan, protokol yang diperlukan untuk
memungkinkan terminal untuk bernegosiasi mana mereka akan menggunakan. Protokol ini
disebut H.245. Hal ini juga melakukan negosiasi aspek lain dari koneksi seperti bit
menilai. RTCP kebutuhan untuk kontrol saluran RTP. Juga diperlukan adalah protokol
untuk membangun dan melepaskan koneksi, memberikan nada panggil, membuat dering
suara, dan sisanya dari telepon standar. ITU Q.931 digunakan di sini. Itu
terminal membutuhkan protokol untuk berbicara dengan penjaga gerbang (jika ada) juga. Untuk
tujuan ini, H.225 digunakan. Saluran PC-to-gatekeeper itu mengelola disebut
RAS (Pendaftaran / Penerimaan / Status) channel. Saluran ini memungkinkan terminal
untuk bergabung dan meninggalkan zona tersebut, meminta dan kembali bandwidth, dan
menyediakan statusupdate, antara lain. Akhirnya, sebuah protokol yang diperlukan untuk data
actual transmisi. RTP di atas UDP digunakan untuk tujuan ini. Hal ini dikelola oleh RTCP,
sebagai biasa. Posisi semua protokol ini ditunjukkan pada Gambar. 7-59.

Untuk melihat bagaimana protokol ini cocok bersama, mempertimbangkan kasus terminal PC di
LAN (dengan gatekeeper) memanggil telepon jarak jauh. PC pertama memiliki untuk
menemukan gatekeeper, sehingga mengirimkan paket gatekeeper penemuan UDP ke port
1718. Ketika penjaga gerbang merespon, PC belajar alamat IP gatekeeper ini. Sekarang PC
register dengan penjaga gerbang dengan mengirim pesan RAS dalam UDP paket. Setelah itu
telah diterima, PC mengirimkan penjaga gerbang pengakuan RAS pesan yang meminta
bandwidth. Hanya setelah bandwidth yang telah diberikan dapat menghubungi penyiapan
dimulai. Ide meminta bandwith di muka adalah untuk memungkinkan gatekeeper untuk
membatasi jumlah panggilan. Hal ini kemudian dapat menghindari over subscribing keluar yang
baris untuk membantu memberikan kualitas yang diperlukan layanan.

Protokol H.245 sekarang digunakan untuk menegosiasikan parameter panggilan. Saya t

menggunakan saluran kontrol H.245, yang selalu terbuka. Masing-masing pihak mulai keluar
dengan mengumumkan kemampuan, misalnya, apakah itu bisa menangani video (H.323 dapat
menangani video) atau panggilan konferensi, yang codec mendukung, dll Setelah masing-masing
pihak yang tahu apa yang lain dapat menangani, dua saluran data yang searah ditetapkan
dan codec dan parameter lainnya ditugaskan untuk masing-masing. Karena setiap sisi mungkin
memiliki peralatan yang berbeda, sangatlah mungkin bahwa codec di depan dan
saluran terbalik berbeda. Setelah semua negosiasi selesai, aliran data bisa
mulai menggunakan RTP. Hal ini dikelola menggunakan RTCP, yang memainkan peran dalam
kemacetan kontrol. Jika video hadir, RTCP menangani sinkronisasi audio / video. Itu
berbagai saluran ditunjukkan pada Gambar. 7-60. Ketika salah satu pihak menutup, Q.931 yang
panggilan saluran sinyal digunakan untuk meruntuhkan koneksi setelah panggilan telah
selesai dalam rangka untuk membebaskan sumber daya tidak lagi diperlukan.

Bila panggilan diakhiri, kontak PC memanggil penjaga lagi dengan pesan RAS untuk
melepaskan bandwidth telah ditetapkan. Atau, itu dapat membuat panggilan lain. Kami tidak
mengatakan apa-apa tentang kualitas pelayanan sebagai bagian dari H.323, bahkan meskipun
kami telah mengatakan itu adalah bagian penting dari membuat real-time conferencing a
keberhasilan. Alasannya adalah bahwa QoS berada di luar lingkup H.323. Jika mendasari
jaringan ini mampu menghasilkan stabil, koneksi jitter-bebas dari panggilan tersebut PC ke
gateway, QoS pada panggilan akan baik; jika tidak, tidak akan. Namun, sebagian dari panggilan
di sisi telepon akan jitter-bebas, karena itu adalah bagaimana jaringan telepon dirancang.