socket套接字的处理

kaede_1

现在开发一个项目，遇到的问题可以抽象出下面这个简化问题：
一个服务S，内有300个线程，往客户端C发数据，C端数量在几百个以内，可能有部分线程都会往C发数据，这种情况下socket应该如何创建和维护（考虑性能损失和安全性）？

目前有两个不成熟的想法，希望各位指点：
1.多个线程通过锁抢一个socket
维护三张映射表,map以ip_port为key
    a）vector<mutex>      //某个socket的锁，通过index确定
    b）map<key, socket>  //ip port对应的socket
    c）map<key, index>    //ip port对应的锁的index
每个线程内，数据到来时，先查看ip和port为key是否有对应的socket和mutex，没有则创建，有则上对应的锁后发送数据，之后解锁。

2.每个线程内都维护一组key<---->socket的映射，不需要锁，数据到来后查看这个ip和port的socket是否已经存在，没有则创建，有则直接发送


网络开发经验不多，考虑到频繁关闭套接字很浪费性能，同时多线程抢锁也会损失一定资源，烦请各位指点

hellioncu

为什么要300线程？

kaede_1

回复 2# hellioncu


    服务器后台开发，算是一个需求吧。

    就这个问题可以抛开线程数，就当一个多线程发送

hanzhenlll

如果数据量不大 且延迟不高的话  一个EPOLL 或者Select 足矣搞定300个客户端。

如果数据量大、需要长连接 多交互，那就用线程池来维护，当服务器接收到新的客户端连接就分配一个可用线程去工作，
当线程池不够时 根据需要等待其他线程空余或者再次申请一段线程池。


楼主明白否？

hanxin83

我从未见过如此二之模型!

总有些菜鸟想把简单的socket写得复杂得跟阿尔法狗一样, 天天出各种问题, 才高大上一样!
劳资天天受这种人的烂库的荼毒~~~
直接说最高效可靠的模型吧.

单进程单线程, 要发就发, 没有就连接, 发送区满就缓存.
稳如狗~


(别误会, 我不是喷题主, 我是喷我的同事们)

kaede_1

回复 4# hanzhenlll


    你说的这个开发框架我了解，但我这个不适用。
    我这边server端是推的形式，不是拉。线程接到其他模块的数据后（里面有ip、port）字段，然后往Client发送数据，我关注的是这时的socket如何维护的问题，毕竟频繁创建socket会比较费资源。
    发送数据的频率不一定，看订阅的情况，有的很短、有的1小时、有的1天。

    有什么建议？多谢指教！

kaede_1

回复 5# hanxin83


    即使喷，我也忍了

    单线程确实有他的优势，但是限于我的环境和需求，也只能是目前的框架了，不知在目前这个条件下，对于socket的维护有什么建议？

    多谢哈！

hellioncu

很多问题你都没说清楚：
是TCP么？客户端主动连接服务器并保持长连接么？

BTW：
300个线程，在绝大多数情况下是不合理的设计。

kaede_1

回复 8# hellioncu

  怪我了。

    1、底层封装了TCP
    2、客户端被动接收（会先到另一个模块注册），传到Server端的数据中有这个客户端的ip和port，然后send。
    框架上可能有点别扭，但业务逻辑是这样的，先假定在这个现有条件下吧，如何维护？  多谢！

BTW：
    如果方便的话，简单说一下300线程不合理的原因，多谢哈！

VIP_fuck

线程数量跟cpu核数量差不多才合理一些，300个，貌似没有必要。目的主要还是多连接吧？epoll应该ok。