关于TCP协议传输效率的问题

tcp

解决方案 »

  1.   

    udp协议就可以了。如果对有些包被扔掉无所谓的话。但是能做更有效的实时。
      

  2.   

    一般的网卡都百兆千兆了，连600KB/S的速度都达不到只能是设计有问题。
      

  3.   

    如果是在局域网就问题不大了，主要看10毫秒能不能把工作做好
    但如果是广域网的话就麻烦点，现在的宽带上传速度除了商业外不可能达到 600kb/s 的速度，最多就只有64~128kb/s
      

  4.   

    看设备网卡驱动性能是否能高速工作，如果可以起码10M肯定满足要求。
    界面上刷新就不要那么快了，半秒或者1秒刷新一次就好了，看不了那么快。
    如果10ms刷新一次，界面会很花的。而且可能会卡。
      

  5.   

    这个数量级别的通讯，局域网没有问题；
    上公网需要测试实际效果。
    如果Server侧除了UI显示，还需要后台运算或者入库操作，
    系统瓶颈是Server侧的业务处理而不是网络通讯；
    如果只是显示，同意楼上说的，可以考虑丢失部分数据，
    UI到秒级刷新一般应用足够了
      

  6.   

    数据能不能实时发送到服务器是靠你的带宽来保证的，600KB/S我感觉如果是局域网一般没有问题；如果是广域网就不好说了，你得考虑网速的因素，我感觉你的程序应该能分别适应于高带宽和底带宽，在服务器端做个队列吧，先把客户端发送的数据存在队列中，之后在服务器端单独开一个线程来处理数据，如果队列中有数据就按你之前的逻辑处理，如果队列中数据不够上层使用了，就加一些特殊处理。
      

  7.   

    select IO 绝对没问题，我做过类似的东西。
      

  8.   

    感谢大家的指导。上次我用相同的方案完成了一个项目，只不过数据只有30KB/S，和这次的要求差了20倍，因此对于传输问题心里没底，担心设计方案最后会碰上难以逾越的障碍，致使进度拖延。关于需求，再进一步解释一下，是在局域网中。客户端每10ms采集一列图像数据发给服务器(即6KB)，服务器接收后经过数据处理最后显示到UI上，每10ms一个轮回，直到停止采集。最终服务器所有列拼起来得到完整图像。传输中不能有数据丢弃。我之前也测试过，ui处理的确很占时间，但是服务器端的图像要随着采集进度实时显示，如果采用秒级刷新，会使得成像过程一股一股的出来，感觉不舒服。关于技术问题，仍有一点疑惑，同样大小的数据包，如果分100次发送，会不会比一次发送慢很多，会下降一个量级吗？
    btw，我准备采用SiGoYi的方案，将数据接收和数据处理分两个线程来做。感觉这样比较合理
      

  9.   

    需求还是没有解释清楚。你这样的客户端有多少？1个和100个所对应的数据量和业务量是不一样的。
    如果就仅仅几个这样的客户端，那么不建议你用任何高级网络模型，直接用多线程的方式来处理（一个socket连接一个线程的方式），响应会很快，处理起来也相对容易些。
    如果客户端很多，那么就需要使用网络网络模型，并且还需要结合缓冲队列来处理。
    同时，UI和业务处理分开是必须的。