<div dir="ltr"><div>Hello all,</div><div><br></div><div> As one outcome of my recent burst of activity, I found what I think is a deficiency in NUT socket protocol, logged at <a href="https://github.com/networkupstools/nut/issues/1920">https://github.com/networkupstools/nut/issues/1920</a> now.</div><div><br></div><div>Relevant extract:</div><div></div><div>
<p dir="auto"><i>Currently <code class="gmail-notranslate">dstate::sock_arg()</code> in many cases quietly does:</i></p>
<div class="gmail-snippet-clipboard-content gmail-notranslate gmail-position-relative gmail-overflow-auto"><pre class="gmail-notranslate"><i><code class="gmail-notranslate">/* The command was handled, status is a separate consideration */
return 1;
</code></i></pre></div>
<p dir="auto"><i>Which does not tell the direct client (<code class="gmail-notranslate">upsd</code>) or eventually the user's client (<code class="gmail-notranslate">upscmd</code>, <code class="gmail-notranslate">upsrw</code>...) how that handling ended up.</i></p>
<p dir="auto"><i>At least some (new) cases might instantly report whether they succeeded or not, similar to how <code class="gmail-notranslate">DATADUMP</code> handling ends with <code class="gmail-notranslate">DATAOK</code> (as opposed to <code class="gmail-notranslate">DATASTALE</code>), or <code class="gmail-notranslate">PING</code> ends with <code class="gmail-notranslate">PONG</code>, but currently do not due to lack of protocol keywords for that at the moment.</i></p>
<p dir="auto"><i>The return values from main/driver-specific handlers (per enums in <code class="gmail-notranslate">drivers/upshandler.h</code>)
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.</i></p>
<p dir="auto"><i>In the bigger picture, may the socket protocol be treated as a private experience between current versions of <code class="gmail-notranslate">upsd</code>
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?</i></p>
<p dir="auto"><i>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).</i></p><p dir="auto"></p><p>What would the esteemed community suggest here (especially if there are some impacts I might have overseen in the cursory reading?)<i><br></i></p><p>Thanks in advance,<br>Jim Klimov</p><p><i><br></i></p>
</div></div>