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

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

2.这1000个客户端软件都是分布在全国各地的远程设备上的软件,都需要向我的服务器软件进行数据传输,我知道要定好协议,关键是会不会出现数据交叉的情况,比如:1号机数据发到1/3,突然由于网络问题停了一会儿,而此时2号机恰巧后2/3的数据来了,然后这两条断续信息组合起来成了完整的信息,会不会有这种情况?如何避免?(偶尔还好可以通过协议滤除,总是这样就头疼了,当然一个客户端一个线程的话是不会出现这种情况)
...全文
895 46 打赏 收藏 举报
写回复
46 条回复
切换为时间正序
当前发帖距今超过3年,不再开放新的回复
发表回复
DwyaneCV 2017-04-21
感谢各位的交流与指导,思路已经清晰,采用完成端口的思想,解决高并发的问题
  • 打赏
  • 举报
回复
DwyaneCV 2017-04-21
引用 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 2017-04-21
引用 40 楼 chb345536638 的回复:
[quote=引用 39 楼 dwyaneyywade 的回复:] [quote=引用 38 楼 yenange 的回复:] [quote=引用 37 楼 dwyaneyywade 的回复:] [quote=引用 36 楼 yenange 的回复:] 写到数据库不就得了, 不需要搞这么麻烦。
你好,什么写到数据库?网络通信与数据库有关系?。。。。。。[/quote]
引用 19 楼 dwyaneyywade 的回复:
我是客户端只每秒发数据,而不用接收数据
你的客户端只是发送一下数据, 又不需要接收, 为什么不能直接写入到服务器的数据库?[/quote] 服务器软件接收到数据后就是要把客户端发来的数据进行整理、转化后给存入到服务器的数据库里,但客户端总要先与服务器软件进行网络通信吧。。。。。。我是需要通过服务器软件对这些数据进行二次加工再写到数据库的[/quote] 直接用WebService,WCF,WebAPI都可以啊,客户端有新数据你就去调用接口就好了[/quote] 完成端口的方法解决高并发的网络通信问题最佳。
  • 打赏
  • 举报
回复
angel6709 2017-04-21
引用 40 楼 chb345536638 的回复:
[quote=引用 39 楼 dwyaneyywade 的回复:] [quote=引用 38 楼 yenange 的回复:] [quote=引用 37 楼 dwyaneyywade 的回复:] [quote=引用 36 楼 yenange 的回复:] 写到数据库不就得了, 不需要搞这么麻烦。
你好,什么写到数据库?网络通信与数据库有关系?。。。。。。[/quote]
引用 19 楼 dwyaneyywade 的回复:
我是客户端只每秒发数据,而不用接收数据
你的客户端只是发送一下数据, 又不需要接收, 为什么不能直接写入到服务器的数据库?[/quote] 服务器软件接收到数据后就是要把客户端发来的数据进行整理、转化后给存入到服务器的数据库里,但客户端总要先与服务器软件进行网络通信吧。。。。。。我是需要通过服务器软件对这些数据进行二次加工再写到数据库的[/quote] 直接用WebService,WCF,WebAPI都可以啊,客户端有新数据你就去调用接口就好了[/quote] 对,可以直接RPC
  • 打赏
  • 举报
回复
angel6709 2017-04-21
引用 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很灵活
  • 打赏
  • 举报
回复
引用 39 楼 dwyaneyywade 的回复:
[quote=引用 38 楼 yenange 的回复:] [quote=引用 37 楼 dwyaneyywade 的回复:] [quote=引用 36 楼 yenange 的回复:] 写到数据库不就得了, 不需要搞这么麻烦。
你好,什么写到数据库?网络通信与数据库有关系?。。。。。。[/quote]
引用 19 楼 dwyaneyywade 的回复:
我是客户端只每秒发数据,而不用接收数据
你的客户端只是发送一下数据, 又不需要接收, 为什么不能直接写入到服务器的数据库?[/quote] 服务器软件接收到数据后就是要把客户端发来的数据进行整理、转化后给存入到服务器的数据库里,但客户端总要先与服务器软件进行网络通信吧。。。。。。我是需要通过服务器软件对这些数据进行二次加工再写到数据库的[/quote] 直接用WebService,WCF,WebAPI都可以啊,客户端有新数据你就去调用接口就好了
  • 打赏
  • 举报
回复
DwyaneCV 2017-04-21
引用 38 楼 yenange 的回复:
[quote=引用 37 楼 dwyaneyywade 的回复:] [quote=引用 36 楼 yenange 的回复:] 写到数据库不就得了, 不需要搞这么麻烦。
你好,什么写到数据库?网络通信与数据库有关系?。。。。。。[/quote]
引用 19 楼 dwyaneyywade 的回复:
我是客户端只每秒发数据,而不用接收数据
你的客户端只是发送一下数据, 又不需要接收, 为什么不能直接写入到服务器的数据库?[/quote] 服务器软件接收到数据后就是要把客户端发来的数据进行整理、转化后给存入到服务器的数据库里,但客户端总要先与服务器软件进行网络通信吧。。。。。。我是需要通过服务器软件对这些数据进行二次加工再写到数据库的
  • 打赏
  • 举报
回复
吉普赛的歌 2017-04-21
引用 37 楼 dwyaneyywade 的回复:
[quote=引用 36 楼 yenange 的回复:] 写到数据库不就得了, 不需要搞这么麻烦。
你好,什么写到数据库?网络通信与数据库有关系?。。。。。。[/quote]
引用 19 楼 dwyaneyywade 的回复:
我是客户端只每秒发数据,而不用接收数据
你的客户端只是发送一下数据, 又不需要接收, 为什么不能直接写入到服务器的数据库?
  • 打赏
  • 举报
回复
DwyaneCV 2017-04-21
引用 36 楼 yenange 的回复:
写到数据库不就得了, 不需要搞这么麻烦。
你好,什么写到数据库?网络通信与数据库有关系?。。。。。。
  • 打赏
  • 举报
回复
吉普赛的歌 2017-04-21
写到数据库不就得了, 不需要搞这么麻烦。
  • 打赏
  • 举报
回复
ServerSuperIO、SuperSocket、netcomm都可以试试。
  • 打赏
  • 举报
回复
用完成端口吧
  • 打赏
  • 举报
回复
DwyaneCV 2017-04-20
引用 14 楼 angel6709 的回复:
[quote=引用 12 楼 dwyaneyywade 的回复:] [quote=引用 9 楼 angel6709 的回复:] 短连接能满足需求吗
何为短连接[/quote] Http 等,用完就断开连接,等需要时在连接。[/quote] 我是客户端只每秒发数据,而不用接收数据,您的意思是我所有的客户端每次faw
引用 18 楼 angel6709 的回复:
1000个设备总是在线?
1000个是基础数量了,可能更多,当然就像之前有人说的,更多的话就要考虑负载均衡了,每台每秒几百字节的数据量吧,每台远程设备每秒上传一次数据
  • 打赏
  • 举报
回复
angel6709 2017-04-20
1000个设备总是在线?
  • 打赏
  • 举报
回复
angel6709 2017-04-20
通讯数据量多大?
  • 打赏
  • 举报
回复
angel6709 2017-04-20
你的需求是每秒钟post一次?
  • 打赏
  • 举报
回复
DwyaneCV 2017-04-20
感谢各位的回复,异步通信是可以高并发的问题,但是实时性如何保证?我做了个实验,一个服务器软件同时与50个客户端进行网络通信,客户端每秒发送数据给服务器软件,然后服务器软件界面上放了50个文本框用于实时显示各客户端来的数据,以1/0显示间断显示,发现每个文本框1/0变化不实时,甚至有的十几秒才变化一次,如何实现这50个文本框可以实时每秒变化一次?
  • 打赏
  • 举报
回复
angel6709 2017-04-20
引用 12 楼 dwyaneyywade 的回复:
[quote=引用 9 楼 angel6709 的回复:] 短连接能满足需求吗
何为短连接[/quote] Http 等,用完就断开连接,等需要时在连接。
  • 打赏
  • 举报
回复
DwyaneCV 2017-04-20
引用 6 楼 qq_34266409 的回复:
我先不讨论你设计思路有什么问题,我说下如果是我我会怎么做 你这需求我一看就想起直播间,直播间是双向通信,你这个是一个服务器和1000个客户端通信, 1.这么多客户端我肯定是用线程持的,新开线程开销太大了 2.我不会一直链接这些客户端,只会在需要的时候再去连, 3当客户端要连你的时候它请求过来我再去和它建立链接,我的最大同时连接数可能只有10个,如果一次来的太多我会将它们放入MQ中一个个来处理,因为1000个客户端不可能每个都一直在发消息, 4所以我会和联系比较频繁的一直保持链接,如果一个链接很久没有消息了我会把它释放掉。具体模式你可以参考QQ的通信, 5如果客户端交流非常密切,而且客户端非常交流量很大,我会采用随机把队列中的踢出去的方式来进行通信
这1000个客户端一旦运行,就是每秒定时上发数据的,而且数据量大概是几百个字节,您的意见很具有参考性,谢谢
  • 打赏
  • 举报
回复
DwyaneCV 2017-04-20
引用 9 楼 angel6709 的回复:
短连接能满足需求吗
何为短连接
  • 打赏
  • 举报
回复
加载更多回复
相关推荐
发帖
C#
加入

10.7w+

社区成员

.NET技术 C#
申请成为版主
帖子事件
创建了帖子
2017-04-20 10:07
社区公告

让您成为最强悍的C#开发者