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
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]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
[email protected]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
