The current logic below __pmGetPDU() does include possible blocking when the
data available is less than the (known after the PDU header) length of the PDU.
Mostly this works just fine, as the remainder of the PDU will be available
"real soon now" (tm), but it does expose a possible DOS attack from a malicious
client for servers processes that read PDUs from arbitrary clients (pmcd and
pmproxy in particular).
To fix this requires moving PDU assembly up the food chain and the app mainline
taking more of an event-driven view of I/O. See the comment about "I/O
routines transformed to continuation-passing style" in libpcp/src/pdu.c.
This approach needs to be an alternative to the classical approach, as we'd
expect most PCP apps to continue to work without mainline changes and no DOS
exposure from this possible attack vector.