In the past few days, we have re-installed diocp3, and the basic work has been initially completed. In the testing phase, we joined the queue for delivery today. This is a very simple job. I did not pay attention to it and left two traps, after 7 to 8 hours, I found the problem and recorded it,
About the queuing delivery process
This is the process of delivering a tiocpsendrequest. The delivery starts and delivers a piece of data, up to 50 k. If it exceeds 50 K, it will be delivered in batches. The process is correct. My first statement is:
Innerpostrequest ships the sent data to the iocp queue. After the shipping is completed, the memory block postion is added to facilitate the next delivery. It seems that there is no problem. If the network condition is quite good, especially on the local machine, the other thread completes the event immediately after delivery <when the fposition is determined in the content, it is still accumulated, the cup is generated a little bit>. Now that you know the cause, you can solve the problem.
Modify. postion increases will not be processed here and will be processed in handleresponse.
After the data is sent, add fpostion and determine whether there is any remaining data to be sent. Finally, we have completed this trap.
Another sentence: "Concurrent Design: never suppose that any code will be executed continuously"