Clarification on REPLY_BUSY handling in PD mode

[amarinelli-1994]

Dear Siddharth,

I’ve been exploring the handling of REPLY_BUSY (0x79) in libosdp, and I noticed that while the Control Panel (CP) side seems to correctly process a REPLY_BUSY response (e.g., transitioning the PD state to OSDP_CP_STATE_WAIT), I couldn’t find where the Peripheral Device (PD) side actually generates this reply.

Specifically, in do_command_callback() (in osdp_pd.c), any nonzero return value from the command callback currently results in:

pd->reply_id = REPLY_NAK;
pd->ephemeral_data[0] = OSDP_PD_NAK_RECORD;

This means even if the callback returns OSDP_PD_ERR_BUSY, the PD still sends a REPLY_NAK.

I also noticed that OSDP_PD_ERR_BUSY is defined and documented, and the CP parser handles OSDP_ERR_PKT_BUSY, so it looks like the groundwork for REPLY_BUSY support is already in place — just not hooked up on the PD side.

Could you clarify:

Is the omission of REPLY_BUSY generation on the PD side intentional or just unimplemented so far?

Or do you envision a different mechanism for PDs to signal they’re busy?

Thanks for your time and for maintaining this great library!

[sidcha]

Is the omission of REPLY_BUSY generation on the PD side intentional or just unimplemented so far?

Hi @amarinelli-1994, Its the later: just not implemented so far.

The CP side implemented it because it need to interact with other PDs implementations which may send such responses. In LibOSDP's PD implementation, so far there hasn't been any need to send a busy response (although the file transfer implementation is a prime candidate for it). PRs to add support for PD side busy handling are welcome :)