I can't send and receive javatcp files well

Asked 2 years ago, Updated 2 years ago, 66 views

on the transmission side bis = new BufferedInputStream made out of data = 4096 while (len = bis.read(data)) != -1) dos.write(data, 0, len); I'm flying it like this

The len value goes to 4096 consistently when you send it

on the receiving end I read it as while((len = dis.read(data))!= -1) The file didn't come properly, so I set the len value It comes out like this;;; What's wrong? I should have received the len value of 4096 when I sent it for the second time, not even udp ;;; Text files of a few bytes are easily accepted.

/

I don't know if it's because I received it like this... I'm sending 132kb files Stop at count 27.

What should I do?

java tcp

2022-09-22 20:17

1 Answers

First of all, if you look at read(byte[]), you can see the following.

If the length of b is zero, then no bytes are read and 0 is returned; otherwise, there is an attempt to read at least one byte. 

Invoking read() ensures that at least one byte is read, but it does not state that the data from the transferred place can be read all at once. This means that even if the sender sends 4096 bytes and the receiver calls read(), you may not receive 4096 bytes at once.

Above all, TCP communications ensure that the order of transmission of the data and the integrity of the data are maintained, not that all data is sent at once.

The data you want to send is divided into segment in TCP and is transferred and stacked in the destination buffer. read() reads data piled up in this buffer, but if all the data sent from the other side is not stacked in the buffer, it will read only the accumulated portion and the rest will be read in the next read() call.

This means that even if you send 4096 bytes, it is fragmented and transmitted depending on the system situation/network situation/data size/MTU.

For this reason, you can see that the data is split and read, such as 1420 and 2676.

Therefore, you should not think that you will be able to receive the data sent to read() at once. If you plan to receive 132KB, please fill it out as below.

byte[] data = new byte[132 * 1024];

int len = 0;
do {
    int read = dis.read(data, len, data.length - len);
    if (read == -1)
           break;
    len += read;
} } while (len != data.length);

if (len != data.length)
    throw new RuntimeException("fails");

If the value of the data received is less than 132KB, I think a more detailed code will be needed. It's hard to judge based on the code you posted.

I tested the server with the same private ip under nat instead of the authorized server, and it suddenly works well;;;

Depending on whether the network is the same network or not, communication delays can occur that much. This may or may not have 4096 bytes of data in the buffer at the time of read().

In the same network, the delay is low, so there is a high probability of 4096 bytes at the time of read(), so it works well in the situation you mentioned, and the servers on the other network do not seem to work well because of the low probability.

공인서버쪽 문제인걸까요 아님 tcp도 패킷이 손실되나요??

TCP does many things to recover data loss during communication. If you cannot recover through this operation, an exception will occur in read().


2022-09-22 20:17

If you have any answers or tips


© 2024 OneMinuteCode. All rights reserved.