Addresses

The low-level format of the addresses are different depending on the mode of communication you have chosen. A function is provided by each of the lower layers to map a user-friendly string-form address to the binary form required by the lower layers.


    struct sockaddr_in *tcpip_strtoaddr(char *str);

    struct netbuf *mosi_strtoaddr(char *str);
   

The format for TCP/IP addresses is straightforward:


    <host> [ ':' <portnum> ]
   

The hostname can be either a domain name or an IP address. The port number, if omitted, defaults to 210.

For OSI, the format is


    [ <t-selector> '/' ] <host> [ ':' <port> ]
   

The transport selector is given as an even number of hex digits.

You'll note that the address format for the OSI mode are just a subset of full presentation addresses. We use presentation addresses because xtimosi doesn't, in itself, allow access to the X.500 Directory service. We use a limited form, because we haven't yet come across an implementation that used more of the elements of a full p-address. It is a fairly simple matter to add the rest of the elements to the address format as needed, however: Xtimosi does support the full P-address structure.

In both transport modes, the special hostname "@" is mapped to any local address (the manifest constant INADDR_ANY). It is used to establish local listening endpoints in the server role.

When a connection has been established, you can use


    char cs_addrstr(COMSTACK h);
   

to retrieve the host name of the peer system. The function returns a pointer to a static area, which is overwritten on the next call to the function.

Note: We have left the issue of X.500 name-to-address mapping open, for the moment. It would be a simple matter to provide a table-based mapping, if desired. Alternately, we could use the X.500 client-function that is provided with the ISODE (although this would defeat some of the purpose of using ThinOSI in the first place. We have been told that it should be within the realm of the possible to implement a lightweight implementation of the necessary X.500 client capabilities on top of ThinOSI. This would be the ideal solution, we feel. On the other hand, it still remains to be seen just what role the Directory will play in a world populated by ThinOSI and other pragmatic solutions.