Thanks for the detailed response Dave.
Let me just focus on the "int fd" issue.
On Mon, 2012-06-25 at 12:08 -0400, Dave Brolley wrote:
> ... I am very interested in the idea of a FD
> as an index into a table of actual file descriptors and, I believe that
> this will solve most of the issues you have raised. Is the IPC table
> what you had in mind, or are thinking of a separate table?
The IPC table may be the right place, provided we change the semantics
for that data structure. I'll use the IPC table in the outline below,
but deeper analysis might suggest another structure may be preferable.
What I had in mind was something along these lines:
* change the __pmIPC structure as follows:
* change socket to be flags and define bit field flags to
encode the channel's type (socket or otherwise for
Windows), clear text or encrypted (for your use), etc.
* add an int fd field for the clear text case
* add whatever extra "stuff" you need to make encrypted
* internally change the semantics of all "fd" things to be an
opaque integer handle (really an index into the IPC table) ...
this gives a natural encoding for valid (>=0), not assigned (-1)
and error (otherwise <0) that should not break any of the
existing APIs that pass "fd" things about.
* when you actually want to do I/O related stuff (read, write,
select, seek, close), map the handle into an __pmIPC struct and
provide code for the variant cases based on the flags
Places where we expect encrypted I/O would support both clear text (for
down rev) and encrypted (for the "both ends agree") cases.
Other places would only have the clear text support and could (should)
die noisily if the associated IPC table entry suggests otherwise.
So, for the all the PDU cases I think the only changes would be in
pduread() and __pmXmitPDU() within pdu.c of libpcp.
This would also have the advantage that the same infrastructure could be
used to get the initial pmcd<-->client communication covered, and then
could be leveraged to provide encryption on other classes of channel
within PCP if that was deemed appropriate ... rather than sweeping it
all up in one "big bang" of changes.