使用信元流（TLVStream）規范、簡化模塊（C/C++）間交互 收藏

　　問題描述：
　　在軟件開發過程中，一般會對復雜的現實世界進行抽象，并且采用分而治之的策略，將大系統分解為子系統，將子系統分解為一個個的模塊。模塊間的通信一般采用函數調用的方式，這樣會產生一些問題：
   1. 模塊間的接口增多會導致模塊間緊密耦合，不利于模塊的重用、調試、維護。
   2. 接口函數參數會很復雜，容易出現很龐大，功能面面俱到的結構體。
   3. 不利于擴展，新增功能要新增接口函數，或者修改接口參數。

---

信元流的定義
　　信元流是一種處理數據的方式。它對現實世界的數據進行抽象，形成一個一個的信元，然后由這些信元以一定的方式組合起來，形成信元流，來傳遞數據。下面信元流的實現。
　　信元的實現
　　信元由三部分組成，分別是信元標識（Tag），信元長度（Length），信元值（Value），即TLV格式。下面是一個信元的c定義： 　　
　　typedef struct __ELEMENT_ST

     {

          ELE_TAG tag;

          ELE_LEN len;

          ELE_VALUE value;

     }ELEMENT_ST；

　　信元流的實現：
　　信元流分為兩部分，信元流頭部（head）和體部（body）。head部分用于記錄信元流的整體描述，比如，信元流的起始模塊，目的模塊，以及信元流的消息類型等等。當然，也可以根據需要自己進行擴展。body部分包括信元流中信元的總大小，即ELE_MSG_BODY中body的長度。

        typedef struct __ELEMENT_STREAM_ST
        {
            MOD_ID src_mod;
            MOD_ID des_mod;
            ELE_MSG_TYPE type;
            ELE_MSG_BODY body;
        }ELEMENT_STREAM_ST;
        typedef struct __ELE_MSG_BODY
        {
            ELE_MSG_LEN len;
            char body[MAX_ELE_MSG_BODY_LEN];
        } ELE_MSG_BODY;

　　構造信元流
　　定義好結構體后，下面定義兩個函數，分別向信元體中添加信元和刪除信元。
   //pbody信元體的指針。這里沒有使用信元流的指針是為了讓函數的重用性更好，用戶可以自己定義信元流。
        //tag:添加信元的TAG值，len：添加信元的長度。pvale：添加信元的值。
        int AddElementToStreamBody(ELE_MSG_BODY *pbody, ELE_TAG tag, ELE_LEN len, void *pvalue);
        //pbody信元體的指針。 //tag:獲取信元的TAG值，buf_len：pbuf的長度。pbuf：目標緩沖區，要把信元VALUE的值寫入吃緩沖區。
        int GetElementFromStreamBody(ELE_MSG_BODY *pbody, ELE_TAG tag, int buf_len, void *pbuf);
　　信元流的body是一個緩沖區，信元在里面順序排列。信元在body中順序不影響它的獲取。添加和獲取的方法比較簡單，不再贅述。

---

　　一個信元流的實例
　　下面來舉一個具體的例子來介紹一下信元流的使用，以及它的優點。
　　假如由兩個模塊A和B。A模塊負責處理業務邏輯，B模塊負責處理呼叫控制。A調用B的一個接口發起呼叫，接口如下。
        typedef struct __MAKE_CALL_ST
        {
            char caller_num[MAX_NUM_LEN];//主叫號碼
            char called_num[MAX_NUM_LEN];//被叫號碼
        }MAKE_CALL_ST;
        int MakeCall(MAKE_CALL_ST *pcall_info);

　　后面需求有更改，某些情況下藥攜帶主叫的callid信息。結構體會變成：
    typedef struct __MAKE_CALL_ST
    {
        char caller_num[MAX_NUM_LEN];//主叫號碼
        char called_num[MAX_NUM_LEN];//被叫號碼
        CALL_ID caller_callid;
    }MAKE_CALL_ST;
　　某些情況下又需要攜帶主叫的SDP信息，結構體會變成：
    typedef struct __MAKE_CALL_ST
    {
        char caller_num[MAX_NUM_LEN];//主叫號碼
        char called_num[MAX_NUM_LEN];//被叫號碼
        CALL_ID caller_callid;
        SDP_INFO call_sdp;
    }MAKE_CALL_ST;
　　隨著需求的增加，這個結構體會越來越大，并且，其中的成員在某些情況下要使用，某些情況下又不使用，造成模塊間的冗余數據。
　　當然，你也可以采用其他的方法，比如，再多定義幾個接口和結構體。但是這樣的話接口和結構體的數量會呈爆炸式的增長。
　　使用信元流可以很好的解決這個問題。把號碼，callid，sdp等全部定義成信元，需要的時候塞進去，不需要的話就不添加。另外還有一個好處就是，一個模塊可以對外只公布一個接口，來收取信元流，然后在根據信元流的類型進行分別處理。這樣，一個模塊對外就只有一個接口了，模塊間的耦合性會降低。

---

一點改進
　　上面定義的信元流的格式在實際使用的過程中還是碰到了一些問題，最突出的就是，信元流的大小是固定死的。這種情況下，如果信元信息很小，會導致空間浪費，效率降低；如果信元信息很多，信元流的空間又不夠。

　　可以對上面的這種方案進行一下優化，把信元的定義更改為：

　　typedef struct __ELEMENT_ST

     {

          ELE_TAG tag;

          ELE_LEN len;

          ELE_VALUE value;

          ELEMENT_ST  *pnext_ele;//下一個信元流

     }ELEMENT_ST；

　　將信元流的定義更改為：

        typedef struct __ELEMENT_STREAM_ST
        {
            MOD_ID src_mod;
            MOD_ID des_mod;
            ELE_MSG_TYPE type;
            ELEMENT_ST  *pfirst_ele;//第一個信元流
        }ELEMENT_STREAM_ST;

　　將信元流和信元更改為動態申請的內存。這樣既可以提高效率，有沒有了大小的限制。

　　需要增加兩個接口，來申請和釋放信元流。

　　唯一不好的地方時，動態申請的內存需要程序員記得釋放，否則會內存泄露。不過還有一個方法，即增加一個申請信元流的函數，如下
        ELEMENT_STREAM_ST *GetEleStream()
        {
            static     ELEMENT_STREAM_ST *pstream = NULL;
            if (NULL != pstream)
            {
                FreeEleStream(pstream);   
                pstream = NULL;
            }
            pstream = AllocteEleStream();
            return pstream;
        }

　　這樣的話，通過函數GetEleStream獲取的信元流，只在函數范圍內有效，退出函數后，立即無效。