DNS lookup and caching

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

DNS lookup and caching

Michael Heilmann
OpenSim Devs

In the region configs, if you use a hostname instead of an IP address,
Opensimulator will resolve it to an IP address immediately, passing the
IP address to the client instead of the hostname. Looking in the code, I
found a comment about xml-rpc and mono dns caching, but little else.  
Looking online, mono appears to cache DNS names for too long, and
changing the DNS cache refresh rate is not yet implemented -- but I
don't understand why resolving once and using the IP address instead
would solve that.

The MOSES Opensimulator Grid has over 100 regions on 10 hosts running on
a local LAN with internet connecting clients.  Our enterprise firewall
does not allow network hairpinning (servers refer to themselves or other
servers using external IP addresses). We have worked around this by
adding a VLAN, where servers can address eachother directly using their
external ip addresses.  This has mostly worked, but hosting an internal
nameserver would be much more desirable.  We are also forced to rely on
the IT guys in charge of the firewall and the switch to change anything,
and that is less reliable than we want.  An internal nameserver we can
do ourselves.

Can anyone explain the xml-rpc / mono dns caching problem that was fixed
by resolving the hostname and using the IP instead?  Is there a
persisting reason that hostname functionality has not been restored?  Thanks

--
Michael Heilmann
Research Associate
Institute for Simulation and Training
University of Central Florida

_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
Reply | Threaded
Open this post in threaded view
|

Re: DNS lookup and caching

justincc
AFAIK, this is because the viewer will not handle FQDN for at least region UDP.  This is most noticeable in the
TeleportFinishEvent message (see OpenSim/Region/ClientStack/Linden/Caps/EventQueue/EventQueueHelper.cs) where this is
only a SimIP slot for an IP address, not an FQDN.

I was sufficiently curious to look at why the viewer about message then displays the FQDN of the simulator (e.g.
sim10088.agni.lindenlab.com).  On inspecting indra/newview/llfloaterabout.cpp in the viewer code it's actually doing a
reverse lookup from the stored IP address.

One possible solution I've assessed in the past is to have OpenSimulator store different IP addresses that are served
depending on where the viewer request originated.  Viewers coming from the LAN could be served a LAN IP for the
simulator and viewers from the WAN a WAN IP.  This would avoid the need for 'loopback' routers.  However, the amount of
work is not trivial (I think 6-8 weeks for someone who knows the code).

On 17/12/14 16:06, Michael Heilmann wrote:

> OpenSim Devs
>
> In the region configs, if you use a hostname instead of an IP address, Opensimulator will resolve it to an IP address
> immediately, passing the IP address to the client instead of the hostname. Looking in the code, I found a comment about
> xml-rpc and mono dns caching, but little else. Looking online, mono appears to cache DNS names for too long, and
> changing the DNS cache refresh rate is not yet implemented -- but I don't understand why resolving once and using the IP
> address instead would solve that.
>
> The MOSES Opensimulator Grid has over 100 regions on 10 hosts running on a local LAN with internet connecting clients.
> Our enterprise firewall does not allow network hairpinning (servers refer to themselves or other servers using external
> IP addresses). We have worked around this by adding a VLAN, where servers can address eachother directly using their
> external ip addresses.  This has mostly worked, but hosting an internal nameserver would be much more desirable.  We are
> also forced to rely on the IT guys in charge of the firewall and the switch to change anything, and that is less
> reliable than we want.  An internal nameserver we can do ourselves.
>
> Can anyone explain the xml-rpc / mono dns caching problem that was fixed by resolving the hostname and using the IP
> instead?  Is there a persisting reason that hostname functionality has not been restored?  Thanks
>


--
Justin Clark-Casey (justincc)
OSVW Consulting
http://justincc.org
http://twitter.com/justincc
_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
Reply | Threaded
Open this post in threaded view
|

Re: DNS lookup and caching

Michael Heilmann
In reply to this post by Michael Heilmann
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.

--
Michael Heilmann
Research Associate
Institute for Simulation and Training
University of Central Florida

> AFAIK, this is because the viewer will not handle FQDN for at least region UDP.  This is most noticeable in the
> TeleportFinishEvent message (see OpenSim/Region/ClientStack/Linden/Caps/EventQueue/EventQueueHelper.cs) where this is
> only a SimIP slot for an IP address, not an FQDN.
>
> I was sufficiently curious to look at why the viewer about message then displays the FQDN of the simulator (e.g.
> sim10088.agni.lindenlab.com).  On inspecting indra/newview/llfloaterabout.cpp in the viewer code it's actually doing a
> reverse lookup from the stored IP address.
>
> One possible solution I've assessed in the past is to have OpenSimulator store different IP addresses that are served
> depending on where the viewer request originated.  Viewers coming from the LAN could be served a LAN IP for the
> simulator and viewers from the WAN a WAN IP.  This would avoid the need for 'loopback' routers.  However, the amount of
> work is not trivial (I think 6-8 weeks for someone who knows the code).

_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
Reply | Threaded
Open this post in threaded view
|

Re: DNS lookup and caching

justincc
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.
>


--
Justin Clark-Casey (justincc)
OSVW Consulting
http://justincc.org
http://twitter.com/justincc
_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
Reply | Threaded
Open this post in threaded view
|

Re: DNS lookup and caching

Michael Heilmann
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
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
Reply | Threaded
Open this post in threaded view
|

Re: DNS lookup and caching

Shaun T. Erickson
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
> [hidden email]
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev

_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
Reply | Threaded
Open this post in threaded view
|

Re: DNS lookup and caching

David Saunders-2
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 <[hidden email]> 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
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev

_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev


_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
Reply | Threaded
Open this post in threaded view
|

Re: DNS lookup and caching

Michael Heilmann
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 <[hidden email]> 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
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev

_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev



_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev