It is possible to define a number of virtual hosts in addition to a real host (standard host). The real host and the virtual host are created using the static or dynamic generation which BCAM offers. Additional steps must be taken in order to ensure that the applications can be addressed. It is possible for a virtual host to have a number of IP addresses.
This functionality has no impact on existing or new standard applications. The functionality is made available with the new subfunctions soc_ioctl() and getsockopt(), setsockopt(), which allow the sockets user to obtain the necessary information on the configuration with virtual hosts and to use this information appropriately in the applications.
The decision as to the host on which the application will run is taken when the bind() function is executed. At this time, the socket must be informed of the host to be addressed.
In the event of single addressing, this is done automatically using the specified IP address, and in the event of ANYADDR or LOOPBACK addressing, it is necessary to specify the relevant BCAM host name. Where required, this name must be entered in the socket using the new setsockopt() subfunction SO_VHOSTANY before bind() is executed. This is necessary because it is not possible to uniquely assign ANYADDR or LOOPBACKADDR to a host.
The new soc_ioctl() subfunctions SIOCGLVHNUM and SIOCGLVHCONF can be used to determine the number of virtual hosts and the associated BCAM host names and socket host names.
Note that it is, of course, still possible to assign sockets applications to a virtual host using the application table in BCAM.
This is why it is also possible to address the real host using the new functionality.
BCAM host name:
The name is eight characters in length. Alphanumeric characters and the special characters #, @, $ or blanks can be used at the end of the name. As a rule, uppercase characters should be used, but the name is case-sensitive. Names comprising numeric characters only are not permitted.
By default, the HOST-ALIASING functionality is active in the BCAM transport system. This can lead to undesired side-effects if the functionality for supporting virtual hosts is used.
HOST-ALIASING means that a request to establish a connection to a virtual host is forwarded to a real host if the relevant port number is only open in the real host.
HOST-ALIASING can be suppressed at the listen socket of the real host using setsockopt(fd, SOL_SOCKET, SO_DISHALIAS, 1, 4). If this flag is set in the socket prior to bind(), the subsequent bind() deactivates HOST-ALIASING for this port number in the BCAM transport system.
The result of this is that a request to establish a connection using this port number on a virtual host can only be successful if the port with the corresponding address is actually open on the virtual host. Requests are then not forwarded to the real host for this application.