A server accepts requests for a service by advertising the service on a known interface and port, represented in the server itself as a socket-binding. Clients establish connections to those socket bindings to make use of the service on the server.

In complex network setups,it may be that the service is available on different interface/ port combinations, depending on the network the client is accessing the server from. In the case of EJB clients, client-mappings associated with a socket-binding allow a server socket to be configured such that the destination address that the client uses to access the service will be chosen based on the network the client is accessing the service from. Here is an example of a client mapping:

<socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">
    ...
    <socket-binding name="myservice" port="1234">
      <client-mapping source-network="10.26.3.10/8" destination-address="10.26.3.7" destination-port="4321"/> 
      <client-mapping source-network="15.16.5.32/16" destination-address="15.16.123.39" destination-port="1324"/> 
    </socketbinding>
   ...
</socket-binding-group>

When an EJB client receives topology updates from a cluster, for each cluster referenced in the topology update, it receives the cluster name and the list of nodes/members of the cluster, and, for each member, the set of client mappings associated with the node.

When a client makes an invocation on the cluster, this information is referenced in order to choose a node from within the cluster. The choice of node involves checking to see if the interface from which the client is making the invocation (source address) is compatible with one of the client mappings associated with the node: in other words, if there exists a client mapping for the node such that the invocation interface belongs to the source network of the client mapping.

Client-mapping information for cluster nodes/members is stored as an attribute source-ip along with ServiceURLs representing those nodes. These are created when the topology update is received. These serviceURLs are then used by EJBClientContext.peformLocatedAction() to choose a target node, taking into account the interface from which the client is sending the request.

There are a few anomalies in the processing of client-mappings. This issue with address a few of them.

The first anomaly is that in order to check if the interface on which the client is sending the invocation is part of the network for a given client-mapping, we need to get an IP address for that interface.

The intended function of the method

SocketAddress EJBReceiver.getSourceAddress(URI uri) 

seems to be to get the source address of a connection to the tareget URI, in order to perform this check. But for all implementations of EJBReceiver (RemoteEJBReceiver and LocalEJBReceiver) this methoid returns null. This effectively disables checking of client mappings, as far as I can tell.