Skip to content

Extend driver-server socket protocol with verdicts #1920

@jimklimov

Description

@jimklimov

Follow-up from research in issue #1914 per implementation experience in PR #1918; possibly a solution vector for bug #1901.

Currently dstate::sock_arg() in many cases quietly does:

/* The command was handled, status is a separate consideration */
return 1;

Which does not tell the direct client (upsd) or eventually the user's client (upscmd, upsrw...) how that handling ended up.

At least some (new) cases might instantly report whether they succeeded or not, similar to how DATADUMP handling ends with DATAOK (as opposed to DATASTALE), or PING ends with PONG, but currently do not due to lack of protocol keywords for that at the moment.

The return values from main/driver-specific handlers (per enums in drivers/upshandler.h) might be reported in a similar fashion at least on the socket protocol. Just to know the command was acknowledged and perhaps how it ended up.

In the bigger picture, may the socket protocol be treated as a private experience between current versions of upsd and NUT drivers - e.g. if someone built/scripted interactions around that, and those third-party tools fail due to unexpected key words, we commiserate but it is not a NUT problem as such?

To be clearer, this is not immediately a question about on-line NUT protocol (data server to clients), although I would not be surprised if it sprouts into that too (or practical handling of that, to more relevantly report OK/ERR for client requests).

CC @aquette @clepple @NUT-RogerPrice

Metadata

Metadata

Type

No type

Projects

No projects

Relationships

None yet

Development

No branches or pull requests

Issue actions