How is TCP flow control handled on XBee Cellular (API mode)?

Question

Does a xmit response indicate local packet send or remote ack?

Is there any way to affect TCP window size/buffering to avoid dropping incoming packets due to a slow, low-RAM host processor?

How much buffering can XBee do internally if serial port is paused with flow control? (However even this doesn't help on multiple simultaneous TCP connections).

Is incoming data ack'd immediately or does it wait until the packet is delivered out the serial port?

Answer 1

What do you mean by a xmit response? What is the frame you received?

No, you don't have that kind of control on the XBee Cellular module.

Data is ACK'ed as soon as it is received on the RF processor before it is sent out the UART.

Comments

TX Status 0x89.  "Indicates success or failure of a transmit operation".

If Data is ACK'ed immediately how does one avoid dropping data due to a relatively slow UART? I imagine that the 2nd packet arriving must at least wait until the first clears the UART -- or there must be some sort of internal buffer of some limited size...

---

Yes there are internal buffers that can hold a few packets at most that are used.

Answer 2

TCP flow control on the XBee will work fine with any speed host processor or multiple TCP connections as long as serial hardware flow control is being used.

When the host processor can't handle any more data it should lower its serial RTS and the XBee will stop sending serial data to it. When the serial port is flow controlled, the XBee's TCP window will eventually fill up indicating to the other side of the TCP connection that there is no more room and the TCP flow will pause. The XBee will not drop any data on the TCP connection unless that connection is closed. This is the same behavior if there are multiple TCP connections.