[Opensim-dev] DNS lookup and caching

Wed Mar 18 20:47:43 UTC 2015

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
> Opensim-dev at opensimulator.org
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev