使用TCPIP_TCP_FifoSizeAdjust动态无法接收远程RST

你试图做的事情永远不会起作用。例如：TCPIpHIPTCPSTRIGPUTE（）和THCTCPIPTCPUFIFOSIZEXECUTE（），你把一些数据放在TX缓冲器中（它没有机会被传送——这个调用不是阻塞），并且你立即用TX缓冲区，缩小它。数据将被损坏。不清楚将在该缓冲区中留下什么。当两方之间没有活跃的通信量时，这些功能可以使用。否则，您会混淆TCP算法，并且中断先前被确认的数据。等等。我可以深入挖掘它，BA。在您的示例中，我们看到了什么是完全被破坏的，但是这不是一个有效的使用。我只会在没有挂起的数据的情况下使用这个函数，否则通信会中断。在不同的注释上，TCP将用大的缓冲器正确地和有效地工作，至少1KB IF。你想看到它的任何性能（大部分的堆栈甚至不允许用户弄乱缓冲区大小，但他们管理它，因为他们认为合适。并且缓冲器从至少KB开始，至少）Tx和Rx缓冲器＝25字节。这是一个小规模而不是真实的生活场景。我可能会强制执行至少256个字节，这也是非常小的。



      以下为原文

    What you're trying to do will never work.
For example:
TCPIP_TCP_StringPut() and then
TCPIP_TCP_FifoSizeAdjust()
You put some data in the TX buffer (which doesn't get a chance to be transmitted - this call is NOT blocking), and immediately you mess with that TX buffer, shrinking it. The data will get corrupted.
Not clear what will be left in that buffer.
These functions can be used when there is no active traffic being exchanged between the two parties.
Otherwise you mess with the TCP algorithm and you break data that's previously been acknowledged, etc.
I can dig more into it, based on your example, to see what exactly gets broken in there, but this is not a valid use.
I'll make a note to use this function only when there is no pending data, otherwise the communication will break.
 
On a different note, TCP will work properly and efficiently with large buffers, at least 1KB if you want to see any performance out of it (most of the stacks don't even allow the user to mess with the buffers size but they manage it as they see fit. And the buffers start  at few KB, at least).
TX and RX buffers == 25 bytes?
This is way undersized and not a real life scenario.
I'll probably enforce to be at least 256 bytes, which is also very small.
 

嗨，雷诺德，谢谢你的回复。道歉。。。在我匆忙地展示一个简单的例子时，我忽略了一些重要的细节。实际上，我在TCPIPpTCPUSTRIGPUTE（）之后调用TCPIPUTCPUFLUHE（）。但是，您的观点仍然是有效的，因为在调用TCPIPpTCPIFIFOSIZEXECUTE（）之前没有调用TCPIPHSTACKYTASK（）。所以，好点，谢谢你…我会做这个调整，看看这是否可行。但是，我确实质疑你所说的……我认为可能，这是不正确的，基于可用的选项。TCPIPPUTCPUFIFOSIZEXECUTE（）的第四个参数是VFLAGS，其中2个可用的标志是TCPYTracePrimeFieldE.RX和TCPYActudioFraveV.TX。在一种情况下，我成功地使用了这一点来动态地扩展RX FIFO来调整以更有效地接收大请求。实际上，如果一个人为许多远程连接服务，并试图有效地使用RAM，这可能是一种真实的生活场景。如果期望接收小TCP消息并发送小响应，就没有理由拥有1K FIFO（甚至256）。



      以下为原文

    Hi rainad, thanks for the reply.   Apologies... in my haste to show a simple example, I left out important details.  Actually, I call TCPIP_TCP_Flush() after TCPIP_TCP_StringPut().  However, your point is nevertheless valid because TCPIP_STACK_Task() does not get called before the call to TCPIP_TCP_FifoSizeAdjust().  So, good point, thank you... I will make this adjustment and see if this works.
 
However, I do question something you said...

I think possibly, that is not true, based on available options.  The 4th parameter to TCPIP_TCP_FifoSizeAdjust() is vFlags, and 2 of the available flags are TCP_ADJUST_PRESERVE_RX and TCP_ADJUST_PRESERVE_TX.   I have successfully used this in one case to expand the RX FIFO dynamically to adjust for more efficient receipt of a large request. 



Well, actually it could be a real life scenario if one is servicing many remote connections, and trying to efficiently use RAM.  There is no reason to have a 1k FIFO (or even 256) if one is expecting to receive small TCP messages and transmit small responses. 

-是的，如果使用保留缓冲区选项，或者扩展了缓冲区，那么一切都可以。问题在于，当缓冲区中包含了尚未被套接字用户发送或接收的数据时，需要小心。从一开始就选择合适的缓冲区，而不是这样做可能更好/更安全：它仍然是一个昂贵的操作，可能会导致内存分配和拷贝等。如果你真的知道所有的消息都很小，那么它可能是有意义的。但是不要指望那个套接字的性能会很慢。



      以下为原文

    - Yes, if the preserve buffers option is used, or the buffers are expanded, then everything should be OK. The problem is with shrinking the buffers when they contain data that hasn't been transmitted yet or received by the socket user.
So, you need to be careful. And probably better/safer to select the proper size of the buffers from the beginning rather than doing this: it is still an expensive operation, may result in memory allocations and copy, etc.
 
- If you really know that all the messages are really small, then probably it makes sense. But don't expect any performance from that socket, it will be really slow.