之前因為工作需要所以有過IM的相關調研，不過感覺當時做的東西，太不滿意了。所以現在准備重新做一遍，順便記錄下整個記錄過程。
先描述一下環境。IM服務器C#語言編寫，采用UDP協議，最大傳輸內容8K。消息的實現過程相對簡單獲取消息處理消息，如下圖
然後我們在業務邏輯裡邊將消息再發送給另一個客戶端，那麼消息服務器的業務邏輯就算完成了。Ok，或許你覺得這個太簡單了，完全不像是消息服務器的邏輯，但是，消息服務器的本質就是這樣，接收到消息，然後轉發。
但是消息多了之後，我們的業務邏輯中勢必會進行各種各樣的判斷，用於確定消息分類型，然後區別對待，並且進行下一步處理。既然這樣，為了方便，消息服務器中一般會引入一個概念，叫做消息路由主要是在獲取到消息之後，判斷消息類型，然後將不同類型的消息推送到具體的處理邏輯中去。到這一步，消息服務器圖應該緩一緩了。如下圖
其實這個時候，簡單的框架已經搭建起來，我們已經做到不同消息的傳達，比如說登陸，比如說發送消息，比如說獲取自己的資料，都可以做的到。但是現在的消息機制是不完善的，並且過於依賴於網絡，所以我們需要一種機制來記錄，我們發送的消息。
消息的生命周期：
消息的生命周期，是在兩個地方共同完成的，發送端發送消息，接收端接收消息，處理並發送回執，客戶端接收回執，完成消息。
發送端周期，消息一旦被發送就開始了周期，在規定的時間內，接收到消息的回執則為消息被響應，否則為消息超時（消息超時後，則客戶端不再響應該消息）。如下圖
接收端周期，接收到消息之後，直至消息處理完成，則消息完成生命周期。
框架上應該已經沒有什麼東西可以阻擋我們前進了，剩下的基本上就是業務上的邏輯了。
登錄、獲取當前登錄的人、轉發消息。一個小型的IM系統已經做完。先上半成品效果圖
此項目，會漸漸開源，未經允許不能商用，僅僅作為學習理解IM使用
