socket套接字的處理

kaede_1

現(xiàn)在開發(fā)一個項目，遇到的問題可以抽象出下面這個簡化問題：
一個服務(wù)S，內(nèi)有300個線程，往客戶端C發(fā)數(shù)據(jù)，C端數(shù)量在幾百個以內(nèi)，可能有部分線程都會往C發(fā)數(shù)據(jù)，這種情況下socket應(yīng)該如何創(chuàng)建和維護（考慮性能損失和安全性）？

目前有兩個不成熟的想法，希望各位指點：
1.多個線程通過鎖搶一個socket
維護三張映射表,map以ip_port為key
    a）vector<mutex>      //某個socket的鎖，通過index確定
    b）map<key, socket>  //ip port對應(yīng)的socket
    c）map<key, index>    //ip port對應(yīng)的鎖的index
每個線程內(nèi)，數(shù)據(jù)到來時，先查看ip和port為key是否有對應(yīng)的socket和mutex，沒有則創(chuàng)建，有則上對應(yīng)的鎖后發(fā)送數(shù)據(jù)，之后解鎖。

2.每個線程內(nèi)都維護一組key<---->socket的映射，不需要鎖，數(shù)據(jù)到來后查看這個ip和port的socket是否已經(jīng)存在，沒有則創(chuàng)建，有則直接發(fā)送


網(wǎng)絡(luò)開發(fā)經(jīng)驗不多，考慮到頻繁關(guān)閉套接字很浪費性能，同時多線程搶鎖也會損失一定資源，煩請各位指點

hellioncu

為什么要300線程？

kaede_1

回復(fù) 2# hellioncu


    服務(wù)器后臺開發(fā)，算是一個需求吧。

    就這個問題可以拋開線程數(shù)，就當一個多線程發(fā)送

hanzhenlll

如果數(shù)據(jù)量不大 且延遲不高的話  一個EPOLL 或者Select 足矣搞定300個客戶端。

如果數(shù)據(jù)量大、需要長連接 多交互，那就用線程池來維護，當服務(wù)器接收到新的客戶端連接就分配一個可用線程去工作，
當線程池不夠時 根據(jù)需要等待其他線程空余或者再次申請一段線程池。


樓主明白否？

hanxin83

我從未見過如此二之模型!

總有些菜鳥想把簡單的socket寫得復(fù)雜得跟阿爾法狗一樣, 天天出各種問題, 才高大上一樣!
勞資天天受這種人的爛庫的荼毒~~~
直接說最高效可靠的模型吧.

單進程單線程, 要發(fā)就發(fā), 沒有就連接, 發(fā)送區(qū)滿就緩存.
穩(wěn)如狗~


(別誤會, 我不是噴題主, 我是噴我的同事們)

kaede_1

回復(fù) 4# hanzhenlll


    你說的這個開發(fā)框架我了解，但我這個不適用。
    我這邊server端是推的形式，不是拉。線程接到其他模塊的數(shù)據(jù)后（里面有ip、port）字段，然后往Client發(fā)送數(shù)據(jù)，我關(guān)注的是這時的socket如何維護的問題，畢竟頻繁創(chuàng)建socket會比較費資源。
    發(fā)送數(shù)據(jù)的頻率不一定，看訂閱的情況，有的很短、有的1小時、有的1天。

    有什么建議？多謝指教！

kaede_1

回復(fù) 5# hanxin83


    即使噴，我也忍了

    單線程確實有他的優(yōu)勢，但是限于我的環(huán)境和需求，也只能是目前的框架了，不知在目前這個條件下，對于socket的維護有什么建議？

    多謝哈！

hellioncu

很多問題你都沒說清楚：
是TCP么？客戶端主動連接服務(wù)器并保持長連接么？

BTW：
300個線程，在絕大多數(shù)情況下是不合理的設(shè)計。

kaede_1

回復(fù) 8# hellioncu

  怪我了。

    1、底層封裝了TCP
    2、客戶端被動接收（會先到另一個模塊注冊），傳到Server端的數(shù)據(jù)中有這個客戶端的ip和port，然后send。
    框架上可能有點別扭，但業(yè)務(wù)邏輯是這樣的，先假定在這個現(xiàn)有條件下吧，如何維護？  多謝！

BTW：
    如果方便的話，簡單說一下300線程不合理的原因，多謝哈！

VIP_fuck

線程數(shù)量跟cpu核數(shù)量差不多才合理一些，300個，貌似沒有必要。目的主要還是多連接吧？epoll應(yīng)該ok。