Hi Ewan
TCP/IP stacks on the PC usually allow a parameter which enables or disables delayed acks. Which parameter it is depends on the stack, so there is no general solution to doing it.
Programs like web browsers or FTP clients probably don't allow this to be influenced by the user and will probably always have it enabled.
Since the uTasker TCP/IP stack works with call back routines it doesn't use delayed acks (delayed acks only really make sense when the application which receives the packet may at a later point in time - within +>..200ms - send data and so the ACK to the received frame can be piggy-backed with the application data). Callbacks always immediately know whether the application is sending data. The only time that delayed ack could be beneficial is when the same socket 'also' generates data at a random time as well as handling the call back. The delayed ack can save an ACK or two on the network but is not always desirable and many protocols (especially industrial ones - eg. MODBUS TCP and various others) do suggest disabling it. Therefore there doesn't seem to be any demand for the feature in the uTasker project, and this is why it is not supported (although it would be possible to add...).
The TOS characteristics that you have mentioned are used in IP frames. There are (theoretically) used by routers which pass the IP frames so that the router can prioritize frames. For example a router may give preference to IP frames with the TOS set to TOS_MINIMISE_DELAYS. It may try to route IP frames with TOS_MINIMISE_MONETARY_COST through cheaper connections (which may be slower or less reliable but less expensive to use). The other ones are probably also logical.
Nowadays the MONETARY one is probably redundant and networks are so much faster and reliable that they all don't have much meaning. Probably most routers don't even look at them (?). When defining an IP frame one simply chooses the type that best matches the service. 'Real-time' Ethernet protocols will go for TOS_MINIMISE_DELAY, or FTP may chose TOS_MAXIMISE_THOUGHPUT because large amounts of data are expected. As I mentioned, it may all be a bit academic because who know whether a router in the path looks at it or behaves any differently? In a LAN there are often no routers and so it really doesn't help to flag an IP frame as having a higher priority than another...
Regards
Mark
