協議本身是一個運行在UDP之上的定製協議。我所以決定使用一個定製協議很簡單。首先，當前這個任務看起來足夠簡單，因此與嘗試改進一個現在協議相比，直接構建一個定製協議更為容易。其次，定製協議可以將開銷減少至最小並儘可能地提高性能。最後，這本身就是一個很好的教學練習。 TCP是一個流協議，每次查看網頁，檢 ...
協議本身是一個運行在UDP之上的定製協議。我所以決定使用一個定製協議很簡單。首先，當前這個任務看起來足夠簡單，因此與嘗試改進一個現在協議相比，直接構建一個定製協議更為容易。其次，定製協議可以將開銷減少至最小並儘可能地提高性能。最後，這本身就是一個很好的教學練習。
TCP是一個流協議，每次查看網頁，檢查郵件或者下載文件時使用的就是TCP協議。從本質上講，TCP會在兩個電腦之間建立一個雙向管道，並盡其所能地掩蓋其底層網路的不可靠性和不確定性。
UDP會暴露很多不確定性。它使用一個校驗和來確保不會傳遞被攻破的數據，但它並不會做任何嘗試來掩蓋出現問題。如果一個路由器決定丟掉一個數據包，那麼這個數據永遠不會被接收。如果一個較早的數據包被延遲，以至於較晚到達，數據的妝收就會亂序。因此，要由各個應用採取措施對這些問題做出補償。
但是UDP使用的資源更少，而且能提供更好的性能。本質上TCP是基於連接的，所以，對於應用要通信的每一個遠程設備都必須建立並維持連接，而如果計劃支持大量此類設備，開銷就會非常大。另外,TCP會嘗試恢復，但是恢復要花費時間。與之不同，UDP只是跳過丟包，繼續發送後續的更新。如果你追求性能，而且能夠應對丟失數據，那麼UDP是上選。這正是在vocie-over-IP應用，線上游戲以及這個示例工程中使用UDP的原因。
坐標就是32位有符號整數。這有些大材小用，因為iPhone屏幕只有320*480，不過這樣可以為將來留出餘地。至於顏色，沒有必要使用大於單位元組的類型來表示各個顏色分量。這樣一來，每個分量的取值範圍就是0～255，這已經是大多數屏幕所能再現的最大顏色解析度。
C編譯器總是會犧牲空間來換取速度，如果電腦處理的數據是對齊的，處理速度則最快，所謂對齊是指數據所在的記憶體地址恰好是其大小的倍數。int32_t類型是4位元組，所以編譯器會嘗試使其地址是4的倍數。
前一種體系稱為大端位元組序，後一種稱為小端位元組序。目前，Mac中使用的Intel x86 CPU採用小端位元組序，iPhone中使用的ARM CPU也是如此。較早的Mac中使用的PowerPC處理器採用大端位元組序，一般的，通常會看到不同平中上分別使用不同的位元組序。如果使用不正確 位元組序讀取數據，會得出混亂而且毫無意義的數字，所以，明確位元組序非常重要。
實際上，至少還存在另外一種位元組序:中間端位元組序！在一些較早的，少見的體繫結構中，並沒有使用前向也沒有使用向後順序，而是採用了一種奇怪的混合順序，對於事例整數305 419 896,會寫為｛0x34,0x12,0x78,0x56}.正是由於在這樣一些較老的系統上存儲字元串”UNIX“時會表示為”NUXI“，所以區別位元組序的問題有時稱為”NUXI問題"。
參考資料：《精彩iPhone炫酷開發-七位一線高手的編程和設計範例》
