This commit (brolley/dev in pcpfans) delays the initialization of
the NSPR, NSS and SASL libraries until their respective
functionalities are needed. As noted in the commit message, a
significant amount of pre-connect and pre-accept NSPR socket code
became obsolete and has been removed. Also, as I had hoped, the
NSPR/native division in the IPC table is also gone.
There is one qa issue which affects tests 712 and 966. In the old
implementation, servers would initialize NSS right away and, should
that fail, were able to report that secure connections are not
supported during the connection handshake with the first client to
connect. With the new implementation, NSS initialization is not
attempted until the first secure connection is actually requested
(after the first connection handshake). Thus, when the first client
connects, a server built --with-secure-sockets will report that
secure connections are supported, even though that may ultimately
turn out not to be true (e.g. NSS init fails because there is no
server certificate). Once NSS init has failed, the server is then
able to report that secure connections are not supported during
subsequent connection handshakes.
The visible result is that the first client to connect may be told
that secure connections are supported, only to get "connection reset
by peer" when a secure connection is actually requested. With the
old implementation, the first client to connect would be told during
the handshake that secure connections are not supported and would be
able to correctly report that to the user.
I'm not quite sure how to handle this. Suggestions please! One
possible solution is to have clients try to connect a second time
when they receive "connection reset by peer" the first time. During
the second handshake, the server will correctly report that secure
sockets are not supported. Another related solution might be to have
the server report that the status of secure connection support is
unknown. This could then be used as the trigger for a second
connection attempt by the client should an initial secure connection
attempt fail.
One other thing to note is that, while the entire socket I/O
abstraction layer API remains intact, much of it (the pre-connect
and pre-accept functions) now have only one implementation (the
native one). Similarly, the types __pmFdSet, __pmSockAddr,
__pmAddrInfo and __pmHostEnt now also have only the native
implementation. It is tempting to consider removing the abstraction
layer from around these functions and types, however, I'm leaning
toward leaving them as they are:
- they could become necessary again in the future should a
different implementation of secure sockets be needed
- they present a level of consistency to users of the socket I/O
API in that all aspects are presented as __pm* functions and
types. This eliminates the need for callers to know where the
underlying abstraction is actually applied, and where it is not.
Dave
-------------------------------------------------------------------
commit 3ac317d69082365c12f51d82779431b531a72ed2
Author: Dave Brolley <brolley@xxxxxxxxxx>
Date: Wed Aug 13 13:07:19 2014 -0400
Delay the initialzation of NSPR, NSS and SASL libraries.
Initialization of these libraries incurs a significant
penalty in the form of resource (memory) usage. This change
delays this initialization, for both clients and servers,
until their respective funcionalities are required.
A significant amount of socket I/O abstraction code
(pre-connect/pre-accept NSPR implementation) was made obsolete
and was removed. The separation of native and NSPR file
descriptors in the IPC table is also no longer necessary
and the related code has been removed.
|
|