os independent interface to socket sendmsg/recvmsg

["Jeff Hill" <johill@lanl.gov>]

All,

I am looking at using some of the more advanced capabilities form the
sockets layer in the future, but there are some porting considerations.

BACKGROUND

In the interest of efficiency I would like to start using the Posix
sendmsg/recvmsg socket calls in the future with channel access. This
provides some advantages.

o sending/receiving multiple non-contiguous frames per system call improves
performance

o when receiving a UDP message it can be known if it was sent to a broadcast
or multicast address without binding to a specific address, and therefore
consuming an additional socket, and other per socket overheads such as
threads or buffers.

While there are OS specific behaviors associated with the more esoteric
features of this interface, it appears after some research that a lowest
common denominator posix functionality mentioned above is available on the
following OS, and presumably any emerging OS designs will also provide a
posix compatible socket interface to have any chance for success in the
future.

{AIX, cygwin, Darwin, freebsd, Linux, rtems, vxWorks, solaris, VMS (via
multinet)}

This leaves windows sockets. The WINSOCK API provides a functionally
equivalent, but incompatible, interface.

GENERAL STRATEGY

There are three options. 

Option 1.
The new server has already a pure virtual interface for communication with
the networking application layer; therefore the server can be attached to,
in addition to sockets, many different network application layers; we could
interface to streams, a zero copy layer, or presumably something really
foreign like DECNET. Within this layer there is now initially only one
implementation for posix sockets which accommodates also some degree of
socket library weirdness that occurs on Windows and VMS. In the future there
would be also a small amount of this code that would have three
implementations; one for Windows, one for advanced posix systems, and one
for legacy posix systems which would implement an OS independent wrapper
around the bare bones {WSAsendmsg/WSArecvmsg, sendmsg/recvmsg,
send/sentto/recv/recvfrom} functionality that is needed respectively. Of
course, it is highly desirable to minimize the size of the code fragments
that are OS specific when implementing this approach. The legacy posix layer
would probably not be needed, but it's sensible to preserve it as a backup
strategy. The legacy posix implementation would take the conservative
approach of assuming that all UDP messages were sent to multicast or
broadcast addresses, and therefore not allow negative search responses.
Therefore, implementation of a general purpose UDP name resolution server on
a stagnant OS implementation could not be advised.

Option 2.
I could move the OS specific code in option one to become a C++ operating
system independent layer implemented in libCom. Of course, implementing a
general purpose socket layer is a big job, and its difficult to be
successful when creating everyone's perfect donkey, given the rate of change
of networking technology and the sheer number of permutations arising in
different network kernel implementations. Therefore, I would be
intentionally implementing only a bare minimum portable lowest common
denominator subset of sendmsg/recvmsg functionality needed by ca. However
such a ca specific functionality might end up being a wart in libCom in the
long run, and this code would probably be criticized as not being a general
purpose implementation suitable for visibility by users of libCom other than
ca.

Option 3.
Do nothing. I am reluctant to choose this option because all OS other than
Windows appear to implement portable core sndmsg/rcvmsg functionality since
the early 90s, and the performance differences are probably also
non-trivial.

All comments appreciated.

Jeff
______________________________________________________
Jeffrey O. Hill           Email        johill@lanl.gov
LANL MS H820              Voice        505 665 1831
Los Alamos NM 87545 USA   FAX          505 665 5107

Message content: TSPA

With sufficient thrust, pigs fly just fine. However, this is
not necessarily a good idea. It is hard to be sure where they
are going to land, and it could be dangerous sitting under them
as they fly overhead. -- RFC 1925