Here are some of the problems with TCP and UDP that have been encountered in the actual background development, which are slowly accumulating:
UDP continuously sends 2 packets, the first 100 bytes, the second 200 bytes, the server recvfrom (1000) received 100, 200 or 300 bytes?
*: 100 bytes under normal conditions
*: Network chaos: It may receive 200 bytes if the packet is out of order due to network cause. It is possible to add a serial number identifier to the custom UDP protocol header
*:UDP is a data message protocol, each packet is independent, the client sendto how many UDP packets, the server will have to recvfrom how many times, the packet will not be merged
TCP Continuous SEND2 packets, the first 100 bytes, the second 200 bytes, the server recv (1000) received 100, 200 or 300 bytes?
*:TCP Sticky Pack: 300 bytes If both packets have arrived at Recv
*: If only 100 bytes of packets arrive when recv, then of course there are only 100 bytes.
*:TCP is a stream transport protocol, and the TCP/IP stack automatically merges TCP packets to ensure packet integrity. However, packages that are not relevant are also sticky, which requires the user process to handle
How to deal with TCP sticky packet phenomenon?
* A common approach is to use the TLV package format: That is, type, length, value, where type and length are fixed. If the type is 1 bytes and length is 4 bytes, then recv (5) receives 5 bytes, determines the packet type and gets the packet length len, then recv (LEN) receives the package body and resolves by type
[Go] Some summary of TCP and UDP usage issues