fnSendTCP() behaviour

[johnr]

Hi Mark, I plan on using fnSendTCP()  as described in my previous post ,due
to our low bandwidth needs and it's more efficient memory usage.
 Does fnSendTCP() return <= 0 only when it can't resolve the ARP entry ?
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 ?
 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.
 If we have to break up a packet with multple fnSendTCP() calls, it loks 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.


 Thanks,
 John
 

[mark]

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

[johnr]

Thanks Mark, It's getting clearer now
  USE_BUFFERED_TCP isn't defined in my project, we're not using TELNET, so TCP_BUFFER_FRAME isn't defined in app_hw_5233x.h.
How can it work ?

 John

[mark]

Hi John

When not using TCP buffer the TCP payload size will default to the Ethernet frame size (LAN_BUFFER_SIZE) - 62

See the following in tcp.c:
 #define TCP_DEF_MTU             (LAN_BUFFER_SIZE - ETH_HEADER_LEN - IP_MIN_HLEN - MIN_TCP_HLEN - 22) // default TCP window size

I made a mistake the last time with 1480, it is in fact 1460 (IP datagram length [max. 1500] minus IP and TCP headers).

Regards

Mark

[johnr]

Thanks, Mark. I'll limit my TCP data payloads 1460 bytes.


 John