RETURN_ON_ERROR_NO_DISCONNECT Behaviour

Device Code
1

Hi guys,

I’m looking at changing our send timeout policy from RETURN_ON_ERROR WAIT_TILL_SENT to RETURN_ON_ERROR_NO_DISCONNECT WAIT_TILL_SENT but just wished to confirm its exact behaviour. Primarily, under what circumstances is onunexpecteddisconnect still triggered?

My expectation is that a genuine loss of connection would still trigger onunexpecteddisconnect and that the only time I need to take different action is when receiving SEND_ERROR_WOULDBLOCK, would this be a correct assumption?

i.e. if I received SEND_ERROR_NOT_CONNECTED, SEND_ERROR_TIMEOUT or SEND_ERROR_DISCONNECTED, assuming I haven’t manually disconnected, that the onunexpecteddisconnect handler will have already been called and that I just have to handle SEND_ERROR_WOULDBLOCK.

Many thanks

2

If the link goes away when there’s no data being sent then you will still get the unexpected disconnect handler firing.

The difference is that if the TCP TX buffer fills and the send timeout hits, you will get wouldblock but the device will stay connected. It’s up to you to call server.disconnect and reconnect.

So, yes - pretty much just as you say. Note that you may well find connecting a UART to get debug messages out when working on this type of code is very useful!