⑴ 如何使用arm-eabi-gdb調試android c/c++程序
1.獲取gdbserver
prebuilt/android-arm/gdbserver
2.獲取arm-eabi-gdb
prebuilt/linux-x86/toolchain/arm-eabi-4.4.0/bin
3.啟動emulator(即qemu虛擬機，調式linux內核時用到)
$adb remount && adb push gdbserver /system/bin
adb shell
#gdbserver 10.0.2.2:1234 /system/bin/ping
$telnet localhost 5554
Trying ::1...
telnet: connect to address ::1: Connection refused
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Android Console: type 'help' for a list of commands
OK
]
KO: unknown command, try 'help'
**cmd**redir add tcp:1234:1234
OK
exit
Connection closed by foreign host.
$cd out/target/proct/generic/symbols/system/bin && arm-eabi-gdb ping
(gdb) r
Starting program:
Don't know how to run. Try "help target".
(gdb) target remote localhost:1234
Remote debugging using localhost:1234
0xb0000100 in ?? ()
(gdb) l
1779 usage();
1780 if (argc > 5)
1781 usage();
1782 } else {
1783 if (argc > 10)
1784 usage();
1785 options |= F_SOURCEROUTE;
1786 }
1787 }
1788 while (argc > 0) {
⑵ 網路編程（五）TCP詳解
考慮最簡單的情況：兩台主機之間的通信。這個時候只需要一條網線把兩者連起來，規定好彼此的硬體介面，如都用 USB、電壓 10v、頻率 2.4GHz 等， 這一層就是物理層，這些規定就是物理層協議 。
我們當然不滿足於只有兩台電腦連接，因此我們可以使用交換機把多個電腦連接起來，如下圖：
這樣連接起來的網路，稱為區域網，也可以稱為乙太網（乙太網是區域網的一種）。在這個網路中，我們需要標識每個機器，這樣才可以指定要和哪個機器通信。這個標識就是硬體地址 MAC。
硬體地址隨機器的生產就被確定，永久性唯一。在區域網中，我們需要和另外的機器通信時，只需要知道他的硬體地址，交換機就會把我們的消息發送到對應的機器。
這里我們可以不管底層的網線介面如何發送，把物理層抽離，在他之上創建一個新的層次，這就是 數據鏈路層 。
我們依然不滿足於區域網的規模，需要把所有的區域網聯系起來，這個時候就需要用到路由器來連接兩個區域網：
但是如果我們還是使用硬體地址來作為通信對象的唯一標識，那麼當網路規模越來越大，需要記住所有機器的硬體地址是不現實的；
同時，一個網路對象可能會頻繁更換設備，這個時候硬體地址表維護起來更加復雜。這里使用了一個新的地址來標記一個網路對象： IP 地址 。
通過一個簡單的寄信例子來理解 IP 地址。
我住在北京市，我朋友 A 住在上海市，我要給朋友 A 寫信：
因此，這里 IP 地址就是一個網路接入地址（朋友 A 的住址），我只需要知道目標 IP 地址，路由器就可以把消息給我帶到。 在區域網中，就可以動態維護一個 MAC 地址與 IP 地址的映射關系，根據目的 IP 地址就可以尋找到機器的 MAC 地址進行發送 。
這樣我們不需管理底層如何去選擇機器，我們只需要知道 IP 地址，就可以和我們的目標進行通信。這一層就是 網路層 。網路層的核心作用就是 提供主機之間的邏輯通信 。
這樣，在網路中的所有主機，在邏輯上都連接起來了，上層只需要提供目標 IP 地址和數據，網路層就可以把消息發送到對應的主機。
一個主機有多個進程，進程之間進行不同的網路通信，如邊和朋友開黑邊和女朋友聊微信。我的手機同時和兩個不同機器進行通信。
那麼當我的手機收到數據時，如何區分是微信的數據，還是王者的數據？那麼就必須在網路層之上再添加一層： 運輸層 ：
運輸層通過 socket（套接字），將網路信息進行進一步的拆分，不同的應用進程可以獨立進行網路請求，互不幹擾。
這就是運輸層的最本質特點： 提供進程之間的邏輯通信 。這里的進程可以是主機之間，也可以是同個主機，所以在 android 中，socket 通信也是進程通信的一種方式。
現在不同的機器上的應用進程之間可以獨立通信了，那麼我們就可以在計算機網路上開發出形形式式的應用：如 web 網頁的 http，文件傳輸 ftp 等等。這一層稱為 應用層 。
應用層還可以進一步拆分出表示層、會話層，但他們的本質特點都沒有改變： 完成具體的業務需求 。和下面的四層相比，他們並不是必須的，可以歸屬到應用層中。
最後對計網分層進行小結：
這里需要注意的是，分層並不是在物理上的分層，而是邏輯上的分層。通過對底層邏輯的封裝，使得上層的開發可以直接依賴底層的功能而無需理會具體的實現，簡便了開發。
這種分層的思路，也就是責任鏈設計模式，通過層層封裝，把不同的職責獨立起來，更加方便開發、維護等等。
TCP 並不是把應用層傳輸過來的數據直接加上首部然後發送給目標，而是把數據看成一個位元組 流，給他們標上序號之後分部分發送。這就是 TCP 的 面向位元組流 特性：
面向位元組流的好處是無需一次存儲過大的數據佔用太多內存，壞處是無法知道這些位元組代表的意義，例如應用層發送一個音頻文件和一個文本文件，對於 TCP 來說就是一串位元組流，沒有意義可言，這會導致粘包以及拆包問題，後面講。
前面講到，TCP 是可靠傳輸協議，也就是，一個數據交給他，他肯定可以完整無誤地發送到目標地址，除非網路炸了。他實現的網路模型如下：
對於應用層來說，他就是一個可靠傳輸的底層支持服務；而運輸層底層採用了網路層的不可靠傳輸。雖然在網路層甚至數據鏈路層就可以使用協議來保證數據傳輸的可靠性，但這樣網路的設計會更加復雜、效率會隨之降低。把數據傳輸的可靠性保證放在運輸層，會更加合適。
可靠傳輸原理的重點總結一下有： 滑動窗口、超時重傳、累積確認、選擇確認、連續 ARQ 。
停止等待協議
要實現可靠傳輸，最簡便的方法就是：我發送一個數據包給你，然後你跟我回復收到，我繼續發送下一個數據包。傳輸模型如下：
這種「一來一去」的方法來保證傳輸可靠就是 停止等待協議 （stop-and-wait）。不知道還記不記得前面 TCP 首部有一個 ack 欄位，當他設置為 1 的時候，表示這個報文是一個確認收到報文。
然後再來考慮另一種情況：丟包。網路環境不可靠，導致每一次發送的數據包可能會丟失，如果機器 A 發送了數據包丟失了，那麼機器 B 永遠接收不到數據，機器 A 永遠在等待。
解決這個問題的方法是： 超時重傳 。當機器 A 發出一個數據包時便開始計時，時間到還沒收到確認回復，就可以認為是發生了丟包，便再次發送，也就是重傳。
但重傳會導致另一種問題：如果原先的數據包並沒有丟失，只是在網路中待的時間比較久，這個時候機器 B 會受到兩個數據包，那麼機器 B 是如何辨別這兩個數據包是屬於同一份數據還是不同的數據？
這就需要前面講過的方法： 給數據位元組進行編號 。這樣接收方就可以根據數據的位元組編號，得出這些數據是接下來的數據，還是重傳的數據。
在 TCP 首部有兩個欄位：序號和確認號，他們表示發送方數據第一個位元組的編號，和接收方期待的下一份數據的第一個位元組的編號。
停止等待協議的優點是簡單，但缺點是 信道利用率 太低。
假定AB之間有一條直通的信道來傳送分組
這里的TD是A發送分組所需要的時間（顯然TD = 分組長度 / 數據速率）再假定TA是B發送確認分組所需要的時間（A和B處理分組的時間都忽略不計）那麼A在經過TD+RTT+TA時間後才能發送下一個分組，這里的RTT是往返時間，因為只有TD是採用來傳輸有用的數據（這個數據包括了分組首部，如果可以知道傳輸更精確的數據的時間，可以計算的更精確），所有信道利用率為
為了提高傳輸效率，發送方可以不使用低效率的停止等待協議，而是採用 流水線傳輸 ：就是發送方可以 連續的發送多個分組 ，不必每發完一個分組就停下來等待對方的確認。這樣可使信道上一直有數據不間斷地在傳送。顯然這種傳輸方式可以獲得很高的信道利用率
停止等待協議已經可以滿足可靠傳輸了，但有一個致命缺點： 效率太低 。發送方發送一個數據包之後便進入等待，這個期間並沒有干任何事，浪費了資源。解決的方法是： 連續發送數據包 。
也就是下面介紹的 連續ARQ協議 和 滑動窗口協議
連續 ARQ 協議
模型如下：
和停止等待最大的不同就是，他會源源不斷地發送，接收方源源不斷收到數據之後，逐一進行確認回復。這樣便極大地提高了效率。但同樣，帶來了一些額外的問題:
發送是否可以無限發送直到把緩沖區所有數據發送完？不可以。因為需要考慮接收方緩沖區以及讀取數據的能力。如果發送太快導致接收方無法接受，那麼只是會頻繁進行重傳，浪費了網路資源。所以發送方發送數據的范圍，需要考慮到接收方緩沖區的情況。這就是 TCP 的 流量控制 。
解決方法是： 滑動窗口 。基本模型如下：
在 TCP 的首部有一個窗口大小欄位，他表示接收方的剩餘緩沖區大小，讓發送方可以調整自己的發送窗口大小。通過滑動窗口，就可以實現 TCP 的流量控制，不至於發送太快，導致太多的數據丟失。
連續 ARQ 帶來的第二個問題是：網路中充斥著和發送數據包一樣數據量的確認回復報文，因為每一個發送數據包，必須得有一個確認回復。提高網路效率的方法是： 累積確認 。
接收方不需要逐個進行回復，而是累積到一定量的數據包之後，告訴發送方，在此數據包之前的數據全都收到。例如，收到 1234，接收方只需要告訴發送方我收到 4 了，那麼發送方就知道 1234 都收到了。
第三個問題是：如何處理丟包情況。在停止等待協議中很簡單，直接一個超時重傳就解決了。但，連續 ARQ 中不太一樣。
例如：接收方收到了 123 567，六個位元組，編號為 4 的位元組丟失了。按照累積確認的思路，只能發送 3 的確認回復，567 都必須丟掉，因為發送方會進行重傳。這就是 GBN（go-back-n) 思路。
但是我們會發現，只需要重傳 4 即可，這樣不是很浪費資源，所以就有了： 選擇確認 SACK 。在 TCP 報文的選項欄位，可以設置已經收到的報文段，每一個報文段需要兩個邊界來進行確定。這樣發送方，就可以根據這個選項欄位只重傳丟失的數據了。
第四個問題是：擁塞控制的問題
也是通過窗口的大小來控制的，但是檢測網路滿不滿是個挺難的事情，所以 TCP 發送包經常被比喻成往誰管理灌水，所以擁塞控制就是在不堵塞，不丟包的情況下盡可能的發揮帶寬。
水管有粗細，網路有帶寬，即每秒鍾能發送多少數據；水管有長度，端到端有時延。理想狀態下，水管裡面的水 = 水管粗細 * 水管長度。對於網路上，通道的容量 = 帶寬 * 往返時延。
如果我們設置發送窗口，使得發送但未確認的包為通道的容量，就能撐滿整個管道。
如圖所示，假設往返時間為 8 秒，去 4 秒，回 4 秒，每秒發送一個包，已經過去了 8 秒，則 8 個包都發出去了，其中前四個已經到達接收端，但是 ACK 還沒返回，不能算發送成功，5-8 後四個包還在路上，還沒被接收，這個時候，管道正好撐滿，在發送端，已發送未確認的 8 個包，正好等於帶寬，也即每秒發送一個包，也即每秒發送一個包，乘以來回時間 8 秒。
如果在這個基礎上調大窗口，使得單位時間可以發送更多的包，那麼會出現接收端處理不過來，多出來的包會被丟棄，這個時候，我們可以增加一個緩存，但是緩存裡面的包 4 秒內肯定達不到接收端課，它的缺點會增加時延，如果時延達到一定程度就會超時重傳
TCP 擁塞控制主要來避免兩種現象，包丟失和超時重傳，一旦出現了這些現象說明發送的太快了，要慢一點。
具體的方法就是發送端慢啟動，比如倒水，剛開始倒的很慢，漸漸變快。然後設置一個閾值，當超過這個值的時候就要慢下來
慢下來還是在增長，這時候就可能水滿則溢，出現擁塞，需要降低倒水的速度，等水慢慢滲下去。
擁塞的一種表現是丟包，需要超時重傳，這個時候，採用快速重傳演算法，將當前速度變為一半。所以速度還是在比較高的值，也沒有一夜回到解放前。
到這里關於 TCP 的可靠傳輸原理就已經介紹得差不多。最後進行一個小結：
當然，這只是可靠傳輸的冰山一角，感興趣可以再深入去研究
⑶ 利用shell命令實現Eeclipse對Android的遠程調試
這篇文章主要講如何自己來做一個apk實現遠程調試，也就是說我們先自己寫一個apk來控制是否啟用遠程調試的功能，然後通過這個apk來啟用遠程調試，接著基於遠程adb的方式來調試以後的程序。聽起來真TM繞口。沒關系，跟著看就行了。實現這個目標分為3步。
好吧，這個逼格的東西並不需要你多麼的了解，我們只需要知道幾條基本的命令。
設置adb的調試埠，當埠>-1的時候，adb是wifi調試，我們默認的一般將埠設置為5555
setprop service.adb.tcp.port 5555
對應的將埠設置為-1或者更小的數值，則將調試方式變為了usb調試
setprop service.adb.tcp.port -1
關閉adb
stop adbd
打開adb
start adbd
好了有了這幾個命令的基礎，就可以實現usb和wifi調試方式的轉換了
怎麼執行，鬼才管呢。我又不是搞底層的。對於執行shell命令，自有高手早已寫好的工具類，這里將源碼貼上
我們需要用到的方法是
解釋下三個參數的意思
參數1：需要執行的命令數組
參數2：是否已經root過。oh天，忘了說，你的手機必須要先root才能來做這件事情，至於root的方式，太多了，什麼root大師，xx大師。
參數3：是否需要返回結果，這個可有可無，如果你選擇返回結果，我想多半是你想知道這些命令有沒有執行成功，你只需要判斷
CommandResult .result
的值是否為0，對的，linux就是這樣，等於0就是成功了的意思
ok，剩下的活你應該會做了，寫一個button控制項，監聽點擊事件，在事件中調用這個方法。至於參數一怎麼寫，當需要打開wifi調試的時候就這樣寫
當需要關閉wifi調試的時候，只需要將5555改為-1就行
好的，現在你可以將apk編譯到你的手機上，並且打開wifi調試，接著在如下目錄
你可以通過 shift+右鍵 的方式有個「在此處打開命令行」。然後輸入
adb connect xxxx
xxxx 是你的手機ip，埠不用輸，默認就是5555，手機ip你可以在設置-關於手機-手機狀態 中找到
於是「噌」的一下，你的eclipse里的device窗口就顯示你的破手機已經連接上了，現在你可以丟掉數據線，靜靜的裝逼了。真是有逼格的燒連啊。
斷開連接，你可以在手機上斷開，也可以在pc上通過
來斷開，當然在手機上斷開保險一點。
好的，有問題的同學可以留言，啊哈哈哈哈哈，這都不會，你好笨啊。
⑷ Tcp，android客戶端服務端斷開重連應該怎麼個實現
我正好也在做這方面的東西，我們可以交流一下，我這邊需要做的是TCP客戶端和TCP伺服器，無這邊伺服器搭建目前運行狀況良好，但是客戶端始終不行，請問你有沒有客戶端的相關常式，我這邊的常式也可以分享給你的說，大家相互借鑒，共同進步。
周末加了一天班，終於把問題解決了，總結一個血的教訓給你，就是：你在調試單片機客戶端的時候，作為伺服器的電腦防火牆一定要關掉啊，我就是因為這樣，白忙了兩天。
你要實現客戶端斷開不影響HTTP伺服器的運行，就需要建立兩個不同的TCP_SERVER_pcb和TCP_CLI ENT_pcb結構體，分別用於客戶端和伺服器的TCP/IP協議棧控制。並且需要兩個不同的發送和接收緩存，不然是不行的。
⑸ android socket udp 怎麼封裝ip+報頭+協議
CP包
每個tcp都包含源埠號和目標埠號，加上ip頭中的源ip和目的ip，唯一確定一個tcp連接。序號用來標識從tcp發端向tcp收端發送的數據位元組流，它表示在這個報文段中的第一個數據位元組。序號欄位包含由這個主機選擇的該連接的初始序號isn（Initial Sequence Number）。該主機要發送數據的第一個位元組，序號為isn+1，因為syn佔用了一個序號。
IP包
IPV4報頭有12個必需的欄位和可選IP選項欄位，位於要發送的數據之前。如果使用IP層已有的庫或其他組件，一般不必考慮報頭中的大多數欄位，但程序代碼需要提供源端和目的端地址。
1、版本（4比特）
IP協議版本已經經過多次修訂，1981年的RFC0791描述了IPV4，RCF2460中介紹了IPV6。
2、報頭長度（4比特）
報頭長度是報頭數據的長度，以4位元組表示，也就是以32位元組為單位。報頭長度是可變的。必需的欄位使用20位元組（報頭長度為5，IP選項欄位最多有40個附加位元組（報頭長度為15）。
3、服務類型（8比特）
該欄位給出發送進程建議路由器如何處理報片的方法。可選擇最大可靠性、最小延遲、最大吞吐量和最小開銷。路由器可以忽略這部分。
4、數據報長度（16比特）
該欄位是報頭長度和數據位元組的總和，以位元組為單位。最大長度為65535位元組。
5、標識符（16比特）
原是數據的主機為數據報分配一個唯一的數據報標識符。在數據報傳向目的地址時，如果路由器將數據報分為報片，那麼每個報片都有相同的數據標識符。
6、標志（3比特）
標志欄位中有2為與報片有關。
位0：未用。
位1：不是報片。如果這位是1，則路由器就不會把數據報分片。路由器會盡可能把數據報傳給可一次接收整個數據報的網路；否則，路由器會放棄數據報，並返回 差錯報文，表示目的地址不可達。IP標准要求主機可以接收576位元組以內的數據報，因此，如果想把數據報傳給未知的主機，並想確認數據報沒有因為大小的原 因而被放棄，那麼就使用少於或等於576位元組的數據。
位2：更多的報片。如果該位為1，則數據報是一個報片，但不是該分片數據報的最後一個報片；如果該位為0，則數據報沒有分片，或者是最後一個報片。
7、報片偏移（13比特）
該欄位標識報片在分片數據報中的位置。其值以8位元組為單位，最大為8191位元組，對應65528位元組的偏移。
例如，將要發送的1024位元組分為576和424位元組兩個報片。首片的偏移是0，第二片的偏移是72（因為72×8＝576）。
8、生存時間（8比特）
如果數據報在合理時間內沒有到達目的地，則網路就會放棄它。生存時間欄位確定放棄數據報的時間。
生存時間表示數據報剩餘的時間，每個路由器都會將其值減一，或遞減需要數理和傳遞數據報的時間。實際上，路由器處理和傳遞數據報的時間一般都小於1S，因此該值沒有測量時間，而是測量路由器之間跳躍次數或網段的個數。發送數據報的計算機設置初始生存時間。
9、協議（8比特）
該欄位指定數據報的數據部分所使用的協議，因此IP層知道將接收到的數據報傳向何處。TCP協議為6，UDP協議為17。
10、報頭檢驗和（16比特）
該字端使數據報的接收方只需要檢驗IP報頭中的