本期內容大綱

• <編輯手札> ─ 廣告非廣告 

• <訊息論壇> ─ iPush Server V2 訊息保證送達技術剖析

• <訊息先生信箱> ─ iPush Server V1.x 與 V2 MySQL 的存取相容性確認 / 為何再上線後收不到離線期間的 Persistent 訊息？

• <艾揚快訊> ─ 兩岸實力派廠商會師武漢，艾揚夥伴日展現即時訊息技術於民生之大用 (02.17)

廣告非廣告

三月份艾揚將舉辦兩項活動，一是三月中旬的「iPush^® Server 與 GIS 整合應用研討會」，一則是三月底的「iPush^® Server V2 教育訓練課程」(假恆逸資訊教育訓練中心辦理)。在這邊做個預告，看似廣告，卻又非廣告。

要說是廣告那可得老王賣瓜一下，少不了自吹自擂，說不定還要打出個俊男美女牌 (最近 Janet Jackson 、如花和上流美好像很紅，說不定可以申請一下經費…… )，不過實際上值得興奮的事情跟這些資訊展流行風八竿子不著邊，這兩個活動好像都很嚴肅、正經八百的，請立正站好準備迎接開場。

回歸主題那可是非廣告，這兩個活動都是落實艾揚對於 Developer社群的大事。首先，由於在  2003  年當中，即時、遠距、多點訊息擷取傳遞架構在 GIS 業界獲得廣大的迴響，我們與許多 Partner 共同發展出極具商業價值的整合應用，迫不及待的想和大家分享這些成果，這項研討會歡迎對於 GIS 與即時訊息技術整合相關的 Developer 與軟硬體業者共襄盛舉。其次，緊接著在三月底要辦理的「iPush^® Server V2 教育訓練課程」，這可不是第一次舉辦了，從去年開始，這項融合艾揚技術開發精華的課程已經辦過幾次，也因為過去舉辦的經驗，今年我們特別把課程區分為基本課程與進階課程，讓學習的效果更好，詳細的課程時間表與授課內容已經上網，請到 ICE DC 瞭解詳細內容。

有同時使用過 ICQ 與 MSN Messenger 這兩個傳訊軟體的讀者就會知道，對於已經離線 (Offline) 的朋友，在 ICQ 中，您是可以發送離線訊息給他的，但 MSN Messenger 則否。這差別就在 Server 會不會幫接收者儲存離線訊息。

像 ICQ 這樣會幫使用者儲存離線訊息，待其下次上線 (Online) 後，再傳送給他的傳訊功能，即是訊息保證送達 (Guaranteed Message Delivery) 的一種應用。

iPush^® Server V2 很重要的大區塊功能增加，即是有了訊息保證送達的能力。以下是我們對這個能力的技術說明。

Pub / Sub 與 P2P 兩種訊息傳遞模式均能啟用訊息保證送達的能力；但當然，在 P2P 下，只有一位 Subscriber 會收到該保證送達之訊息

要能夠應用 iPush^® Server V2 訊息保證送達的能力，必須具備下列三個要件：

• 保證送達只針對 Subject 訊息；Channel 訊息無此能力。

• 發送者必須傳送 Persistent  (持續性) 訊息給 iPush^® Server。

• 接收者必須向 iPush^® Server 進行 Durable (持久性) 訂閱。

我們來看如下的作業示意圖：

作業流程步驟敘述如下：

1. 發送者 (Publisher) 針對某一 Subject 傳送 Persistent 訊息給 iPush^® Server。叫用函式為 ipushSendPSubjectData() 或 ipushSendPQueueSubjectData()。

2. iPush^® Server 收到該 Persistent 訊息後，會將其儲存起來 (儲存介質為 File 或 Database)。

3. iPush^® Server 成功儲存後，會送一個回應訊息 (Acknowledgement) 給發送者。

4. iPush^® Server 根據 Subscription Mapping，將儲存的 Persistent 訊息，主動推播給上線的 Durable 訂閱接收者。Durable 訂閱接收者為先前叫用函式 ipushSubDSubject() 訂閱該 Subject 的使用者。

5. 收到該訊息後，該接收者會送一個回應訊息 (Acknowledgement, ACK) 給 iPush^® Server。

6. iPush^® Server 收到回應訊息後，即會將該遞送完成的訊息，從儲存介質中移除。

這樣的作業流程，非常的直覺易懂，但其中的某些環節，還是值得深入探究，以便 Developer 在開發應用時，可以更加貼切。

而前三個步驟與後三個步驟各自獨立運作，讓發送者與接收者以 iPush^® Server 隔開不相關，體現的即是 Loosely-coupled (低耦合系統)，與 Asynchronous Programming (非同步程式設計) 的精神。

我們繼續深入各環節討論下去。

在步驟 2，iPush^® Server 會根據收到 Persistent 訊息時的叫用函式種類，來決定該訊息是處於 Pub/Sub 還是 P2P 傳遞模式，來決定是要儲存一份還是多份。

若是處於 Pub/Sub 傳遞模式 ，則還要加上當時的 Subscription Mapping，來決定實際儲存的份數，以便每一位 Subscriber 都可以收到一份該訊息。

在步驟 3，我們可以指定送 Persistent 訊息出去後多久的時間內，若是 iPush^® Server 沒有 ACK 回應，就判定為 Timeout。

ActiveX API

利用 Property ackTimeout 來設定 ACK Timeout 時間。

預設 ackTimeout 為 10000 ms，即 10 秒。

Java Class API

利用函式 ipushSetAckTimeout() 來設定 ACK Timeout 時間。如下所示：

public long ipushSetAckTimeout(int index, long timeout)

其中的 timeout 即為 ACK Timeout 時間，屬 long 資料型態，單位為 ms (毫秒)。若不叫用此函式，系統預設為 10000 ms，即 10 秒。

有別於一般的訂閱方式 (Non-durable Subscription)，在進行 Durable Subscription (持久性訂閱) 函式呼叫時，除了給予要訂閱的 Subject Name 外，還要再多給一個 Durable Name (最大長度為 224 個字元)，以便讓 iPush^® Server 進行 Subscription Mapping 作業。

當使用者對  iPush^® Server 進行 Durable Subscription 後，即使該使用者離線，在這期間只要是有其訂閱 Subject 的 Persistent 訊息到來，iPush^® Server 還是會為其進行儲存的作業。待其下次上線，再次進行同一 Subject，同一  Durable Name 的 Durable Subscription，即會將屬於他的訊息推送過去給他。

相關函式呼叫說明如下：

<訂閱>

ActiveX API

只要是叫用 Durable Subscription 的函式，就必須在參數中給定 Durable Name，如下 ipushSubDSubject() 所示者：

void ipushSubDSubject(BSTR subject, BSTR name)

其中的 name 即為 Durable Name，屬 BSTR 資料型態，其最大有效長度為 224 個字元。

Java Class API

只要是叫用 Durable Subscription 的函式，就必須在參數中給定 Durable Name，如下 ipushSubDSubject() 所示者：

public void ipushSubDSubject(int index, String subjects, String name)

其中的 name 即為 Durable Name，屬 String 資料型態，其最大有效長度為 224 個字元。

<取消訂閱>

ActiveX API

與訂閱對應，也一樣要在參數中給定要取消的 Durable Name，如下 ipushUnsubDSubject() 所示者：

void ipushUnsubDSubject(BSTR subject, BSTR name)

其中的 name 即為要取消訂閱的 Durable Name，屬 BSTR 資料型態，其最大有效長度為 224 個字元。

Java Class API

與訂閱對應，也一樣要在參數中給定要取消的 Durable Name，如下 ipushUnsubDSubject() 所示者：

public void ipushUnsubDSubject(int index, String subjects, String name)

其中的 name 即為要取消訂閱的 Durable Name，屬 String 資料型態，其最大有效長度為 224 個字元。

<訊息接收處理>

接收者隨 Subject 訊息接收到的 durableName 參數值 (ActiveX Event) 或 durname 參數值 (Java interface) 可以得知訊息的 Durable Name。

ActiveX API

iPush^® Server 推送 Subject 訊息給訂閱者接收時，接收者的 API 會丟出 Event SetSubjectData()，其中的 durableName 參數值即是該訊息的 Durable Name，如下所示者：

SetSubjectData(BSTR subject, BSTR durableName, VARIANT* data, long connId, long msgId)

其中的 durableName 為 BSTR 資料型態；若其長度為 0，就表示這是一個Non-durable Subscription 訊息。

Java Class API

iPush^® Server 推送 Subject 訊息給訂閱者接收時，接收者的 API 會丟出 interface iPush2MsgListener 中的 Method onSubjectMessage()，其中的 durname 參數值即是訊息發送者的 Durable Name，如下所示者：

public void onSubjectMessage(int ipushno, String subject, String durname, byte msg[], int msglen, int CID, long MsgID)

其中的 durname 為 String 資料型態；若其長度為 0，就表示這是一個Non-durable Subscription 訊息。

在步驟 6，iPush^® Server 在收到接收者的回應訊息後，即會將先前為該接收者儲存的 Persistent 訊息移除。

另一個 iPush^® Server 會自儲存介質移除 Persistent 訊息的時機，即為該訊息的有效期限 (Time-To-Live) 已到。詳情請參考上期電子報。

雖然系統也會儲存 Non-persistent 訊息，但因為 iPush^® Server 在傳送 Non-persistent 訊息給 Durable Subscription 使用者時，並不會等待一個個的 ACK 回應，所以若是 Non-persistent 訊息過多，或是連線情況不佳，可能會被  iPush^® Server 視為壅塞，進而丟棄處理。

所以在開發設計應用系統時，應該避免使用 Durable Subscription 來接收 Non-persistent 訊息，以免有意想不到的結果產生。

結論就是：要應用 iPush^® Server V2 的訊息保證送達能力來實作應用系統，就切記訊息收送的黃金組合為：

Guaranteed Delivery = Persistent Message Publishing + Durable Subscription　

[訊息先生信箱] Ask Mr. Message    Mr. Message  

<Developer Tony 來信詢問>

根據上期電子週報的答覆，我想再次確認，是不是原本使用於 iPush^® Server V1.x 的 MySQL 資料庫，可以直接讓  iPush^® Server V2 使用？

還有一個問題是：我使用 ActiveX API 來開發應用程式，叫用了 ipushSubDSubject()，在線上接收訊息沒有問題，但為何離線後再次上線，卻收不到送給該訂閱者的 Persistent 訊息呢？(我確定在該訂閱者離線期間，有多個 Persistent 訊息送進同一 Subject) 

<Mr. Message 的答覆>

Tony 您好，針對您的兩個問題，答覆如下：

1. 是的，沒有錯，原本使用於 iPush^® Server V1.x 的 MySQL 資料庫，可以直接讓  iPush^® Server V2 存取，原本已經存在的 Service / User 等資料，都可以直接沿用。

2. 請注意，離線再上線後，若應用程式沒有再次以同一 Subject、同一 Durable Name 叫用 ipushSubDSubject(BSTR subject, BSTR name)，那 iPush^® Server 並不會將為 Durable 訂閱者留存的訊息傳送過來。所以切記，再次上線後，一定要再呼叫一次 ipushSubDSubject()，這樣訂閱者才會收到離線期間要給他的 Persistent 訊息。

歡迎來函詢問 Mr. Message 任何與訊息有關的技術、產品、應用、實作、商務問題，Mr. Message 必將竭誠答覆。

<快訊>

兩岸實力派廠商會師武漢，艾揚夥伴日展現即時訊息技術於民生之大用 (02.17)

2004 年 2 月 17 日，由艾揚科技(武漢)有限公司主辦，武漢市政協台港澳僑暨海外聯絡委員會協辦，武漢土木建築學會計算機專業委員會為指導單位的「艾揚夥伴日2004：即時訊息的力量」活動，在武漢香格里拉大飯店圓滿落幕。

本次活動計有武大吉奧、泓格科技、精業公司、崧旭資訊、廈門帝岡、柏眾網控、柏元網控等兩岸多家從事工控、物業監控、水務、氣象、疾病管制、勤務管制與派遣等領域的知名系統整合與嵌入式系統製造商參與。這些兩岸領導廠商均使用艾揚的 iPush^® Server 與 iPush^® Embedded 中介軟體來解決相關資訊系統在遠距離下的即時監控問題。此次會師武漢，向各產業與事業單位主管展示艾揚夥伴的示範應用，除彰顯即時訊息技術所能創造的效益與價值外，也充分突顯了艾揚與夥伴協助各產業引進即時訊息解決方案的實力。

據艾揚科技(武漢)有限公司總經理葉志敏表示，即時訊息技術的應用範圍極廣，以智慧樓宇與智慧社區管理來說，目前存在於市場上的資訊方案，都著重在物業管理者使用的功能，普遍無法讓業主或居民直接查看。現在透過與 iPush^® Server 系統整合，就可以讓業主與居民直接上網看到住家或辦公處所的即時畫面，甚至是將瓦斯、電力、溫度等異常警示即時訊息送到民衆的手機或 PDA。

另外，像是用於即時的疾病管制，可以透過與地理資訊系統的整合，在 SARS 或禽流感的疫情統計分析上，可以讓各區域的醫療點或疫情查報人員在以秒爲單位的時間內完成通報，並顯示在電子地圖上，讓決策者可以在最短的時間內，依區域進行不同的應變決策。

此次活動場內冠蓋雲集，武漢市委副書記殷增濤、副市長袁善腊、市人大常委副主任單大年等要員均出席並致詞，除表達對本次活動推動以高新技術來增進人民生活現代化、資訊化之肯定外，並對艾揚科技(武漢)公司正式掛牌營運表示祝賀。

詳細新聞，請連結艾揚科技新聞發佈區 >> Go !

上一期精采內容：新世代訊息技術深度剖析 – 細說 iPush Server V2 (下)

若您覺得本期內容值得參考，請轉寄給認識的朋友或同事，為國內的訊息技術社群發展盡一份力。感謝您。　

回艾揚即時訊息技術電子週報主頁 | 上一期  | 下一期

Copyright 2002-2004, 艾揚科技股份有限公司版權所有；歡迎轉寄。 關於電子報發送有任何問題，或是欲轉載內容，請連絡 icedc@icetech.com.tw 台北市 100 羅斯福路二段 9 號 12 樓之 1 ，TEL: +886-2-2396-1880，FAX: +886-2-2396-1881

Unsubscribe >>
欲取消訂閱艾揚即時訊息技術電子週報 (ICE Messaging Weekly)，請 Mail 至 icedc@icetech.com.tw，
主旨註明：取消訂閱艾揚即時訊息技術電子週報 即可。