【问题标题】:Android Socket TCP DatalossAndroid Socket TCP 数据丢失
【发布时间】:2020-03-17 17:19:20
【问题描述】:

我无法使用 WiFi-Direct 传输整个文件。文件发送者指示整个文件已被复制到套接字输出流。文件接收器只接收大约一半的文件。

我查看了原始文件的内容和存储接收数据的文件的内容,发现接收方只接收原始文件的片段。例如,它将接收字节 0-100,然后跳转到字节 245-350。

为什么接收方只接收文件的零碎部分,而不是整个文件?

文件接收逻辑

    private class FileReceiveThread(val channel: Channel) : TransmissionThread() {
        private var mFileName: String = ""
        private var mFileSize: Long = 0L
        private var mBytesReceivedTotal = 0L

        override fun run() {
            try {
                Timber.d("File receive thread running: fileSize=$mFileSize, fileName=$mFileName")
                val outputFile = File.createTempFile("file", "")
                val fileOutput = outputFile.outputStream()
                val channelInput = channel.getInputStream().unwrap()

                val inputBuffer = ByteArray(FILE_TX_BUFFER_SIZE)
                var bytesReceived = channelInput.read(inputBuffer)

                while (bytesReceived > 0) {
                    fileOutput.write(inputBuffer)
                    mBytesReceivedTotal += bytesReceived
                    Timber.d("Received $mBytesReceivedTotal total bytes")
                    bytesReceived = channelInput.read(inputBuffer)
                }

                onTransmitComplete?.invoke()
            } catch (e: Exception) {
                e.printStackTrace()
            }
        }

        fun start(filename: String, size: Long) {
            mFileName = filename
            mFileSize = size
            start()
        }
    }

文件发送逻辑

    private class FileSendThread : TransmissionThread() {
        var mFile: File? = null
        var mOutputStream: OutputStream? = null

        override fun run() {
            if (mFile != null && mOutputStream != null) {
                val inputStream = mFile!!.inputStream()
                val channelStream = mOutputStream!!
                val buffer = ByteArray(FILE_TX_BUFFER_SIZE)

                var bytesRead = inputStream.read(buffer)
                var totalBytesRead = 0L + bytesRead

                while (bytesRead > 0) {
                    Timber.v("Read $bytesRead, total $totalBytesRead")
                    channelStream.write(buffer)
                    bytesRead = inputStream.read(buffer)
                    totalBytesRead += bytesRead
                }

                Timber.d("Wrote file to output stream")

                inputStream.close()

                Timber.d("No more data to send")
                onTransmitComplete?.invoke()
            } else Timber.d("Parameters null: file=$mFile")
        }

        fun start(file: File, stream: OutputStream) {
            mFile = file
            mOutputStream = stream
            start()
        }
    }

【问题讨论】:

  • while (mBytesReceivedTotal < mFileSize) 正手的接收者如何知道文件的大小?很奇怪。
  • 缺少:fileOutput.close().
  • Timber.v("Bytes received total: $mBytesReceivedTotal") 那么它打印了什么?
  • mFileSize 在线程外接收,并传入。见 FileSendThread 底部。 fileOutput 已在其他地方关闭。至于接收到的字节记录,它只打印接收到的字节数。它始终是总文件大小的大约一半。表示接收方只接收到文件的一半。
  • mFileSize is received outside of the thread, 这并没有回答我的问题。重复:How would the receiver at forehand know the size of the file? .

标签: java android sockets tcp ftp


【解决方案1】:
           while (inputStream.read(buffer) > 0) {
                channelStream.write(buffer)
            }

read() 通常不会填满整个缓冲区。因此,如果你写缓冲区,那么只要它被填满。

           var totalbytesread = 0;
           var nread;
           while ((nread = inputStream.read(buffer)) > 0) {
                channelStream.write(buffer, 0, nread)
                totalbytesread += nread;
            }

           channelStream.close()';

记录读取的总字节数。 您的原始代码会导致接收到的文件更大,因此还有其他内容有待发现..

【讨论】:

  • 我没有收到更大的文件,我收到的是更小的文件。接收到的文件大约是正在发送的文件的一半。以下是接收日志:link。另外,这里是发送日志:link,注意:接收日志似乎被切断了,但实际上没有。
  • channelStream.write(buffer, 0, nread) 真的写nread' bytes? Isnt there a return value? int nwritten = channelStream.write(buffer, 0, nread)` 吗?他们应该是平等的。检查。
  • 之前检查过,没有!
  • 对不起,我不知道你的意思是不是。请准确。
  • write(b byte[]) 函数不返回写入的字节数。返回类型为void
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2012-07-15
  • 2015-01-05
  • 2023-03-11
  • 2014-03-22
  • 1970-01-01
  • 2014-05-05
  • 1970-01-01
相关资源
最近更新 更多