--- /dev/null
+This library implements two NAL interfaces, both running over IP.
+The first, tcpnal, creates TCP connections between participating
+processes in order to transport the portals requests. The second,
+ernal, provides a simple transport protocol which runs over
+UDP datagrams.
+
+The interface functions return both of these values in host order for
+convenience and readability. However this means that addresses
+exchanged in messages between hosts of different orderings will not
+function properly.
+
+Both NALs use the same support functions in order to schedule events
+and communicate with the generic portals implementation.
+
+ -------------------------
+ | api |
+ |_______________________|
+ | lib |
+ |_______________________|
+ | ernal | |tcpnal |
+ |--------| |----------|
+ | udpsock| |connection|
+ |-----------------------|
+ | timer/select |
+ -------------------------
+
+
+ These NALs uses the framework from fdnal of a pipe between the api
+and library sides. This is wrapped up in the select on the library
+side, and blocks on the api side. Performance could be severely
+enhanced by collapsing this aritificial barrier, by using shared
+memory queues, or by wiring the api layer directly to the library.
+
+
+nid is defined as the low order 24-bits of the IP address of the
+physical node left shifted by 8 plus a virtual node number of 0
+through 255 (really only 239). The virtual node number of a tcpnal
+application should be specified using the environment variable
+PTL_VIRTNODE. pid is now a completely arbitrary number in the
+range of 0 to 255. The IP interface used can be overridden by
+specifying the appropriate hostid by setting the PTL_HOSTID
+environment variable. The value can be either dotted decimal
+(n.n.n.n) or hex starting with "0x".
+TCPNAL:
+ As the NAL needs to try to send to a particular nid/pid pair, it
+ will open up connections on demand. Because the port associated with
+ the connecting socket is different from the bound port, two
+ connections will normally be established between a pair of peers, with
+ data flowing from the anonymous connect (active) port to the advertised
+ or well-known bound (passive) port of each peer.
+
+ Should the connection fail to open, an error is reported to the
+ library component, which causes the api request to fail.