Embedded Web Server for the CR16
TCP dictates that the Initial Sequence Number be generated by a 32-bit clock running at
250Khz. This method is utilized to help guard against overlapping segments between two peers
that may reestablish a connection after a previous one was prematurely aborted. We utilize a
32-bit timer managed by the OS as a basis for the ISN. However, this timer operates at the
OS system tick rate which may be anywhere from 100Hz to 250Hz. While posing no threat in
most/all embedded environments, this feature may be easily amended to comply fully with the
RFC, should it be deemed necessary in any specific application.
Use of the push flag
TCP requires that if the implementation does not allow the Application to control the Push flag,
it MUST be set by TCP in the final segment at a minimum.
This implementation does not afford the application with control of this flag; TCP sets the Push
flag in the final segment of every transmission.
Compliance with the IP Specification
As with TCP, RFC 1122 additionally supplements the original IP specification (RFC-791), by
summarizing requirements and correcting various errors and shortcomings detected over the
years. It conveniently lists those portions of the specification that MUST or SHOULD be
implemented in order to be in compliance (see Appendix B). Only a few of these features are
really necessary in a controlled, embedded environment (such as ours) and are consequently
omitted in whole or in part from this, as well as many 3rd party stacks. A few of the more
common of these features are briefly discussed in the following paragraphs, and just what is
and isnt included in this stack - and whether it matters.
IP Version Number:
Currently, only Version 4 (Ipv4) type datagrams are supported. Support for IPv6 is TBD. If
any other version number appears in the header of a received datagram, it is noisily discarded.
A host MUST verify the IP header checksum on every received datagram and silently discard
those datagrams that fail the test. As in the case of the TCP checksum, many stacks omit this
computation since the CRC performed by PPP is more than adequate. However, if used over
SLIP or another Link layer protocol that does no such error checking, the checksum is
necessary. For this reason, it is optionally included in the IP layer.
IP Fragmentation and Reassembly:
This IP does not support any form of fragmentation. Path discovery mechanisms are
encouraged to preclude fragmentation. In our case, the MSS is determined at compile time,
and is, for all practical purposes, equivalent to the MTU. This IP will never attempt to fragment