File transfer can cause timeout

[rm5248]

Describe the bug
An OSDP device that I am using takes a long time to respond to file transfer messages from the CP. When libosdp is used as a CP, this results in the file transfer(firmware upgrade) messages not being sent, because libosdp decides that the PD is not responding.

Expected behavior
File transfer messages do not cause a timeout

Observed behavior
File transfer messages work

Additional context
I did a local fix by just setting OSDP_RESP_TOUT_MS to 800(from 200) in order to make sure that it works. There are two options that I can see on how to fix this:

1. For file transfer messages, automatically increase the timeout to be 3x OSDP_RESP_TOUT_MS
2. Add a flag to configure the timeout at runtime(to be 3x the standard OSDP_RESP_TOUT_MS)

[undici77]

I’m encountering the same issue. Fixed timeout should be ok (200ms) in many situation, but in my opinion it could be useful adding dynamic timeout based on baudrate and packet length.

DYNAMIC_TIMEOUT = ((frame_bits_per_byte × payload_bytes) / baud_rate_bps) × 1000
TIMEOUT = OSDP_RESP_TOUT_MS + DYNAMIC_TIMEOUT

Where frame_bits_per_byte could be fixed at 11 or 12 to consider worst case scenarios and considering different platform/latency.

[sidcha]

Hi @rm5248, @undici77, Which PD is this? perhaps you are both referring to one product that has this problem? Also, does the PD become slow in general or only to file transfer commands? If it's the later, we could do something about it. I ask because file transfer can be interleaved between other commands, we cannot just raise the time out for all commands, then we would not be spec compliant.

The 200ms hard limit comes from OSDP specification and in multi-drop networks if we wait for 600ms per PD, there would be a noticeable lag in the system with just 2 PDs offline or inactive.

[undici77]

In my case, the issue is simply related to OSDP_PD_CAP_RECEIVE_BUFFERSIZE. If you define a packet size of 256 at 9600, in 200 ms you can't send/receive the entire packet. The timeout should be calculated from when you finish sending the packet, not from when you start transmitting. Dynamic timeout not resolve the entire problem (shoud be relatd to answer length too) but looks a good tradeoff.

Otherwise FileTransfer packet size must be related to the timeout.

[sidcha]

The timeout should be calculated from when you finish sending the packet, not from when you start transmitting.

Fair point. This is something the spec states but there is no good way to handle this from the library. In a product I'm working on, where timing is critical, I have downstream patches to handle the ticks correctly to libosdp's accounting is wire accurate. That fix is not generic enough to be pushed upstream.

What we can do is add TIME_TO_TANSFER_ONE_BYTE * packet_len to the packet wait time accounting. This should place the internal accounting close to the end of real packet. It still doesn't account for transmission overhead but still better than current implementation.

[rm5248]

Hi @rm5248, @undici77, Which PD is this? perhaps you are both referring to one product that has this problem? Also, does the PD become slow in general or only to file transfer commands? If it's the later, we could do something about it. I ask because file transfer can be interleaved between other commands, we cannot just raise the time out for all commands, then we would not be spec compliant.

As far as I am aware, the only command that is a problem is the file transfer command. I agree that increasing the timeout for all commands doesn't make sense.

What we can do is add TIME_TO_TANSFER_ONE_BYTE * packet_len to the packet wait time accounting. This should place the internal accounting close to the end of real packet. It still doesn't account for transmission overhead but still better than current implementation.

This sounds like a good idea to me. The spec does say that the reply delay of 200ms is from the receipt of the checksum(e.g. CP->PD) to the start of the response, so it sounds like that is not currently taken into account.

Just some quick calculations for baud rate:

Baud rate	Bytes(10-bit) / second	Bytes / millisecond	Time to transfer 256 bytes(ms)
9600	960	0.96	266
38400	3840	3.84	66
115200	11520	11.52	22