Беспорядок в htons-прямом порядке байтов / обратный порядок байтов
Выравнивание переменных в памяти (краткая история).
В прошлых компьютерах имел шину данных на 8 битов. Это означает, что каждый такт 8 битов информации мог быть обработан. Который был прекрасен тогда.
Тогда прибыл компьютеры на 16 битов. Из-за совместимости сверху вниз и других проблем, байт на 8 битов был сохранен, и слово на 16 битов было представлено. Каждое слово составляло 2 байта. И каждый такт 16 битов информации мог быть обработан. Но это создало небольшую проблему.
Позволяют нам посмотреть на карту распределения памяти:
+----+
|0000|
|0001|
+----+
|0002|
|0003|
+----+
|0004|
|0005|
+----+
| .. |
В каждом адресе существует байт, к которому можно получить доступ индивидуально. Но слова могут только быть выбраны даже в адресах. Таким образом, если мы читаем слово в 0000, мы читаем байты в 0000 и 0001. Но если мы хотим считать слово в положении 0001, нам нужен два доступа для чтения. Сначала 0000,0001 и затем 0002,0003 и мы только сохраняем 0001,0002.
, Конечно, это заняло некоторое дополнительное время, и это не ценилось. Так вот почему они изобрели выравнивание. Таким образом, мы храним переменные слова на границах слова и переменные байта на границах байта.
, Например, если у нас есть структура с полем (B) байта и полем (W) слова (и очень наивный компилятор), мы получаем следующее:
+----+
|0000| B
|0001| W
+----+
|0002| W
|0003|
+----+
, Который не является забавой. Но при использовании выравнивания слов мы находим:
+----+
|0000| B
|0001| -
+----+
|0002| W
|0003| W
+----+
Здесь память принесена в жертву за скорость доступа.
можно предположить, что при использовании двойного слова (4 байта) или квадратического слова (8 байтов) это еще более важно. Вот почему с большинством современных компиляторов Вы можете, выбрал, какое выравнивание Вы используете при компиляции программы.
3 ответа
If you want your program to be portable, then any time you send an integer greater than 1 byte in size over the network, you must first convert it to network byte order using htons or htonl, and the receiving computer must convert it to host byte order using ntohs or ntohl.
In your case, the reason the value is still the same is probably because the sending computer and the receiving computer are of the same endianness. In other words, the sending computer and the receiving computer you're working with are both little endian (or big endian, whatever the case may be.)
But if you want your program to be portable, you can't rely on this to always be the case. One day, for example, the sending computer may be an Intel x86, and the receiving may be a Sun SPARC, and then your program will fail if you don't use htons.
If you want to send data from an x86 or amd64 machine to a machine with a PowerPC processor, in binary format you'll quickly see that your data encounters the "NUXI problem" as the different processors treat the integers differently and appear to swap the bytes. (They don't actually swap the bytes -- they just work with them in a different order.)
When working on x86 or amd64, the least-significant byte comes first in memory (this way you can perform addition from lower to higher memory addresses). The PowerPC puts the most-significant byte first in memory (this way you can sort numbers based on the bytes that come earlier in memory -- a string sort and an integer sort can be exactly the same.)
Он остается таким же, потому что в вашей архитектуре сетевой порядок такой же, как и собственный порядок. Если вы никогда не планируете компилировать свой код для другой архитектуры, вы можете опустить вызовы hton / ntoh. Тогда ваш код не будет переносимым.