需求如下：
服務器端 BS架構 使用 webform 或 mvc 都可以
客戶端 CS架構 使用 winform
客戶端的數量不確定，大于等于1，小于等于100
服務器端與客戶端是一對多的關系
服務器端系統有固定的IP地址和埠號，始終對外保持監聽，客戶端程式啟動以后，自動連接服務器端，如果被服務器端監聽到，則雙方建立連接，如果是第一次訪問，就在資料庫表里插入一條資料，記錄該客戶端的IP地址，如果不是第一次訪問，說明該客戶端資訊已存在，則更新一下最近一次的連接時間
服務器端系統中有一個頁面，把資料庫表中的所有記錄用表格的形式顯示出來，如果某個客戶端和服務器為連接狀態，則該條記錄高亮顯示，如果某個客戶端和服務器未連接，則該條記錄的背景色為灰色
因為會有多個客戶端同時操作，隨時可能建立連接或者取消連接，所以上面那個頁面每分鐘自動重繪一次，實時更新客戶端的連接狀態
上面那個頁面的表格中有兩列，
一列放了一個文本框和一個按鈕，文本框中可以輸入訊息，然后點擊按鈕發送，也就是說該頁面可以給每一個正在連接的客戶端發送訊息（一對一的，不是群發，不是廣播）
還有一列，放一個多行文本框，用來顯示每個客戶端給服務器發送的訊息
請問以上功能如何實作？
webform 和 winform 之間如何進行socket通信？
服務器端（B/S系統，webform 或 mvc）應該如何保持監聽？
希望大家給點兒思路，如果能夠提供源代碼，那就最好了，謝謝！
uj5u.com熱心網友回復：
webform 和 winform通過服務器進行通信。WebClient通過SignalR等網頁實時技術，連接到服務器，允許服務器推送資訊（連接狀態，訊息狀態等等）。
WinFormClient的選擇就更多了，比如也可以用SignalR。
服務器，連接著所有的WebClient，WinformClient，起資訊中轉，派送的功能。
uj5u.com熱心網友回復：
看了半天，我覺得你思路相當混亂！我覺得你還是先理清思路再說。一般好的設計，不會有Web頁面和Winform通信這種需求，因為Web頁面是時刻變化的，你要求它保持一個監聽，這不是扯淡嗎？而樓上說的通過服務器進行通信，拜托，這叫“通信”？
我們也有需要同時使用B/S和C/S的，一般B/S為主，C/S為輔。當需要轉C/S時，直接在Web頁面上提供一個按鈕，以自定義協議的方式啟動本地C/S客戶端，傳入session，直接連到服務器。
多客戶端對服務器的同步/異步操作，網上應該有很多例子的。
uj5u.com熱心網友回復：
額，服務器bs，客戶端cs。？？你是說web服務器，和winform程式么。
webapi 訪問注冊一下就行了。至于你說什么展示頁面，那跟winfrom沒有毛線關系。因為他是脫離的，你是依賴資料庫也好，依賴redis快取也罷，依賴etcd，cosorl注冊中心都無所謂。他本質上無需跟下面通訊，他就是只是一個展示
當然你要跟下面發訊息嘛，websocke可以，mq可以。
本質上你應該隔離，脫離開。不要動不動就玩技術。越玩技術越低級
uj5u.com熱心網友回復：
或者干脆說，你就是一個標準的CS。只是服務器端能有一個webapi承載，以便外部有個html頁面跟他互動。實際上這也是主流方式，比如rabbitmq，他只是標準的服務，但是他內部承載一個webapi（或內部承載和web服務器）他有個html頁面對外顯示
uj5u.com熱心網友回復：
這其實也是以后的主要方向，你看net core和java的spring boot 就明白了。這個兩個都在脫離，net core脫離iis，spring boot脫離tomcat。因為后面的專案不強調什么cs，bs。
后面專案強調隔離和按需配置
你這個玩意，如果按目前的方式開發，其實沒那么麻煩和糾結
后端服務net core，內部承載webapi以便和H5 web展示。內部通訊按需取用，比如一個consoul用來注冊客戶端發現。一個mq，kafaka用來做通訊，就ok了。
后端服務net core 去監控consoul/etcd 的注冊節點（帶過期策略），這個可以用webapi提供給外面展示。內部通訊你是一對多也好，一對一也罷，俺們不管。一個mq，kafaka丟出去，誰愛訂閱誰訂閱。
你點擊一個按鈕，這個按鈕會說，我的publish key是啥，你管他要干嘛，不管，我只會給這個key發，當然這個key你可以etcd/consoul對應的客戶節點上獲取，他上線就給你注冊說“我要這個key的，我監聽這個key的”（過期策略會告訴這節點已下線，你可以不用操作了）
so，整個程序，我們不說什么CS，BS，也不說什么webform，winfrom，跟不說什么socket，singlR，其實以后的專案都會如我上面說的“你別管什么技術，全部脫離，各玩各的，需要配合的時候配合，不需要配合的時候，自己獨立”
uj5u.com熱心網友回復：
樓主的意思大概是需要一個服務端去一直回應客戶端的連接，然后有一個web網頁去看各個客戶端連過來的情況。并且客戶端與服務端的連接情況是實時反饋到網頁上進行查看的。我做過類似的專案，網頁上大概是下面的情況。
跟樓主說一下我做的時候大致的思路。
一開始我也想著，服務端已經有一個web專案部署在IIS上了，那么只需要這個web專案可以隨時的監聽到相關埠，保持和客戶端的通訊就行了，這個簡單，我在web頁面上做一個按鈕，類似于開始監聽這種，點擊按鈕，通過web api介面打開相應業務功能，開始監聽客戶端連接，然后服務端收到的訊息后處理客戶端連接的訊息，再通過signalR來主動地把服務端訊息推送到web頁面，來完成實時的訊息更新。
后來我發現web專案的服務端去做一些比較"主動"的事情的時候總是吃力的，因為IIS總是用來回應客戶端的請求，http連接總是連接完畢后就釋放了，它是無狀態的你無法通過web api來確認一個客戶端是否在線，除非你有在客戶端做定時發送心跳這種處理。再然后，比如我的Web專案有api更新，需要我重新發布內容的時候，我的監聽功能也會被迫關閉，發布完成后需要重新打開。并且通過服務端主動地向web頁面推送訊息這么看起來也不是特別的“服務端”，總是覺得很別扭，特別是當你推送的內容需要跟前臺登錄地權限掛鉤時，這些東西設計起來就變得有一些復雜。
后來我就另外起了一個控制臺應用，將所有主動的事情都放在了這個控制臺里進行，控制臺應用一直開著，埠就一直保持監聽的狀態，這就非常的"主動"了，控制臺應用接收到的所有的資料，該存資料庫存資料庫，如果web網頁需要頻繁查詢的一些資料，包括一些訊息推送的佇列，我選擇存在了redis里。包括你希望的在網頁端通過點擊一個按鈕向各個客戶端發送訊息，通過redis的訂閱和發布功能，你都可以辦到。
那么web端網頁訊息的實時更新我也不再選擇使用signalR去主動推送，由前端自己定義定時器來輪詢向服務器發送請求。最后完成的效果還可以。
這樣的話負責處理客戶端連接和訊息處理的是控制臺程式，web后臺僅僅作為查詢和展示。
最后，將這個控制臺程式注冊為windows服務設定開機自動啟動，就可以了。
最后我本人是個新手，以上僅供參考。
轉載請註明出處，本文鏈接：https://www.uj5u.com/net/127350.html
標籤：C#