[Opensim-dev] DNS lookup and caching

Wed Mar 18 21:05:00 UTC 2015

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 <ste at smxy.org> 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 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
>>
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at opensimulator.org
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20150318/21282e96/attachment-0001.html>