求socket监听50W客户端的解决方案

Question

首先我先问下.我监听客户端(几十万硬件)发来的数据,我直接用C#写一个exe在服务器上运行 这样合理吗?
如果合理 那看下代码(不考虑服务器的配置) 这样做会不会有问题 客户端就不写了 因为是硬件 我也没有 暂时是模拟的 所以 只看服务端的东西 /// <summary>
        /// 负责监听 客户端段 连接请求的  套接字
        /// </summary>
        Socket sokWatch = null;
        /// <summary>
        /// 负责 调用套接字， 执行 监听请求的线程
        /// </summary>
        Thread threadWatch = null;        //开启监听 按钮
        private void btnStartListen_Click(object sender, EventArgs e)
        {
            //实例化 套接字 （ip4寻址协议，流式传输，TCP协议）
            sokWatch = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp);
            //创建网络节点对象 包含 ip和port
            IPEndPoint endpoint = new IPEndPoint(IPAddress.Parse(txtIP.Text.Trim()), int.Parse(txtPort.Text.Trim()));
            //将 监听套接字  绑定到 对应的IP和端口
            sokWatch.Bind(endpoint);
            //设置 监听队列 长度为10(同时能够处理 10个连接请求)
            sokWatch.Listen(10);
            threadWatch = new Thread(StartWatch);
            threadWatch.IsBackground = true;
            threadWatch.Start();
        }
其中 StartWatch方法 是有客户端连接的时候 执行的操作(比如把连接放到集合里)然后 每次有客户端发送消息的时候 一下代码在另外一个cs里
 
this.threadMsg = new Thread(RecMsg);
this.threadMsg.IsBackground = true;
this.threadMsg.Start();
void RecMsg()
{
   while (isRec)
   {
      //这里面 是接收byte[] 然后 我解析之后 insert 到数据库里了
   }
}我自己测试100客户端 同时上传数据 目前来看 是没什么问题..但是 客户端(硬件)不仅仅是这么多 几十万 几百万 都有可能..所以 我这样的设计  合理吗?  如果不合理,会产生什么问题?

Answer 1

就一个服务器，TCP你想都别想50W。
这还用问合理N个服务器才能实现。要是你走UDP，就不一定了，只做收发其他不管

Answer 2

UDP 是我把ProtocolType.Tcp修改成udp就行了吗??目前来说 我也是接收-解析-insert

Answer 3

void StartWatch()
        {
            while (isWatch)
            {
                try
                {
                    //threadWatch.SetApartmentState(ApartmentState.STA);
                    //监听 客户端 连接请求，但是，Accept会阻断当前线程
                    Socket sokMsg = sokWatch.Accept();//监听到请求，立即创建负责与该客户端套接字通信的套接字
                    string ClientIP = ((System.Net.IPEndPoint)sokMsg.RemoteEndPoint).Address.ToString();
                    ConnectionClient connection = new ConnectionClient(sokMsg, ShowMsg, RemoveClientConnection);
                    //将负责与当前连接请求客户端 通信的套接字所在的连接通信类 对象 装入集合
                    dictConn.Add(sokMsg.RemoteEndPoint.ToString(), connection);
                                 }
                catch (Exception ex)
                {                    ShowMsg(ex.Message);
                }
            }
        }
        #endregion

Answer 4

楼主应该考虑weservie进行互动

Answer 5

楼主应该考虑WCF进行互动
如果想死得更快

Answer 6

楼主可以使用LoadRunner 测试一下  模拟多个用户访问你写的服务程序  看看最多能承受多大

Answer 7

50W客户端并不等同50W的并发访问，你应该考虑的是，在客户端可能的最长交互时间之内产生的并发量，与服务器能支持的Listen的最大值
如果并发量不高，你用独立线程是可接收的
如果太高，则会产生过多的子线程，此时应该使用begin-end异步方式，这一般也是首选，系统封装好的，可靠性比较好

Answer 8

楼主有测试结果吗？如果是TCP做的话
请使用“异步编程”APM（beginXXX EndXXX之类的）不要使用多线程 因为在服务端  如果有1000个用户连入  使用多线程的话  那么需要1000个线程接收数据  这是不可能的  异步编程主要不是通过多线程实现的  所以性能上应该会好很多如果UDP做的话
我觉得 用哪个都差不多  每个终端都是平等的  数据接收只需要一个线程就够另外 异步编程和多线程的区别 请参照 http://social.msdn.microsoft.com/Forums/vstudio/en-US/fa9e1830-ef06-4dd1-8ef7-59ebf04ab1e6/asynchronous-vs-threading

Answer 9

几十万，几百万，看到这个量，我第一反应就是 完成端口。
http://blog.csdn.net/wewaa/article/details/2973020
而且服务器肯定不能只有一台，肯定是集群。

Answer 10

我看到50W的标题，我和我的小伙伴惊呆了，做连接数限制，还有借助成熟的nio框架

Answer 11

其实我觉得楼上说得也可以，如果数据交换频率不高用http吧，socket 50w个连接吓人啊。

Answer 12

建议UDP吧,没其它好讲的.QQ都还在使用呢

Answer 13

看你的标题党，以为你做过什么。可是看你的代码，在按钮上“监听”（btnStartListen_Click），以及所谓的“设置 监听队列 长度为10”，以及所谓的while循环代码，等等，这其实跟那些非软件专业的学生去报名一个培训班时的水平是一样的，我认为你如果出于这种阶段，那么最好脚踏实地地去找个公司上班。

Answer 14

UDP是必须的，TCP即使是短连接也危险如果只接收分析，不需要应答之类的没什么难度

Answer 15

 ProtocolType.Tcp修改成 ProtocolType.Udp
就OK了么???