Thank you Simon. This is a very helpful list! > -----Original Message----- > From: > [EMAIL PROTECTED] > u.org > [mailto:lwip-users-bounces+bruce.sutherland=rfinnovations.com. > [EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] > Sent: Thursday, 23 October 2008 12:41 PM > To: Mailing list for lwIP users > Subject: Re: [lwip-users] Throttling incoming TCP in receive > callback usingraw API > > Bruce Sutherland wrote: > > In our TCP receive callback, data is simply copied from the pbufs > > provided by lwip, into a serial ring buffer. As the serial port is > > much slower than the Ethernet port, we need a way to inform > lwip that > > we cannot receive more data when the serial buffer is full. > What is the mechanism to do this? > > Should I delay calling tcp_recved in the case that the serial ring > > buffer is too full? > That's exactly the way to do it. tcp_recved sends a window > update to the remote side while the ACK is sent by > stack-internal functions right after receiving. > > If so, when will my receive callback be called again? Is there some > > better way to achieve this? > > > The receive callback will be called again when new data > arrives, which can happen although you did not call > tcp_recved if the RX window is not yet full. If the window is > full, the client may send again after receiving a window > update from you. > > I'm guessing the ETH connection is much faster than the > serial connection? In that configuration, I think it will be > enough to call tcp_recved after having sent the data on the > serial line. That way, you only have to make sure that the > TCP RX window is bigger than (or equal > to) the serial buffer. > > Our current implementation appears below, which calls > tcp_recved for > > all data as it arrives, and just throws an assertion if the serial > > ring buffer is too full to fit the data. > > > > > That's not a good idea as this assertion can appear very > often if the TCP sender sends faster than the serial port can > handle it. > > > Simon > > > _______________________________________________ > lwip-users mailing list > [email protected] > http://lists.nongnu.org/mailman/listinfo/lwip-users >
_______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
