總所周知，不同系統平台間的記憶體訪問位元組序不同，有所謂big-endien和little-end兩種。因此，為實現通用的通訊程式，通常的做法是統一採用big-endian位元組序作為網路標準位元組序，到主機端根據情況進行轉換，即使用ntoh*和hton*這兩類巨集或函式。
然而，就效率方面來講，對於同構的系統平台，這樣做未免有些浪費。尤其是我們常見的x86平台，每次通訊，傳送端都要先把資料從little-endien轉成big-endien，接收端再執行相反的過程轉回來，相當於做了兩次無用功。有時，即使對於異構平台，這些轉換過程如果實現為函式呼叫也是浪費的。
因此，考慮對同構平台作一些優化，我們可以採取非傳統的思路。ace的cdr_stream就採用了這種設計思路進行優化，巨集常量ace_enable_swap_on_write在編譯時確定是否進行位元組序轉換，預設是關閉的，即不進行轉換。例如下面的**：
當然，在保證能在異構平台件正常通訊的前提下，位元組序轉換是必要的。不過即使這種情況，也有兩種選擇。一種當然是傳統的方式，即將通訊資料統一轉為網路位元組序；另一種是在傳送資料時不進行位元組序轉換，而由傳送方標明本身的位元組序，仍然保持主機位元組序在網路中傳輸，由接受端確定是否進行轉換。這就涉及到乙個位元組序標識存放的問題。ace經典教程《c++npv1》給出的例子，是將位元組序標識放在每個通訊包頭的第乙個位元組。這樣做當然可以解決問題，不過也帶來了額外的開銷，就是每個包頭中多了乙個位元組。
採用標識位元組序的方式優化，另一種效率更高的做法，就是在通訊連線建立之初，標識和確定通訊雙方的位元組序。我們可以在應用協議中約定：建立連線後傳送的第乙個資料報中，包含了網路位元組序資訊，以後的資料報都不包含這一資訊。之所以能這麼優化，是因為已知的系統平台都不會在執行時改變本機位元組序，而且可預知的未來也會繼續保持這一特性。
優化往往會帶來一些限制和複雜性，上述位元組序轉換的優化也如此，這要求各通訊端都採用新的位元組序標識協議。對於這一點，我們別忘了要考慮不同語言的實現。
linux網路程式設計中的位元組序轉換
首先解釋一下位元組序的概念，所謂位元組序是指多位元組資料的儲存順序，比如0x1234要放在0000h和0001h兩儲存單元，有兩種儲存方式 大端格式為 0000h 12,0001h 34和小端格式為 0000h 34,0001h 12。大端格式 將高位位元組資料儲存在低位址，低位位元組資料儲存在高位...
python 網路位元組序轉換 網路位元組序
一.位元組序 位元組序是由於不同的主處理器和作業系統，對大於乙個位元組的變數在記憶體中的存放順序不同而產生的。位元組序通常有大端位元組序列和小端位元組序兩種分類方法。由於主機的千差萬別，主機的位元組序不能做到統一，但是網路上傳輸的數值，它們有統一的規定。網路位元組序 是指多位元組變數在網路傳輸時的表...
python php 網路程式設計 位元組序轉換
1.python寫法 import socket def convert integer data 1234 32 bit print original s long host byte order s,network byte order s data,socket.ntohl data sock...