一、
為什麼需要兩個連線相互輔助進行命令識別並傳輸音訊。首先從a客戶端傳送資料到b客戶端是乙個音訊資料流，而音訊資料流在伺服器上傳輸的時候使用的是橋接模式。這也就說明了在伺服器端，其實不是將乙個packet資料傳輸到另乙個packet。如果需要用packet進行傳輸，這意味著我們需要對客戶端的資料進行反向解析，解析之後需要進行儲存，儲存之後再進行另乙個連線的排程，而整個過程是比較漫長的，從而會導致整個傳輸流程的延遲增加，因此導致了整個音訊的不夠順暢，所以，在伺服器端實現的是從ioargs傳輸到ioargs。
因此也就明白了為什麼需要另乙個連線來實現命令傳輸了，因為直流傳輸的整個橋接流，一旦進行了橋接模式，也就是把資料從乙個ioargs傳輸到另乙個ioargs,此時資料沒有傳輸到上層，也就是不可能得到packet。一旦無法得到packet，也就是無法傳輸到業務資料層。業務資料層的資料是可以進行解析的，並且可以進行識別的，而對於ioargs而言，是乙個原始資料層，它的資料無法進行乙個準確的識別，導致了之前的音訊傳輸流無法進行命令識別，所以需要另外連線來輔助進行命令識別。
二、互動流程
首先，a客戶端會建立好兩個連線.
對於b客戶端來說，也是建立兩個連線。
對於橋接連線：首先在服務端肯定有兩個連線，分別連線著兩個客戶端。這兩個客戶端連線之後的資料，從a客戶端傳送過去的資料到達伺服器後，首先會被接收成ioargs，然後會把這個ioargs直接傳輸給另乙個客戶端，整個過程是乙個可逆向的，可以迴圈進行互動的。a客戶端將資料傳輸到伺服器，伺服器將資料傳輸給b客戶端。同時，b客戶端將資料傳輸給伺服器，也可以再反向**給a客戶端，這就是橋接模式的核心原理。
對於命令連線來說，我們的服務端也有乙個對應的命令連線，從a客戶端先把資料投遞到伺服器的時候，伺服器會對整個資料進行反向解析，解析到packet，而對於b連線也是一樣，此時，具有兩個佇列的packet，此時可以對兩個佇列的資料進行識別。識別是在服務端完成的，整個過程是由服務端進行控制，遵循的是我們的命令結構，對命令進行解析，並且進行識別，比如說生成房間，或者通知某個客戶端進行聊天，這個過程中涉及到是否把a客戶端的資訊同步給b客戶端，這個過程也是由伺服器端決定的，具體的流程由伺服器端的業務進行判斷。
所以，整個紅色框的部分，就是伺服器端的部分，這就是兩個連線連線之後的整個傳輸流程。
三、opus資料規則
乙個客戶端通過麥克風不斷地產生資料，而這個資料我們稱之為pcm資料流，也就是最原始的資料，這部分資料一旦被緩衝區存滿之後，會不斷地進行覆蓋，而我們需要的就是從整個緩衝區中讀取一部分資料出來。
此時，我們已經從緩衝區讀取了10個位元組，那要如何將資料填充到opus壓縮資料中呢？
我們會對資料進行opus編碼，而編碼之後的資料可能只有6個位元組，此時把它寫到另乙個buffer當中，而這個buffer寫的時候從第三個座標開始寫，依次往後推，我們寫6個座標長度，這就代表了壓縮之後的資料。而壓縮之後的資料，在傳輸之前會先對這部分資料進行提取，此時提取到的資料是6個位元組，所以會在前面的兩個位元組當中寫入我們的長度資訊，也就是0、6。那麼整個的長度就是2個位元組再加上6個位元組，最終是8個位元組長度。網路傳輸的時候，會把8個位元組長度進行傳送。傳送到b客戶端的時候，b客戶端開始進行讀取，此時，他會先讀取長度，而讀取長度，它有乙個長度限制，它會先讀2個位元組，讀取到2個位元組後，也就是06，在客戶端會進行short讀取，讀取之後會拿到長度資訊，也就是6，那麼它直到後面的opus編碼部分的長度，也就是6個位元組，然後它會在之後面的長度當中讀取6個位元組出來，讀取到新的buffer當中，那這是在新連線當中。當整個資料讀取出來後，會對整個資料進行opus節碼，節碼之後會對整個資料進行還原。
這就是整個傳輸資料的流程。
為什麼要對正opus編碼之後的資料提取長度呢？
其實是因為opus的基本規則。
mysql 即時通訊 即時通訊IM模板
更新記錄 1.0.3 2020 10 22 完成點對點通訊功能，修復若 ug。1.0.2 2020 06 02 1 增加登入 註冊 個人資訊頁面 speedy im 注意介紹 正在持續開發中，目前僅部分ui開發完成。demo im.apk 已有基礎ui以及登陸 點到點聊天等功能。開發客戶端測試賬號密...
Android即時通訊開發總結
第三方平台 比如環信，融雲，leancloud，容聯雲 網易雲信等等。直接使用sdk就可以實現了，最簡單最直接，而且穩定性已經不錯了，連ui介面都帶有了，可以自行修改，缺點是要收費。spark smack openfire 安卓使用asmack，測試使用spark，伺服器使用openfire。asm...
即時通訊系統
企業擁有一套理想的即時通訊系統，正如找到了一位得心應手的商務秘書。然而，縱觀當前企業即時通訊市場，同質化的即時通訊軟體比比皆是，而能夠讓企業真正根據自身需要來按需定製 人性化開發的即時通訊系統卻少之又少。傳統開發理念讓企業被動使用即時通訊。目前，大多數的軟體提供商還在用傳統的開發理念來開發企業即時通...