realdreamer(我是愤怒) 说的没错,应该是几个小包被组合成一个大包了.

解决方案 »

  1.   

    首先,包是连续的,而我每次收都是按包头的大小收的,所以即使是协议把包组合在一起发到Server端,Client收的时候也是拆开的啊,也不应该出现丢包的现象啊?????
      

  2.   

    //组合在一起??不是吧,因为我收的时候都是按每个包的大小收的啊
    每次都指定不同大小的缓冲区来接受? 反正只要累加每次返回的实际收到的字节数量就知道你到底收到了多少了TCP是建立了一个流,而流是没头没尾的。所以**划分**不同包时要小心。
      

  3.   

    recv收的时候可以指定收的字节数的啊.我的做法就是,每次先收下头四个字节转换成整型,然后在循环收完这个整数,则认为收到一完整的包.因为我的包的第二部分是记录包的个数的,我每次收总是发现这个数字不连续,总是丢掉一些.
      

  4.   

    如果你是用 WINDOWS 2000 , 可以用网络监视器监视本地的网络活动。看看是不是丢了。
      

  5.   

    如果Server和Client都在调试状态下则不会出现丢的现象,怎么解释啊!
      

  6.   

    realdreamer(我是愤怒),你好,我是封装在dll里面的,还没写出完,代码也比较多,如果可以的话把程序发给你帮我看看吧.谢谢,你的mail?
      

  7.   

    No way can TCP lose packets. There must be something wrong when you calculate bytes.//头四个字节转换成整型
     考虑网络字节顺序了吗?
      

  8.   

    这是可能的。我们在做一个系统时,也出现了这种情况。可能在数据中,有SOCKET的结束标识,它可能当作几次发送了。只好重新打包数据,循环读SOCKET,只认包的头和尾。
      

  9.   

    //可能在数据中,有SOCKET的结束标识,
    呵呵,TCP绝对不会丢中间部分的数据的,如果有问题,肯定是自己的问题。我只想到三种可能:
    每次实际读出的byte数,即函数的返回值
    网络自己顺序
    是不是用字符串处理函数了
      

  10.   

    //发送的时候可能并不按你在程序中所发送的顺序。除非你是试用多线程发送。否则TCP会保证数据会按顺序到达的。
      

  11.   

    你在协议里加上包得长度,最好有包头,然后再recv时严格按照先获得包头,在获得长度,然后按照长度获得相应的包提,依次类推,不会出现丢包的问题,当然,前提是你的网络很稳定。