问题描述:一个服务端,一个客户端。客户端往服务端传文件,具体细节不说了,客户端发给服务端的是文件处理后的定长数据报文(由数据报文头和数据报文体组成,其中报文头里约定了客户端发送多少个定长报文后,服务端要往回发一个确认包,然后客户端才继续发送定长报文)。服务端每接收一个数据报文先对其处理(拆包,写入文件等),然后接收下一包,如果到了约定发送确认包的数量时发送一个确认包给客户端。问题:在传小文件的时候没问题,但是在文件稍大一些的时候(4-10M)就出问题。我现在发送的报文是两包一个确认,问题出现在服务器接收每批第2包的时候,收不到数据,但是客户端那边显示已经发送,正等待确认,所以陷入了阻塞。但是这个问题不是一直出现,每次出现也不是在固定的位置。不知问题出现在哪儿?
抓包工具抓出来了截图:怎么贴图?

解决方案 »

  1.   

    1. 你的设计没有引入超时或heartbeat机制,肯定会有问题的。
    2. 多线程socket通信是比较麻烦,你使用调试工具看看线程是否是suspend了。那个抓包我实在是看不明白。
      

  2.   

    有超时的,在建立socket连接的时候,我就使用SetTimeOut设置了超时,在阻塞后,超过超时时间连接就会端口,我的传输也就失败了。第2个原因应该也不是问题。
      

  3.   

    应该是你发送后没有flush,所以最后的数据可能被缓存了
      

  4.   

    有flush。今天终于找到问题所在了,因为我在每次接收一包数据的时候都是new一个DataInputStream,服务器发送的快的时候可能在我new一个输入流之前已经发了数据,而我还没有得到输入流,这样就造成了丢包现象。
    我在服务器端发送的时候加一个延时,出错的概率就会减少。但在我们不能控制服务端的时候这个方式就不好了。
    所以最好的解决办法就是我们在建立Socket连接的时候,就取得输入、输出流。在以后每次收发数据的时候就一直用这个输入输出流,这样在批次确认的数据传输中就不会有丢包了。
    具体为什么我new一个数据流的时候包就丢失了,我还不很清楚,socket内部机制不很了解,有知道的也可以说一下。