Hello again,
I've been busy working on Ken McDonell's suggestion of retaining "file
descriptor is an int" in the abstraction of the NSS/NSPR and POSIX
socket I/O. The work is not finished, but there is enough in place for
you all to see the new direction. The work is still being done in the
brolley/nss branch in our pcp repository at
git://sourceware.org/git/pcpfans.git
To summarize:
o __pmFD has been removed and all file descriptors are once again
represented by int.
o The normal socket I/O functions (socket, listen, bind, etc.) are still
abstracted as __pm* in src/libpcp/src/auxconnect.c. The previously
existing functions (__pmCreateSocket, __pmCloseSocket, etc) also remain
there.
o On platforms where NSS/NSPR is available, these functions use it,
otherwise, they use the native I/O functions.
o When NSS/NSPR is used, the integral fds which are generated refer to
items in a file descriptor table where the actual NSPR file descriptors
reside.
o The IPC table may simultaneously contain a variety of types of file
descriptors, so we need a way to distinguish native file descriptors
from the ones used to index the NSS/NSPR file descriptor table. There is
a simple mechanism in place to distinguish them. All fds whose value is
above INT_MAX/2 is currently a non-native file descriptor. It is likely
that a more elegant solution exists.
o Even when NSS/NSPR is available, all of the abstraction functions can
accept either native file descriptors and addresses or the ones which
refer to the file descriptor table. I inferred that this is necessary
since the pmcd appears to handle I/O from the pmdas in the same 'select'
loop as is used for the clients. So, at the very least the __pmFD_*
functions would need to handle this, as would __pmSelect. Another
solution might be to separate this into two loops. __pmSend and __pmRecv
also would appear to require this capability since they are called from
__pmGetPDU and __pmXmitPDU which both appear to handle fd's from various
sources. Should this capability not actually be required, it can easily
be removed.
o All components which create sockets using __pmCreateSocket must use
the __pm* abstraction for all further I/O since only these functions
understand how to use the non-native file descriptor returned by
__pmCreateSocket. Some components not related to pmcd<-->client I/O were
already using __pmCreateSocket in order to benefit from automatic
registration in the IPC table as well as some common socket options
being set. I converted these components to use the __pm* abstraction. If
this is not desirable, these changes can also easily be reverted.
o Only work for abstracting the I/O interface is currently in place.
Nothing has been done yet regarding a protocol between client and server
for upgrading the connection to SSL/TLS once a connection has been
established.
Once again, I am soliciting your comments/concerns/suggestions in order
to keep this work on track for eventual acceptance into the project.
Thanks,
Dave
|