[Nut-upsdev] [nut-commits] svn commit r1376 - in trunk: . server

[Arjen de Korte]

> btw, I'm finalizing the very last changes for 2.2.2-pre1 (--with-lib
> becoming --with-dev + NEWS and UPGRADING completion). Do you hold some
> more on netxml and Bruce related subjects?

Yes, there are:

- drivers/usbhid-ups:
I intend to backport all the changes that are still in the trunk. Despite
having asked for comments and testing numerous times on the Development
mailing list over the past few weeks (and months), I have received little
to no comments. So either these changes are the best thing since sliced
bread, or I am the only active developer with a USB HID UPS. Either way, I
see no alternative other than by backporting this to Testing get feedback
from the field (and see what happens). The version we have now in Testing
broke some devices with exceptionally long report descriptors, so we'll
have to do something here anyhow.

- clients/upsclient.c:
I'm working on resolving a bug here, where the clients block if the server
is not responding. The solution is to use select() to allow the server
some time (5 seconds, in order not to wait to long) to send an answer and
if this doesn't arrive, give up on it and disconnect. To make things more
robust the other way around, we'll use a similar mechanism for sending
data to the server.

- drivers/dstate.c:
Basically the same is true here. We don't handle situations like the above
gracefully when sending something to the server. On a highly loaded server
when the IPC pipe is getting full, the write() command that sends data to
the server fails eventually. Again, a select() on sending data to the
server with a timeout value of 5 seconds might solve that (by preventing
the the driver from sending more data when the pipe is already full).

The recent changes to the server will *not* go into Testing. I'm not
entirely sure that this is portable on older platforms. Since the audience
for servers handling more than FD_SETSIZE connections will be quite
limited, I don't think we have a lot to gain by hurrying this to Testing
(although the poll() mechanism is a somewhat cleaner solution than
select() is).

Best regards, Arjen