Sliding Window

[aritec]

Set

define XTCP_ENABLE_PARTIAL_PACKET_ACK 1

define UIP_PACKET_SPLIT_THRESHOLD 4

is splitting my 9 byte packet in 2 packets. The first one with 4 byte is Ok, the second one with 5 bytes is just filled with Zeros.

[aritec]

The function in xcoredev.xc is changing data of the second packet

void
xcoredev_send(chanend tx)
{
  int len = uip_len;
  if (len != 0) {
    if (len < 64)  {
      for (int i=len;i<64;i++)
        (uip_buf32, unsigned char[])[i] = 0;
      len=64;
    }

    mac_tx(tx, uip_buf32, len, -1);
  }
}

If I comment the for loop who sets the buffer to 0, the 2th packet is not touched and the software is working much better.

regards
Armin

Hi Armin,
We haven't fully tested or documented this feature yet but are planning to do so.

Basically, a connection needs to sign up to the scheme by calling xtcp_accept_partial_ack.

If a connection does this then it may get an XTCP_REQUEST_DATA/SENT_DATA event where only some of the outstanding data has been acked. In this case the client has to shift its buffers accordingly.

For example, suppose I sent 1000 bytes via xtcp_send. This packet will be split in two.

If the first half is acked then the client will get an XTCP_SENT_DATA event but conn.oustanding will be set to 500.
Now the client needs to send a packet where the first 500 bytes are the same as the outstanding 500 but it can follow it up with another 500 bytes. In C you need to do something like

memcpy(buf,buf+conn.outstanding,conn.outstanding);
memcpy(buf+conn.outstanding,new_data,500)
xtcp_send(buf, conn.outstanding+500);

Here conn.oustanding+500 needs to be less than conn.mss . The scheme means that a XTCP_RESEND_DATA event always requires exactly the last data sent.

So the application manages its own sliding window. This tends to have better memory usage than the stack doing it.

I hope this makes sense. As I mentioned, we do plan to document this properly in the near future.

Dave