第四章 系統設計與實作
4.2 伺服器端之系統設計
4.2.5 伺服器面對客戶端要求之處理過程
以下就以幾個實例來說明上述之伺服器端結構，在實際收到使用者要求之詳細運作 過程。
4.2.5.1 聯絡人上線狀態之維護
現在有一客戶端程式登入伺服器端，伺服器會在 USER_ACTIVITIES 建立一筆新紀 錄，記錄目前客戶端之 UID、SESSION ID 以及登入時的時間。登入後後客戶端可使用 api_set_presence 設定客戶端擁有之聯絡人上線狀態。
使用者欲存取聯絡人資料，用瀏覽器從 Web 介面登入系統。Web 介面使用 api_get_contacts 要求聯絡人清單，並在 Web 介面顯示出來。
若客戶端程式登出系統，伺服器端會清除 USER_ACRIVITIES 中，該次登入所建立 之登入階段記錄，並檢查是否還有客戶端在線上，若已無其他登入的客戶端，則將該使 用者所屬之聯絡人狀態設定為 MSN/SKYPE_UNKNOWN。
但若客戶端不正常離線（如網路斷線），則該筆記錄在無法在登出時被清除，伺服 器也無法主動檢查資料庫中是否有已經逾期的登入階段（因為 Web 伺服器乃是一被動 之伺服端架構），所以需要一個方法讓伺服器在接受客戶端要求時，能順便進行清理逾 期登入階段之工作。
因為登出程序涉及的有使用者活動狀態，以及聯絡人上線狀態的變動，而涉及這兩 種資訊的取得的 API 有 api_user_login、api_get_activities 與 api_get_contacts 三種。伺服 器端會在執行這三個 API 時，隱含地檢查 USER_ACTIVITIES 中是否有逾期的登入階段 記錄，若有，則為該登入階段執行必要的登出程序（清除該記錄，重設聯絡人狀態）。
如此，雖然資料庫中的資料不是時時保持新鮮，卻可以確保在使用者要求時可以獲得最 新的狀況。
4.2.5.2 即時通訊
若使用者透過 Web 介面要求與某個聯絡人通訊，伺服器會根據使用者要求的方式，
從伺服器端資料庫取出該位聯絡人的聯繫資料。而要怎麼呼叫客戶端的對應程式呢？系 統會產生一組 URI(Universal Resource Indicator)，瀏覽器收到這組 URI，會叫起對應的 客戶程式來處理。
URI 格式會有兩種情況：如果客戶端的即時通訊程式本身有處理 URI 的能力，則會 直接回傳該程式所認識之 URI 協定（如 skype:、mailto:…等）；而如果客戶端的即時通 訊程式無法處理 URI，則會由我們的客戶端程式代為呼叫。此情況所回傳之 URI 協定格 式 為 contacto:[MESSENGER ACCOUNT]?[METHOD] ， 例 如 客 戶 端 要 求 與 [email protected] 以 MSN Messenger 進行文字交談，而 MSN Messenger 沒有處理 URI 的能力，則伺服端會回傳：contactto:[email protected]?msn_text 這樣的 URI，瀏覽器 收到以後，會呼叫我們的客戶端程式，客戶端程式分析此 URI，再叫起 MSN Messenger，
並打開與 [email protected] 的文字交談視窗。
4.2.5.3 聯絡人管理
聯 絡 人 管 理 所 涉 及 的 資 料 庫 表 格 有 三 個 ： CONTACTS 、 GROUPS 、 GROUP_ENTRIES。以下以刪除某個聯絡人、與刪除某個群組的程序來說明此三個表格 的關聯互動情況。
若伺服端收到刪除某個聯絡人CIDC的要求(api_delete_contact)，伺服器端會先從 GROUP_ENTRIES找出所有ID欄位為CIDC之紀錄，並將之刪除，即刪除所有包含此聯絡 人之群組裡，代表此聯絡人之元素。接下來伺服器端會在CONTACTS表格裡找到CIDC， 並刪除該記錄，即刪去此聯絡人。至此，一個聯絡人已經成功從伺服端被刪除，
CONTACTS CID Name
GROUP_ENTRIES GID ID
GIDX GIDF
GIDY CIDC
GIDZ CIDC
a. b. 刪除ID為CIDC之元素 – 即GIDY、GIDZ不再包含CIDC
GROUPS GID Name GIDF Group F GIDG Group G GIDH Group H
GROUP_ENTRIES
圖9 從資料庫中刪除Contact C (CIDC)之過程