Bagikan melalui

Protocol-Independent Data Di Luar Band

  • Artikel

Abstraksi soket aliran mencakup gagasan data out of band (OOB). Banyak protokol memungkinkan bagian data masuk ditandai sebagai khusus dalam beberapa cara, dan blok data khusus ini dapat dikirimkan kepada pengguna dari urutan normal. Contohnya termasuk data yang dipercepat dalam X.25 dan protokol OSI lainnya, dan data mendesak dalam penggunaan TCP BSD UNIX. Bagian berikut menjelaskan penanganan data OOB secara independen protokol. Diskusi data OOB yang diterapkan menggunakan data mendesak TCP mengikuti penjelasan independen protokol. Dalam setiap diskusi, penggunaan recv juga menyiratkan recvfrom, WSARecv, dan WSARecvFrom, dan referensi ke WSAAsyncSelect juga berlaku untuk WSAEventSelect.

Data OOB Independen Protokol

Data OOB adalah saluran transmisi yang secara logis independen yang terkait dengan setiap pasangan soket aliran yang terhubung. Data OOB dapat dikirimkan kepada pengguna secara independen dari data normal. Abstraksi mendefinisikan bahwa fasilitas data OOB harus mendukung pengiriman yang andal setidaknya satu blok data OOB pada satu waktu. Blok data ini dapat berisi setidaknya satu byte data, dan setidaknya satu blok data OOB dapat tertunda pengiriman kepada pengguna kapan saja. Untuk protokol komunikasi yang mendukung sinyal dalam band (seperti TCP, di mana data mendesak dikirimkan secara berurutan dengan data normal), sistem biasanya mengekstrak data OOB dari aliran data normal dan menyimpannya secara terpisah (meninggalkan celah dalam aliran data normal). Ini memungkinkan pengguna untuk memilih antara menerima data OOB secara berurutan dan menerimanya secara berurutan tanpa harus menyangga semua data yang mengintervensi. Dimungkinkan untuk mengintip data out-of-band (OOB).

Pengguna dapat menentukan apakah ada data OOB yang menunggu untuk dibaca menggunakan fungsi ioctlsocket atau WSAIoctl dengan IOCTL SIOCATMARK . Untuk protokol di mana konsep posisi blok data OOB dalam aliran data normal bermakna, seperti TCP, penyedia layanan Windows Sockets mempertahankan penanda konseptual yang menunjukkan posisi byte terakhir data OOB dalam aliran data normal. Ini tidak diperlukan untuk implementasi fungsi ioctlsocket atau WSAIoctl yang mendukung SIOCATMARK. Kehadiran atau tidak adanya data OOB semuanya diperlukan.

Untuk protokol di mana konsep posisi blok data OOB dalam aliran data normal bermakna, aplikasi mungkin memproses data out-of-band sebaris, sebagai bagian dari aliran data normal. Ini dicapai dengan mengatur opsi soket SO_OOBINLINE dengan fungsi setsockopt . Untuk protokol lain di mana blok data OOB benar-benar independen dari aliran data normal, mencoba mengatur SO_OOBINLINE menghasilkan kesalahan. Aplikasi dapat menggunakan fungsi ioctlsocket atau WSAIoctl dengan SIOCATMARK IOCTL untuk menentukan apakah ada data OOB yang belum dibaca sebelum tanda. Misalnya, ini dapat menggunakan informasi ini untuk menyinkronkan ulang dengan rekan-rekannya dengan memastikan bahwa semua data hingga tanda di aliran data dibuang jika sesuai.

Dengan SO_OOBINLINE dinonaktifkan (pengaturan default):

  • Windows Sockets memberi tahu aplikasi peristiwa FD_OOB, jika aplikasi yang terdaftar untuk pemberitahuan dengan WSAAsyncSelect, dengan cara yang sama persis FD_READ digunakan untuk memberi tahu adanya data normal. Artinya, FD_OOB diposting ketika data OOB tiba tanpa data OOB yang sebelumnya diantrekan. FD_OOB juga diposting saat data dibaca menggunakan bendera MSG_OOB sementara beberapa data OOB tetap diantrekan setelah operasi baca kembali. FD_READ pesan tidak diposting untuk data OOB.
  • Windows Sockets kembali dari pilih dengan set soket exceptfds yang sesuai jika data OOB diantrekan pada soket.
  • Aplikasi dapat memanggil recv dengan MSG_OOB untuk membaca blok data mendesak kapan saja. Blok data OOB melompati antrean.
  • Aplikasi dapat memanggil recv tanpa MSG_OOB untuk membaca aliran data normal. Blok data OOB tidak muncul di aliran data dengan data normal. Jika data OOB tetap ada setelah panggilan ke recv, Windows Sockets memberi tahu aplikasi dengan FD_OOB atau dengan exceptfd saat menggunakan pilih.
  • Untuk protokol di mana data OOB memiliki posisi dalam aliran data normal, satu operasi recv tidak mencakup posisi tersebut. Satu recv mengembalikan data normal sebelum tanda, dan recv kedua diperlukan untuk mulai membaca data setelah tanda.

Dengan SO_OOBINLINE diaktifkan:

  • FD_OOB pesan tidak diposting untuk data OOB. Data OOB diperlakukan seperti biasa untuk tujuan fungsi pilih dan WSAAsyncSelect , dan ditunjukkan dengan mengatur soket dalam readfds atau dengan mengirim pesan FD_READ masing-masing.
  • Aplikasi tidak dapat memanggil recv dengan bendera MSG_OOB diatur untuk membaca blok data OOB. Kode kesalahan WSAEINVAL dikembalikan.
  • Aplikasi dapat memanggil recv tanpa bendera MSG_OOB diatur. Setiap data OOB dikirimkan dalam urutan yang benar dalam aliran data normal. Data OOB tidak pernah dicampur dengan data normal. Harus ada tiga permintaan baca untuk melewati data OOB. Yang pertama mengembalikan data normal sebelum blok data OOB, yang kedua mengembalikan data OOB, yang ketiga mengembalikan data normal setelah data OOB. Dengan kata lain, batas blok data OOB dipertahankan.

Rutinitas WSAAsyncSelect sangat cocok untuk menangani pemberitahuan keberadaan data di luar band saat SO_OOBINLINE nonaktif.

Data OOB dalam TCP

Penting

Diskusi berikut tentang data out-of-band (OOB), yang diimplementasikan menggunakan data mendesak TCP, mengikuti model yang digunakan dalam distribusi perangkat lunak Berkeley. Pengguna dan pelaksana harus menyadari bahwa:

 

  • Ada, saat ini, dua interpretasi RFC 793 yang bertentangan (di mana konsep diperkenalkan).

  • Implementasi data OOB dalam Berkeley Software Distribution (BSD) tidak sesuai dengan Persyaratan Host yang ditentukan dalam RFC 1122.

    Secara khusus, pointer mendesak TCP di BSD menunjuk ke byte setelah byte data mendesak, dan pointer mendesak TCP yang mematuhi RFC menunjuk ke byte data mendesak. Akibatnya, jika aplikasi mengirim data mendesak dari implementasi yang kompatibel dengan BSD ke implementasi yang kompatibel dengan RFC 1122, penerima membaca byte data mendesak yang salah (membaca byte yang terletak setelah byte yang benar dalam aliran data sebagai byte data mendesak).

    Untuk meminimalkan masalah interoperabilitas, penulis aplikasi disarankan untuk tidak menggunakan data OOB kecuali ini diperlukan untuk beroperasi dengan layanan yang ada. Pemasok Windows Sockets didesak untuk men dokumentasikan semantik OOB (BSD atau RFC 1122) yang diterapkan produk mereka.

Kedatangan segmen TCP dengan set bendera URG (untuk mendesak) menunjukkan adanya satu byte data OOB dalam aliran data TCP. Blok data OOB berukuran satu byte. Penunjuk mendesak adalah offset positif dari nomor urutan saat ini di header TCP yang menunjukkan lokasi blok data OOB (secara ambigu, seperti yang disebutkan di sebelumnya). Oleh karena itu, mungkin menunjuk ke data yang belum diterima.

Jika SO_OOBINLINE dinonaktifkan (default) saat segmen TCP yang berisi byte yang ditunjukkan oleh penunjuk mendesak tiba, blok data OOB (satu byte) dihapus dari aliran data dan di-buffer. Jika segmen TCP berikutnya tiba dengan set bendera mendesak (dan penunjuk mendesak baru), byte OOB yang saat ini diantrekan dapat hilang karena digantikan oleh blok data OOB baru (seperti yang terjadi dalam Distribusi Perangkat Lunak Berkeley). Namun, ini tidak pernah diganti dalam aliran data.

Dengan SO_OOBINLINE diaktifkan, data mendesak tetap berada di aliran data. Akibatnya, blok data OOB tidak pernah hilang ketika segmen TCP baru tiba berisi data mendesak. Tanda data OOB yang ada diperbarui ke posisi baru.

Catatan

Saat opsi soket SO_OOBINLINE diatur, SIOCATMARK IOCTL selalu mengembalikan TRUE, dan data OOB dikembalikan ke pengguna sebagai data normal.