一个服务器软件与n个（1000个以上）客户端软件网络通信的问题

[DwyaneCV]

一个服务器软件与多个客户端软件通信，如果是几十个还好，我知道怎么处理，多开几个线程而已。
我想问的是
1.目前项目要求是可能有超过1000个客户端同时与服务器软件进行网络通信，难道我服务器软件要开1000个线程来分别与这1000个客户端进行通信？

2.这1000个客户端软件都是分布在全国各地的远程设备上的软件，都需要向我的服务器软件进行数据传输，我知道要定好协议，关键是会不会出现数据交叉的情况，比如：1号机数据发到1/3，突然由于网络问题停了一会儿，而此时2号机恰巧后2/3的数据来了，然后这两条断续信息组合起来成了完整的信息，会不会有这种情况？如何避免？（偶尔还好可以通过协议滤除，总是这样就头疼了，当然一个客户端一个线程的话是不会出现这种情况）

[DwyaneCV]

引用 9 楼 angel6709 的回复:

短连接能满足需求吗

何为短连接

[DwyaneCV]

引用 6 楼 qq_34266409 的回复:

我先不讨论你设计思路有什么问题，我说下如果是我我会怎么做 你这需求我一看就想起直播间，直播间是双向通信，你这个是一个服务器和1000个客户端通信， 1.这么多客户端我肯定是用线程持的，新开线程开销太大了 2.我不会一直链接这些客户端，只会在需要的时候再去连， 3当客户端要连你的时候它请求过来我再去和它建立链接，我的最大同时连接数可能只有10个，如果一次来的太多我会将它们放入MQ中一个个来处理，因为1000个客户端不可能每个都一直在发消息， 4所以我会和联系比较频繁的一直保持链接，如果一个链接很久没有消息了我会把它释放掉。具体模式你可以参考QQ的通信， 5如果客户端交流非常密切，而且客户端非常交流量很大，我会采用随机把队列中的踢出去的方式来进行通信

这1000个客户端一旦运行，就是每秒定时上发数据的，而且数据量大概是几百个字节，您的意见很具有参考性，谢谢

[angel6709]

引用 12 楼 dwyaneyywade 的回复:

[quote=引用 9 楼 angel6709 的回复:] 短连接能满足需求吗

何为短连接[/quote] Http 等，用完就断开连接，等需要时在连接。

[DwyaneCV]

感谢各位的回复，异步通信是可以高并发的问题，但是实时性如何保证？我做了个实验，一个服务器软件同时与50个客户端进行网络通信，客户端每秒发送数据给服务器软件，然后服务器软件界面上放了50个文本框用于实时显示各客户端来的数据，以1/0显示间断显示，发现每个文本框1/0变化不实时，甚至有的十几秒才变化一次，如何实现这50个文本框可以实时每秒变化一次？

[angel6709]

你的需求是每秒钟post一次？

[angel6709]

通讯数据量多大？

[angel6709]

1000个设备总是在线？

[DwyaneCV]

引用 14 楼 angel6709 的回复:

[quote=引用 12 楼 dwyaneyywade 的回复:] [quote=引用 9 楼 angel6709 的回复:] 短连接能满足需求吗

何为短连接[/quote] Http 等，用完就断开连接，等需要时在连接。[/quote] 我是客户端只每秒发数据，而不用接收数据，您的意思是我所有的客户端每次faw

引用 18 楼 angel6709 的回复:

1000个设备总是在线？

1000个是基础数量了，可能更多，当然就像之前有人说的，更多的话就要考虑负载均衡了，每台每秒几百字节的数据量吧，每台远程设备每秒上传一次数据

[john_QQ:2335298917]

用完成端口吧

[iNeuOS工业互联网]

ServerSuperIO、SuperSocket、netcomm都可以试试。

[吉普赛的歌]

写到数据库不就得了， 不需要搞这么麻烦。

[DwyaneCV]

引用 36 楼 yenange 的回复:

写到数据库不就得了， 不需要搞这么麻烦。

你好，什么写到数据库？网络通信与数据库有关系？。。。。。。

[吉普赛的歌]

引用 37 楼 dwyaneyywade 的回复:

[quote=引用 36 楼 yenange 的回复:] 写到数据库不就得了， 不需要搞这么麻烦。

你好，什么写到数据库？网络通信与数据库有关系？。。。。。。[/quote]

引用 19 楼 dwyaneyywade 的回复:

我是客户端只每秒发数据，而不用接收数据

你的客户端只是发送一下数据， 又不需要接收， 为什么不能直接写入到服务器的数据库？

[DwyaneCV]

引用 38 楼 yenange 的回复:

[quote=引用 37 楼 dwyaneyywade 的回复:] [quote=引用 36 楼 yenange 的回复:] 写到数据库不就得了， 不需要搞这么麻烦。

你好，什么写到数据库？网络通信与数据库有关系？。。。。。。[/quote]

引用 19 楼 dwyaneyywade 的回复:

我是客户端只每秒发数据，而不用接收数据

你的客户端只是发送一下数据， 又不需要接收， 为什么不能直接写入到服务器的数据库？[/quote] 服务器软件接收到数据后就是要把客户端发来的数据进行整理、转化后给存入到服务器的数据库里，但客户端总要先与服务器软件进行网络通信吧。。。。。。我是需要通过服务器软件对这些数据进行二次加工再写到数据库的

[大葡萄八块一斤]

引用 39 楼 dwyaneyywade 的回复:

[quote=引用 38 楼 yenange 的回复:] [quote=引用 37 楼 dwyaneyywade 的回复:] [quote=引用 36 楼 yenange 的回复:] 写到数据库不就得了， 不需要搞这么麻烦。

你好，什么写到数据库？网络通信与数据库有关系？。。。。。。[/quote]

引用 19 楼 dwyaneyywade 的回复:

我是客户端只每秒发数据，而不用接收数据

你的客户端只是发送一下数据， 又不需要接收， 为什么不能直接写入到服务器的数据库？[/quote] 服务器软件接收到数据后就是要把客户端发来的数据进行整理、转化后给存入到服务器的数据库里，但客户端总要先与服务器软件进行网络通信吧。。。。。。我是需要通过服务器软件对这些数据进行二次加工再写到数据库的[/quote] 直接用WebService，WCF，WebAPI都可以啊，客户端有新数据你就去调用接口就好了

[angel6709]

引用 34 楼 sp1234 的回复:

[quote=引用 32 楼 angel6709 的回复:] [quote=引用 21 楼 sp1234 的回复:] [quote=引用 9 楼 angel6709 的回复:] 短连接能满足需求吗

短连接最突出的，是每一次都重新握手连接，而且不能做到主动双向通讯（服务器端主动 push）。 如果一个人他一开始了解通讯，肯定是“一发一收，然后就断掉”的短连接方式觉得最简单。但是长连接不但从效率，还是双向主动发送信息方面，都有着巨大优势。这就好像是一个传统网页程序跟微信的区别，微信是可以从服务器主动push信息的，而且大量信息也不卡，不是传统的简单查询网页。这就可以看出习惯于长连接跟习惯于短连接的用户，操作体验根本不同。[/quote] 其实短连接也是相对的，如果你频繁请求（1s一次）而session timeout 设置为1.5s，则等价于长连接。[/quote] 其实我说的也比较明白了，那么就再重复一下。短连接的突出点，其一就在于平凡地“三次握手”。假设一个客户端在某个时候，1分钟内要发送2000个消息，没一个消息平均只有50个字符，那么这2000次握手要花费多大代价呢？！ 另一个突出点，就是不能支持服务器端主动 push。这在一些需求中，是技术“分水岭”。一个只能不断手动查询的程序，跟一个能够及时提醒前端的程序，用户体验和创意差太多了！！！[/quote] 1. 楼主的需求就是只有client push 2.http 可以实现长连接，通过设置timeout，timeout后断开连接，time没out 不断开连接，即长连接。这时候，不会有建立连接的握手。 3.服务器push client 的需求可以使用异步延迟回调实现 4.https比较安全 5.http方便负载均衡 6.tcp很灵活

[angel6709]

引用 40 楼 chb345536638 的回复:

[quote=引用 39 楼 dwyaneyywade 的回复:] [quote=引用 38 楼 yenange 的回复:] [quote=引用 37 楼 dwyaneyywade 的回复:] [quote=引用 36 楼 yenange 的回复:] 写到数据库不就得了， 不需要搞这么麻烦。

你好，什么写到数据库？网络通信与数据库有关系？。。。。。。[/quote]

引用 19 楼 dwyaneyywade 的回复:

我是客户端只每秒发数据，而不用接收数据

你的客户端只是发送一下数据， 又不需要接收， 为什么不能直接写入到服务器的数据库？[/quote] 服务器软件接收到数据后就是要把客户端发来的数据进行整理、转化后给存入到服务器的数据库里，但客户端总要先与服务器软件进行网络通信吧。。。。。。我是需要通过服务器软件对这些数据进行二次加工再写到数据库的[/quote] 直接用WebService，WCF，WebAPI都可以啊，客户端有新数据你就去调用接口就好了[/quote] 对，可以直接RPC

[DwyaneCV]

引用 40 楼 chb345536638 的回复:

[quote=引用 39 楼 dwyaneyywade 的回复:] [quote=引用 38 楼 yenange 的回复:] [quote=引用 37 楼 dwyaneyywade 的回复:] [quote=引用 36 楼 yenange 的回复:] 写到数据库不就得了， 不需要搞这么麻烦。

你好，什么写到数据库？网络通信与数据库有关系？。。。。。。[/quote]

引用 19 楼 dwyaneyywade 的回复:

我是客户端只每秒发数据，而不用接收数据

你的客户端只是发送一下数据， 又不需要接收， 为什么不能直接写入到服务器的数据库？[/quote] 服务器软件接收到数据后就是要把客户端发来的数据进行整理、转化后给存入到服务器的数据库里，但客户端总要先与服务器软件进行网络通信吧。。。。。。我是需要通过服务器软件对这些数据进行二次加工再写到数据库的[/quote] 直接用WebService，WCF，WebAPI都可以啊，客户端有新数据你就去调用接口就好了[/quote] 完成端口的方法解决高并发的网络通信问题最佳。

[DwyaneCV]

引用 41 楼 angel6709 的回复:

[quote=引用 34 楼 sp1234 的回复:] [quote=引用 32 楼 angel6709 的回复:] [quote=引用 21 楼 sp1234 的回复:] [quote=引用 9 楼 angel6709 的回复:] 短连接能满足需求吗

短连接最突出的，是每一次都重新握手连接，而且不能做到主动双向通讯（服务器端主动 push）。 如果一个人他一开始了解通讯，肯定是“一发一收，然后就断掉”的短连接方式觉得最简单。但是长连接不但从效率，还是双向主动发送信息方面，都有着巨大优势。这就好像是一个传统网页程序跟微信的区别，微信是可以从服务器主动push信息的，而且大量信息也不卡，不是传统的简单查询网页。这就可以看出习惯于长连接跟习惯于短连接的用户，操作体验根本不同。[/quote] 其实短连接也是相对的，如果你频繁请求（1s一次）而session timeout 设置为1.5s，则等价于长连接。[/quote] 其实我说的也比较明白了，那么就再重复一下。短连接的突出点，其一就在于平凡地“三次握手”。假设一个客户端在某个时候，1分钟内要发送2000个消息，没一个消息平均只有50个字符，那么这2000次握手要花费多大代价呢？！ 另一个突出点，就是不能支持服务器端主动 push。这在一些需求中，是技术“分水岭”。一个只能不断手动查询的程序，跟一个能够及时提醒前端的程序，用户体验和创意差太多了！！！[/quote] 1. 楼主的需求就是只有client push 2.http 可以实现长连接，通过设置timeout，timeout后断开连接，time没out 不断开连接，即长连接。这时候，不会有建立连接的握手。 3.服务器push client 的需求可以使用异步延迟回调实现 4.https比较安全 5.http方便负载均衡 6.tcp很灵活 [/quote] 完成端口的方法实现高并发的网络通信最佳

[DwyaneCV]

感谢各位的交流与指导，思路已经清晰，采用完成端口的思想，解决高并发的问题