Uip1.0 active sending problem understanding

Recently LPC1768 Debugging uIP1.0 Network protocol code , The setting configures the mode of sending without subcontracting , The number of bytes originally intended to be sent and returned should not be too large , I have locally customized protocols . When debugging later , Find out TCP The agreement actually has the problem of sticking and unpacking

The problem of sticking bags is the most annoying , Originally, this light protocol stack has been out for many years , Now many people have found that they don't play this embedded thing , Looking for one uIP The protocol stack was not found , Finally, only the only slightly valuable article can be found on AMO Forum

Because it is used on the device side uIP Of TCP Server configuration , After the upper computer is connected to the device, it sends the specified protocol , But I found something on the device side TCP The server cannot actively send !!!! This is very annoying . Originally a duplex communication , Live into a single job

The problem is that

1. UI End send 14 Byte packet request to device , Device reply 56 byte , The equipment uIP The cache is 56*10 byte , That is, a single time uIP At most, I can only reply to 10 A frame . So if TCP Send sticky packets ,, Like, all of a sudden 20 individual 14 Byte request , Then the device will not respond at one time !!!!! The problem is coming , Need reply 20 When I get a bag uIP Not so much , You can only reply to 10 individual , So the rest 10 What can I do ???

2. The solution to the above problem is to do it on the device side ack Respond to , Reply first 10 A bag for UI,UI This time will reply to a ACK Give the equipment , Equipment received ACK Then process the remaining packages .

3. good , Follow the above ideas , Now there's another problem , Namely UI End send 14 Byte requests are a continuous process , Then it's possible UI First time received 10 When I get a bag , The second time is just about to be sent 14 byte , that TCP The agreement will put this ACK Flag Put it in 14 Bytes of TCP Send to the device together on the protocol ( In this way, the equipment cannot determine whether it is going to deal with ACK still newdata), Normally, it should be handled first ack My bag , Processing returned , To deal with newdata, This requires the device to store the received data as a cache ,. There is still a problem with sitting in a circular cache like this , Is that when UI After sending fast , The cache on the device side will still be full !

4. Suddenly thought of another idea

because uIP Now the default receive cache and send cache are the same memory , So let me make a distinction here , Receive cache settings 14*4 * 2 byte , The returned cache is set to 56*8 byte , In this case, can I guarantee that I can communicate symmetrically on the network ? Because the device's receive cache , Never more than 14*4 * 2 Byte receive , In this way, the returned value is 56*4*2 byte !!

Debug the code in the evening to test the idea ? Update later if feasible