[lwip-devel] Change to tcp_enqueue option support

[Kieran Mansley]

I'd like to rework the way that TCP options are handled by tcp_enqueue.
My goal is to add support for TCP timestamps, but this part of the
change should be reasonably generic to other TCP options as well.

At the moment tcp_enqueue will take either data or options but not both.
I would like to change it to be able to cope if both are requested.  I
think this is a straightforward and safe change, so don't expect anyone
will object, but if you do please let me know.

I would also like to change the way that options are added to segments.
At the moment the caller of tcp_enqueue passes in a region of memory
with the options rather like it would a payload.  I would like to change
this so that it just passes in flags indicating which TCP options it
would like to have included.  These flags would then be stored by
tcp_enqueue in the segments, and appropriate space for the options
reserved between the conventional TCP header and the payload.  When the
segment was output the requested options would be computed and written
to the reserved location.

This has some advantages (for example it is necessary to support things
like the timestamp option without lots of special-case code) but also
some disadvantages: it's probably a little more code, and it would
require the requested option flags to be stored in the tcp_seg structure
so making that a little bigger.  An alternative that wouldn't increase
the size of the tcp_seg structure would be to use the tcp_pcb->flags
field to store this information; this wouldn't allow different segments
on a connection to take different options (apart perhaps from some
special cases like SYNs) but that would probably be fine for our
immediate needs.

The other consequence of significance is that it would change the
arguments of tcp_enqueue().  As this doesn't form part of the documented
API I'm happy with this, but I'd be interested to know if people are
using it directly as there are probably ways to avoid changing it if
they are.

Any thoughts or objections?  I'm working on a patch that might make some
of this clearer.

Thanks

Kieran