下午完成了java代碼的實現, 源代碼亦轉移至github了, 地址: https://github.com/xzwdev/stmp.git
這個部分開始描述STMP協議在事務上的處理, 其實這部分與TCAP基本上保持了一致, 只是多了幾個事務原語定義, 下面一一道來.
在描述這些事務原語之前, 必需先提一下STID(源事務ID)和DTID(目的事務ID), 所謂源和目的, 只是相對的概念, 只要這個事務ID是本地(自己)生成的, 站在本地的角度,
那它就是一個源事務ID, 否則它就是一個DTID, 有了這兩個ID, STMP協議的事務邏輯才得以成立.
1. TRANS_BEGIN(事務開始)
BEGIN用於開始一個事務, 通信雙方都可以發起, 它有一個必要的字段, 即STID, 它用於在本地鏈路上標識一個唯一的事務, 在有些TCAP的實現中, 它可以是1 ~ 4
四個字節, 也就是支持uchar, ushort, uint三種類型的事務ID. 不同的長度決定了併發事務的個數, STMP並沒有要求STID的長度或類型, 也就是說, 你可以將它置
成一個字符串, 以類似於HashMap<String, Msg> 這樣方式來持有事務, 一個BEGIN總是這樣發生:
一個BEGIN發出之後, 在本地即開始了一個事務, 事務不可能無限期持有, 因此, 嚴謹的代碼在這裏會開啓一個定時器, 超時到來時, 即可將事務異常結束. 從這一點
上來看, 如果你發出一個BEGIN, 那多半會期待對方有一個響應. BEGIN消息不應該攜帶DTID, 這沒有意義.
2. TRANS_END(事務結束)
END用於正常結束一個事務, 通信雙方都可以發起. 它有一個必要的字段, 即DTID, 也就是說本地鏈路至少收到過對端的一個事務ID, 這樣纔有結束一個對端事務
的可能, 一個簡單的END可能是這樣發生:
一個END發出或收到後, 應該正常結束一個事務.
3. TRANS_CONTINUE(事務繼續)
CONTINUE一般在某個事務開始後, 後續的報文無法立即產生, 或因當前報文過大而需要分成多個報文陸續發出. TCAP的CONTINUE需同時攜帶STID和DTID, 這
有一點強制的意味, 因爲它將導致下面的流程成爲不可能:
STMP對此不作強制, 如果當前的CONTINUE無法得到DTID, 你一樣可以繼續, 一個TCAP和STMP兼容的CONTINUE場景可能是這樣:
4. TRANS_SWITCH(事務前轉)
SWITCH和FORWARD類似, 它用於前轉一個消息到第三方, 較複雜的場景可能纔會用到, 如下:
最早發起SWITCH的A和最晚接收到SWITCH的C維持着一個事務, 而B則對此漠不關心, 它只起到一個網關的作用, 因此, 在這個時間點上, B是無狀態的.
SWITCH應該總是攜帶一個路由信息, 以便角色B能正確路由到C或者B的下一跳. STMP協議沒有定義路由信息格式, 可自行設計.
TCAP沒有定義TRANS_SWITCH原語.
5. TRANS_ABORT(事務中斷)
ABORT是END的暴力或異常版本, 它用於明確告之對端, 當前事務發生了異常, ABORT發起的時機與END保持一致. 可參考上面的TRANS_END流程.
6. TRANS_CANCEL(事務取消)
CANCEL發生在一個BEGIN發出後, 且沒收到任何響應之前, 也就是緊挨着BEGIN發出, 並攜帶一個STID, 用於取消BEGIN產生的事務, 流程如下:
TCAP也沒有定義TRANS_CANCEL原語.
7. TRANS_UNI(單向消息)
如果你不需要在當前鏈路上產生事務, 則可以使用UNI原語, 因此也不需要攜帶STID或DTID, UNI總是這樣發生:
太晚了, 改天繼續.