@author Daniel F. Savarese @see DefaultSocketFactory
Both {@link java.lang.Object#equals(java.lang.Object) Object.equals()} and {@link java.lang.Object#hashCode() Object.hashCode()} should be overridden appropriately. Protocol socket factories are used to uniquely identify Protocol
s and HostConfiguration
s, and equals()
and hashCode()
are required for the correct operation of some connection managers.
An instance of this interface can be passed to methods that allocate sockets. In this way, the actual, underlying type of socket allocated can be replaced (for instance, with an SSL socket or an firewall-tunnelling socket), without the user of the socket having to explicitly be aware of the underlying implementation.
In some ways, this class is a replacement for the SocketImplFactory
class. This class addresses the following issues.
SocketImplFactory
may be installed only once for the entire process, so different policies cannot be used concurrently and/or consectively. For instance, imagine a situation where the user wants one part of the program talking via SSL to some port on machine A and via standard sockets to some port on machine B. It is not possible to install separate SocketImplFactory
objects to allow both. Socket
class presumes a highly-connected network with the ability to resolve hostnames to IP addresses. The standard Socket
class always converts the hostname to an IP address before calling SocketImplFactory
. If the hostname does not have an IP address, then the SocketImplFactory
never gets a chance to intercept the host name and perform alternate routing based on the name. For instance, imagine that the user has implemented a firewall-tunnelling socket; the raw hostname must be passed to the firewall machine, which allows the socket to be established once some out-of-band credentials are supplied. But we could never get this far because the standard Socket
class would have already rejected the request since the IP address of the target machine was unknown.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|