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.