On some computers (for instance, Linux machines that
dynamically get an IP address using dhcp and for which
there is no DNS entry) the world address resolves to
the loopback address (127.0.0.1). Although a hostname
(e.g. "foobar.mydomain.net") can be established for
such machines using
InetAddress.getLocalHost().getHostName(),
the InetAddress cannot determine the corresponding
Internet IP address (e.g. 66.35.250.150).
This causes several problems:
* Agents that are created in such a world and want to
migrate to a remote environment and come back will
fail, because they do not know the actual address of
their home world.
* Agents that migrate to the world (having obtained the
IP address of the machine by other means) and that
check in their startUp method where they are to decide
on their subsequent actions will not function
correctly. Typically, they will endlessly migrate to
the same world.
Logged In: YES
user_id=803935
I do not yet know a good way to fix this:
* ServerSocket#getLocalAddress does not work.
* Once a socket has been created (e.g. to another world),
the IP address can actually be establised using
Socket#getLocalAddress. However:
- Setting the world's address to a new correct
WorldAddressImp object may be too late, as some agents may
already use the old, incorrect address.
- Changing the actual world address itself is not good
either, as it breaks the immutability of WorldAddressImp.
Also, there are then still problems with addresses that have
already been serialised.
- Creating a socket on creation of the world to an
arbitrary machine in order to establish the IP address is
difficult as well, as their is the question which machine to
connect to.
* Specifying the world address as a commandline argument
would work, but is not great. It is non-automatic, error
prone, and would not work for applets etc.
Logged In: YES
user_id=803935
Since version 0.94 of DIET Agents, it is possible to disable
the automatic detection of the world's IP address by
explicitly providing an address. This can be done using the
--host commandline option provided by BasicApp.
As has been said before, this is not ideal but at least it
provides a work around on machines where the automatic
detection fails.