文件传送的困惑

我用winsock控件分割发送图片，用单步调试得到的文件比原文件多两个字节，直接运行却少了最后小于8192K的一段字节。我已经用了延时了，怎么搞的？困扰了两个晚上了，我用手机上的，不好贴代码

解决方案 »

  1.   

    这个得看代码了。UDP、TCP，还有你是怎么读取，怎么传输，怎么接收的。找一个抓包工具，至少可以确认问题出现在发送以前还是接收以后。
    然后再调试下。
    如果有数据读取编码，一开始可以用测试数据单独调试，等搞完了再放到网络环境下。
      

  2.   

    我用的TCP协议，二进制打开文件，用GET读取，PUT写入，我用MSGBOX得到的信息显示我都已经接收到，单步调试文件大小正长，直接执行却少了最后一段小于字节
      

  3.   

    尝试做了一个利用WINSOCK控件的自动分包发送机制的东东(VB6.0)应该有参考价值吧.
      

  4.   

    不要用任何doevents，sleep之类的延时代码。如果了解透彻的，一样很完美。我觉得还是你接收方面的问题。
      

  5.   

    a)读取二进制文件用的数组长度定义不正确。
    b)8k 是发送时的自动分包，剩余的数据在下一个包中。
      

  6.   

    你怎样定义数组？
    redim a(100) as byte
    '默认情况是 101 个成员，等同于
    redim a(0 to 100) as byte'用长度定义数组时通常要减1
    redim a(lLength-1) as byte
      

  7.   

    我是用的PUT函数将二进制数组写入文件，每次写入后，第二个参数i加1024*8，最后得到的文件大小与原来的图片一样大，就是无效。
      

  8.   

    接收方不能期望接收的次数和发送方发送的次数一样，因为TCP/IP是基于流而不是基于包的。
    所以最好发送方先发将要发送的字节数，再跟上要发送的数据
    接收方先收到将要接收的字节数，然后再将后续接收的数据缓存，直到收满所有数据或超时返回接收失败。
      

  9.   

    推荐用 Beyond Compare，二进制比较。
      

  10.   

    趁着手机有流量，终于把beyond compare下载下来了。比较后发现，图片小于8K时，两张图片完全一样，当大于8K时，传回的图片用十六进制打开发现全是0,总算找到问题了
      

  11.   

    现在已经确定发出的没有问题，并且接收到数组里的居然是空的（在传送大于8K的图片时），我先根据传送过来的大小判断是否大于8K,如果是则接收数据写入大小为8K的数组，并且长度减去8K,到小于8K时，重新定义数组大小，接收剩下的数据并写入文件，想不通TCP为何是空的