The use of Sockets, both client and Server, have restrictions on OpenShift due to the multi-tenant architecture that provides for a high-density of applications to run on a single OpenShift Node. First, this blog will use Java as an example but the concepts hold true for the underlying C sockets. Second, a little background …
Each Cartridge instantiation is allowed to bind to a single, Node-unique loopback address provided by the Node and available as an environmental variable (e.g. OPENSHIFT_JBOSSAS_IP). This design allows each instantiation to bind to standard ports with no conflicts between instantiations running on the same Node. External communication is handled through proxies (Apache & HAProxy) running on each Node.
ServerSockets must bind to the unique loopback. SELinux will prevent an instantiation from binding to any address other than the unique loopback provided by the Node.
Client Sockets must not call an explicit bind if they are intended to connect to a remote address. If the Socket is intended to connect to the unique loopback then the Socket must bind to the unique loopback provided by the Node. If the Socket attempts to bind to another address then permission will be denied by SELinux. If a Socket bound to the unique loopback attempts to connect to a remote address the connection will fail with a no route to host.
Several clustering technologies (e.g. JGroups, Hazelcast) are designed so that each cluster node sends the other cluster nodes information on how to connect back. In OpenShift there needs to be two sets of configuration params (host/IP and port) for these types of mechanisms. The first set is the local binding that consists of the unique loopback and port. The second set is the host/IP and port that is advertised to the other cluster nodes for how to connect back. This second set it the address and port of the Node proxy.
Several popular and widely used components did not or do not provide the configuration options required to deploy on OpenShift. Several versions of JGroups and AS/EAP support the required configuration options. The required configuration options for Vert.x and Hazelcast is in process. Several Spring and Apache components do not yet support the required options.