Bagaimanakah GCDAsyncSocket menghantar secara berurutan? ? ?
PHPz2017-05-02 09:32:41
0
1
837
Bagaimanakah GCDAsyncSocket menghantar mesej secara berurutan? ? ? Contohnya, hantar nama fail dahulu, kemudian panjang, dan kemudian fail Anda juga mesti menghantar
Ringkasnya, sambungan TCP tidak berfungsi semasa penghantaran rangkaian (terutamanya untuk mengoptimumkan penghantaran data), tetapi TCP mempunyai pemprosesan "isihan" yang sepadan, jadi untuk sambungan yang sama (seperti klien A dan pelayan S Sambungan ini antara ), lapisan bawah Soket TCP telah melaksanakan urutan Jika anda menghantar mengikut urutan a, b, c, penerima akan menerima a, b, c dalam urutan. Ini juga merupakan kelebihan TCP berbanding UDP.
Jadi masalah anda bukan masalah GCDAsyncSocket.
Soket hanya menghantar dan menerima data, tanpa logik perniagaan tertentu, aplikasi soket biasanya mempunyai format data mereka sendiri, seperti menggabungkan pelbagai parameter dengan pembatas (contohnya: nama fail | fail), atau menggunakan format biasa xml Atau json, dsb. untuk penghuraian mudah ( {"nama fail": "", "data": ""} ). Pada masa yang sama, disebabkan oleh had MTU, sekeping data perniagaan yang lengkap mungkin dibongkar dan dihantar apabila dihantar, dan kehilangan paket mungkin berlaku disebabkan oleh sebab rangkaian, jadi parameter "panjang data soket" akan ditambahkan pada format data tersuai , serupa dengan The Content-Length of HTTP POST biasanya ditambahkan pada permulaan sekeping data untuk menandakan panjang keseluruhan data soket berikutnya. Parameter "panjang" tidak mengambil bahagian dalam format data Panjang subseksyen tertentu yang dipersetujui oleh kedua-dua pihak mewakili parameter "panjang data soket". Apabila penerima memproses data, ia terlebih dahulu menghuraikan "panjang" beberapa bit pertama, dan kemudian menentukan data lengkap berikutnya berdasarkan panjang ini.
Jika anda menghadapi masalah semasa pembangunan Soket dan tidak dapat menentukan punca dengan jelas, adalah disyorkan untuk menangkap paket dan menganalisisnya terlebih dahulu untuk melihat cara data dihantar, menyelesaikan masalah kerosakan rangkaian, dan kemudian menentukan sama ada ia adalah penghantar masalah atau masalah penerima. Jika tiada masalah dengan penghantar dan penerima, dan tiada masalah dengan kod perkhidmatan, akhirnya pertimbangkan untuk menyemak sebab "proksi rangkaian", seperti penghala, pengendali, dll. Ia juga mudah untuk masalah berlaku dalam lapisan tengah rangkaian China.
![[Web front-end] Permulaan pantas Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
Ringkasnya, sambungan TCP tidak berfungsi semasa penghantaran rangkaian (terutamanya untuk mengoptimumkan penghantaran data), tetapi TCP mempunyai pemprosesan "isihan" yang sepadan, jadi untuk sambungan yang sama (seperti klien A dan pelayan S Sambungan ini antara ), lapisan bawah Soket TCP telah melaksanakan urutan Jika anda menghantar mengikut urutan a, b, c, penerima akan menerima a, b, c dalam urutan. Ini juga merupakan kelebihan TCP berbanding UDP.
Jadi masalah anda bukan masalah GCDAsyncSocket.
Soket hanya menghantar dan menerima data, tanpa logik perniagaan tertentu, aplikasi soket biasanya mempunyai format data mereka sendiri, seperti menggabungkan pelbagai parameter dengan pembatas (contohnya: nama fail | fail), atau menggunakan format biasa xml Atau json, dsb. untuk penghuraian mudah ( {"nama fail": "", "data": ""} ). Pada masa yang sama, disebabkan oleh had MTU, sekeping data perniagaan yang lengkap mungkin dibongkar dan dihantar apabila dihantar, dan kehilangan paket mungkin berlaku disebabkan oleh sebab rangkaian, jadi parameter "panjang data soket" akan ditambahkan pada format data tersuai , serupa dengan The Content-Length of HTTP POST biasanya ditambahkan pada permulaan sekeping data untuk menandakan panjang keseluruhan data soket berikutnya. Parameter "panjang" tidak mengambil bahagian dalam format data Panjang subseksyen tertentu yang dipersetujui oleh kedua-dua pihak mewakili parameter "panjang data soket". Apabila penerima memproses data, ia terlebih dahulu menghuraikan "panjang" beberapa bit pertama, dan kemudian menentukan data lengkap berikutnya berdasarkan panjang ini.
Jika anda menghadapi masalah semasa pembangunan Soket dan tidak dapat menentukan punca dengan jelas, adalah disyorkan untuk menangkap paket dan menganalisisnya terlebih dahulu untuk melihat cara data dihantar, menyelesaikan masalah kerosakan rangkaian, dan kemudian menentukan sama ada ia adalah penghantar masalah atau masalah penerima. Jika tiada masalah dengan penghantar dan penerima, dan tiada masalah dengan kod perkhidmatan, akhirnya pertimbangkan untuk menyemak sebab "proksi rangkaian", seperti penghala, pengendali, dll. Ia juga mudah untuk masalah berlaku dalam lapisan tengah rangkaian China.