Justin Clark-Casey informed me that it is out of spec to hand a domain
name to clients, so there is no DNS at all, let alone a fix. The
messages for clients are also generated in Opensim away from the
client-stack, so passing internal/external IP addresses is infeasible
without unpacking and repacking messages to clients.
We are sticking with our current solution, which is an isolated VLAN
that allows for addressability on the external ip addresses without
relying on a loopabk. All Opensim hosts have their regular networking,
plus the vlan for inter-sim communications.
Michael Heilmann
Research Associate
Institute for Simulation and Training
University of Central Florida
On 03/18/2015 05:05 PM, David Saunders wrote:
Hey,
My observations when I was trying to set up behind a non-loopback
router was the Robust sends the IP and not the named address. This is
proven, on my development network I have a public IP through a Nat
router that does not do loop back. The internal IP to the server.
IT works good on thing that you can use the named address, I am able
to connect to the robust server, but the handoff to the regions is by
IP. If you have the debug console running on the console it will show
it trying to connect to the public IP not the internal IP.
On Wed, Mar 18, 2015 at 4:47 PM, Shaun T. Erickson <[email protected]
<mailto:[email protected]>> wrote:
Michael,
Did you ever pursue this effort? I was very excited when it was
brought up, as eliminating the need for NAT Loopback would be
immensely useful to many folks.
-ste
On 12/22/14 11:22 AM, Michael Heilmann wrote:
I understand. I am performing my own investigation on address
passing in Opensimulator before narrowing down any approach.
The extra addresses in ExternalHostName that you mentioned
seems possible, I'll refer to it as option 1.
option 2:
It crossed my mind that InternalAddress may be able to hold
that information, as it functionally aligns with
addressability on internal networks. However, this could
cause problems if a region is listening on two distinct
internal networks on two separate NICs.
option 3:
RFC 1918 defines address spaces for internal networks, so it
may be simpler to trust the
10.x.x.x/172.16.x.x-172.31.x.x/192.168.x.x networks to be
internal if they appear. The catch would be if a region is
listening to separate internal networks on separate NICs,
which NIC address should be returned? Would it be feasible to
detect the internal network address that the connection is
made through, and use that address? This seems the most
elegant from a networking perspective, but Opensimulator
messages are not generated in the clientStack, and I am not
attracted to modifying packed messages on their way out the door.
A fourth option:
Instead of overriding the internal address/external host name
functionality, have this new functionality override any
address when a client appears on an internal network, and
respond with the network ip address that the host machine is
using on that local network. This functionality would then
not always be on, but be configured through an ini file flag.
This would allow for address/mask definition without affecting
the current addressability.
So far I have noticed that typically where a message is
generated and packed, that there is a UUID identifying the
client/Avatar in question. I wonder if some singleton lookup
object could house the connection types, and be queried where
these messages are generated.
Any other ideas, or changes to these are welcome.
Michael Heilmann
Research Associate
Institute for Simulation and Training
University of Central Florida
On 12/19/2014 04:34 PM, Justin Clark-Casey wrote:
The 6-8 week estimate was based on a quick plunge through
the code to give an estimate to the client I had at the time.
I didn't do any actual work so unfortunately I have no
detailed design and I can't guarantee this would work.
My initial thought was to have some syntax in the
ExternalHostName field that could allow two addresses and
specify when
each would be used. For example, perhaps
ExternalHostName = 192.168.1.2:192.168.1.0/24;63.3.19.155
to specify that all requests originating from the
192.168.1.0/24 <http://192.168.1.0/24> subnet would be
served the local IP 192.168.1.2 but all
others would receive 63.3.19.155. One requirement for any
scheme is that it is backward compatible (i.e. just a single
IP address/FQDN will behave as it does now).
This then needs to flow throughout OpenSimulator so that
at the crucial UDP points (login/entity transfer) one will
serve back the correct address in response to a client
request. I expect this data will have to be stored in the
Regions db table which might require an expansion of the
current varchar(64) type for serverIP.
Trying to match this to all the HTTP parts where an
address is separately specified would be a massive pain but
hopefully is completely unnecessary, as one can give FQDNs
at those points which are resolved dynamically (I think!).
The usual practice for code submission is to create a
patch and then put it on the Mantis database in "Patch
Included"
state, as described at [1]. It is then assessed by a core
developer(s) and included or feedback given as appropriate.
In this case, though, I would also like to see some
feature proposal doc [2] before a patch, if only to see
what the
proposed config format is and catch any early problems.
Also, this is the kind of significant feature where I think we
would want to have see a contribution agreement, which
core and other developers have done. More details at [3].
I'm very happy to keep discussing this on this list. A
proposal or even a patch doesn't need to be complete
before it's
public. In fact, I'd much prefer to discuss issues as
they come up so that myself and other people on this list can
identify problems early and even point out if there are
basic issues with the idea of serving different IP
addresses for
UDP to different clients based on their requesting IP.
[1] http://opensimulator.org/wiki/Submitting_code_to_OpenSim
[2] http://opensimulator.org/wiki/Feature_Proposals
[3] http://opensimulator.org/wiki/Contributions_Policy
On 18/12/14 14:07, Michael Heilmann wrote:
Justin
The inability to pass a FQDN to the client is
interesting, I did not see that.
Doug and I discussed our level of interest in this
functionality, and your solution. I will begin work
to explore and
implement your solution immediately. As I am not a
core developer, and in fact this would be my first
contribution to
opensim, I may need some guidance on your normal code
submission practices. We (MOSES) have our own git
clone of
opensim master on github that I will be working out of.
_______________________________________________
Opensim-dev mailing list
[email protected]
<mailto:[email protected]>
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
[email protected] <mailto:[email protected]>
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
[email protected]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
