|
From: Brian M. <btm...@gm...> - 2010-09-09 13:41:43
|
On Wed, Sep 8, 2010 at 8:18 AM, Bryan Thompson <br...@sy...> wrote:
I am wondering how we should construct and expose for configuration
> ServerSockets for custom data transfer services. Right now we have two such
> services which open ServerSockets to do NIO operations on ByteBuffers.
>
> public ServerSocket(int port, int backlog, InetAddress bindAddr) throws
> IOException;
>
> This allows us to specify the port (or pass 0 for a random port) and to
> specify the local IP address on which the service will communicate. T
> it could also be nice to have the service talking on a configured port (for
> example, in order to simplify firewall configuration).
>
It seems that the pattern in use right now to specify the INetAddress is:
>
> InetAddress.getByName(
> NicUtil.getIpAddress("default.nic"/*systemPropertyName*/,
> "default"/*defaultNicName*/, false/*loopback*/)
> );
>
> Presumably, the "default.nic" value could be replaced by the name of a
> different system property if we wanted to bind high volume data transfers
> onto a specific.
> It that is the intention, then perhaps we should define an alternative
> system property name for those cases and begin to use it at the appropriate
> locations in the code base.
>
Yes, "default.nic" could be replaced with a different value.
That value was created as a special value when you requested
that a mechanism be added for telling the configuration that you
would prefer that the system's default nic be used, whatever it
may be, rather than a specific nic name. This was needed because
the default nic on Windows cannot generally be know a priori, and
may actually change upon reboot. Whereas the use of this
'default.nic' mechanism is very convenient for development, it is
not necessarily the best solution for real deployment scenarios;
where there is quite a bit more control of the environment, where
there may be multiple nics one wishes to configure, and where
a priori knowledge can be exploited to make life easier for the
deployer in the data center.
For example, if you look at my personal branch, you will see a class
named ConfigDeployUtil that is used in each smart proxy's config
file to retrieve things like the groups or nics or ports, from a single,
top-level deployer-oriented config file that is in the form of a
name=value text file rather than a jini config (which deployer's seem
to prefer over the jini config format). The ConfigDeployUtil class
makes certain assumptions about its environment. So, although that
class is not very general purpose, it's intent is to shield the deployer
from the jini config files; thus making the life of the deployer much
simpler.
I wouldn't necessarily expect ConfigDeployUtil to be used with the
ServicesManagerService mechanism. And there are numerous
options for what may be used to replace the "default.nic" parameter
above; setting system properties being one such option.
> However, this still leaves unspecified a pattern to configure the port for
> the service. Would you envision a "PortUtil" (or an extension to NicUtil)
> which uses a similar pattern specifying the system property name and the
> default port name (or port number)?
>
I don't think a utility such as a "PortUtil" is necessary. The purpose of
the NicUtil was to provide code that can be executed from either
the config file itself, or from other code in the system; allowing one
to retrieve IP or Inet addresses based on a given network interface
name. This provides a way then, for avoiding the configuration of
specific IP addresses; instead configuring nic names, which vary far
less greatly than IP addresses do.
With respect to port numbers, it seems like a simple 'port = value'
should suffice; whether you're using jini configs or any other sort
of config file.
BrianM
|