Himself wrote a simple file transfer procedures, the service side multi-threaded transfer files, the client threads receives the file and also when the machine test no problem, but when I test in the wireless local area network (LAN), send the file lost when I was a lot of information, of course, if the client recv by packet send a frame similar to confirm back, then the server after receiving the confirmation frame to send again the next packet was no problem, but such transfer files for long time a lot of, don't know is what reason, I remember the default send is not synchronized, why such a problem,

The development environment is Windows 10

CodePudding user response:

Send just send to send a cache, is not really send to each other,

CodePudding user response:

Presence of bosses to answer

CodePudding user response:

reference 1/f, Simple, Soft reply:

send just send to send a cache, is not really send to each other,

Do you think the meeting is what problem, it is received at the receiving end so poor

CodePudding user response:

Are you a TCP or UDP?

CodePudding user response:

TCP

CodePudding user response:

You didn't confirm the return value,
The send to determine how many bytes successfully sent in the past,
Recv to determine how many bytes, successfully received
Before sending the actual file data sending file size in the past

CodePudding user response:

refer to 6th floor smwhotjay response:

You didn't confirm the return value,
The send to determine how many bytes successfully sent in the past,
Recv to determine how many bytes, successfully received
Before sending the actual file data sending file size over the past

Mean I in the application layer protocol design less

CodePudding user response:

refer to 6th floor smwhotjay response:

You didn't confirm the return value,
The send to determine how many bytes successfully sent in the past,
Recv to determine how many bytes, successfully received
Before sending the actual file data sending file size over the past

Confirm the return value can solve a problem

CodePudding user response:

refer to 4th floor, Simple, Soft reply:

are you a TCP or UDP?

TCP send and receive the basic idea is each send package is contained inside their own baotou, baotou contains data length, data types, such as the receiver receive each time, are receiving baotou first, then according to the actual baotou to receive the data length, requires one to one correspondence

CodePudding user response:

I program logic is a little problem, now send not lost package, just transport slow, I will try to expand the buffer

CodePudding user response:

references 9/f, Simple, Soft reply:

Quote: refer to 4th floor, Simple, Soft reply:

are you a TCP or UDP?

TCP send and receive the basic idea is each send package is contained inside their own baotou, baotou contains data length, data types, such as the receiver receive each time, are receiving baotou first, then according to the actual baotou to receive the data length, requires one to one correspondence

Logic is a little problem at the receiving end, verified the length is no problem after receive a