A little bit of thinking about socket programming

There are several problems:

1. Why does htons need to be used to convert the byte order during bind, but does not need to be converted when the send function sends data in the future?

After thinking about it, I thought: when starting bind, the port number and IP parameters are all in the form of integers in bind operations. However, when sending data, the parameters for sending and receiving are both (const) char FAR * buf
,

This means that the sent and received data is no longer in the form of integers, but in the form of strings. However, large and small ends are the same when storing strings, in this way, conversion is not required,

Different machines can also be correctly identified. (For strings on the network, character arrays are transmitted in no network byte order. Others' Statement)

Ii. After successful connection, the recv/recvfrom function is used to receive data. What is the memory?

The code for receiving data twice by a TCP socket sockConn that has obtained a connection is as follows:

Char buf1 [16];
Recv (sockConn, buf1, 16, 0 );
MessageBox (buf1 );

Char buf2 [16];
Recv (sockConn, buf2, 16, 0 );
MessageBox (buf2 );
The code for sending data twice by another TCP socketsockClient connected to sockConn is as follows:
Send (sockClient, "sendmessage1", strlen ("sendmessage1") +); // contains the string Terminator, sent in 13 bytes.
Send (sockClient, "sendmessage2", strlen ("sendmessage2"), 0); // It does not contain the string Terminator. A total of 12 bytes are sent.
The first messageBox (buf1) of sockConn; the result is sendmessage1, and the second MessageBox (buf2); the result is sendmessage2 burning sendmessage1. At this time, I can estimate the memory situation as shown in:
That is to say, the buf2 memory space is just in front of the buf1 of the previous receiving data container. I guess this is the meaning of the so-called TCP Data Stream. the received data will be connected together and streamed. When MessageBox (buf2) is used to output buf2, it is always output until the 13th-byte Terminator/0 of the subsequent buf1 is met, so the above output result is displayed.
Check back the statement that sockConn receives data for the second time. recv (sockConn, buf2, 16, 0); parameter 16 controls the number of bytes of received data. In fact, this parameter is not necessarily the size of the buf, it can take any integer greater than 0. If I change the statement sent by sockClient for the second time:
Send (sockClient, "sendmessage2ABCDEF", strlen ("sendmessage2ABCDEF"), 0); // The string Terminator is not included, and a total of 18 bytes are sent.
The result of MessageBox (buf2) is sendmessage2ABCDsendmessage1, because recv (sockConn, buf2, 16, 0); parameter 16 specifies that only 16 bytes of data can be received, therefore, the data "EF" is discarded. If you change recv (sockConn, buf2, 16, 0) to recv (sockConn, buf2, 18, 0); which MessageBox (buf2); the result is sendmessage2ABCDEFndmessage1, because buf2 only has 16 bytes, the received 17th and 18 bytes "EF" will continue to be written into the memory at the end of buf2, so I changed the "se" of buf1 to "EF. If it is changed to recv (sockConn, buf2, 20, 0); where is MessageBox (buf2); the result is sendmessage2ABCDEFndmessage1, and the data "nd" in the third and fourth bytes of buf1 will not be rewritten, because the space is not available for the received data.
Simply put, the third parameter of the recv function is like a gate. When the received data is written into the memory, it is prohibited to cross the gate. If the memory before the gate is insufficient to write all received data, discard the data that cannot be written later. If the memory before the gate causes extra data after all received data is written, the excess memory will retain the original value and will not be rewritten.
You can even change it to recv (sockConn, buf2,); buf1 and buf2 are only 32 bytes in total, and I changed the third parameter of recv to 40, if the sockClient sends 50 bytes, the content of the first 40 bytes can be successfully written into the memory. It should be noted that the new 8-byte memory space after buf1 is opened only when buf2 + buf1 is insufficient for memory to write data, for example, if the sockClient sends only 30 bytes, buf1 will not open up any memory space. If sockClient only sends 37 bytes, buf1 will only open up 5 bytes of memory instead of 8 bytes of memory.