It's very different to see the code and write the code.

It's not hard to see the code, but it's not easy to write simple code from beginning to end.

Write a TCP server & client. It was changed from UDP, and it was a very old one.

The first listen error, the original Sock_dgram forget to change to Sock_stream,

Then found listen port is wrong, originally forgot Bind,

Later found that the client sends the data service side can not receive, and then look at the code, the original is no accept/connect.

Add accept and connect, the client prompt successfully, but the service side did not return, looked for a half-day, found that the client forgot to change the sock_dgram to Sock_stream.

It's too weak.

But finally changed, write this simple program, the purpose is to verify the following message sub-frame features:

Message Framing uses the message-framing mechanism to protect messages from the socket only within one boundary, which means that if the client sends 100 bytes to the server and then sends 50 bytes. Then the server reads 100 bytes and 50 bytes in two read operations respectively. This is also true for UDP, which is useful for message-oriented protocols. Unlike this, TCP is operated in a byte-stream manner. Without a framing mechanism, the data received at one end may be more or less than the data sent at the other end (this divides a write operation into multiple operations, or merges multiple writes into a single read operation). This behavior requires a message-oriented protocol that operates on top of TCP to provide data buffering and message framing mechanisms in the application layer (which can be a complex task).

It's very different to see the code and write the code.