Hi John
>>Does fnSendTCP() return <= 0 only when it can't resolve the ARP entry ?
Generally yes - if it were to fail for any other reason (I haven't seen this happening but theoretically it could be due to the Ethernet controller blocking for a short time). This case would however be handled by TCP_EVENT_REGENERATE since it is the same, from TCP perspective, as a lost tranmission.
>>After returning >0 the listener will get a TCP_EVENT_ACK when the other side acks us or a TCP_EVENT_REGENERATE on a timeout ?
Yes, correct. The frame has been sent so it will either be acked or gets lost.
>>Where is the TCP send/rcv buffer size defines used in in non-buffered mode ? I should set these to handle the largest packets I expect to send/rcv.
The maximum frame size is given by the LAN buffer space (#define LAN_BUFFER_SIZE 1536) which is maximum and defined by Ethernet. This contains the Ethernet header and the maximum payload is 1500 bytes.
The maximum TCP content will be this minus the IP header (20 bytes with out any IP option - not used by the uTasker stack). This leaves maximum TCP payload size of 1480 bytes per frame.
Therefore you can set TCP_BUFFER_FRAME to maximum 1480 and your code will have to ensure that no more is attempted.
>>If we have to break up a packet with multple fnSendTCP() calls, it looks like we would always need to prepend the MIN_TCP_HLEN space and set the push flag to 0 except on the last packet fragment.
Yes, each fragment uses the same buffer strategy.
The PUSH flag informs the receiving side that it should pass on any collected data to the application layer. I don't know whether you will in fact notice any difference depending on the use of this flag - but I try to set it only when a complete block of information has been completely sent. It is probably that many receiver side implementations will not actually bother about it though.
Regards
Mark