<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
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.<br>
<br>
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.<br>
<pre class="moz-signature" cols="72">Michael Heilmann
Research Associate
Institute for Simulation and Training
University of Central Florida</pre>
<div class="moz-cite-prefix">On 03/18/2015 05:05 PM, David Saunders
wrote:<br>
</div>
<blockquote
cite="mid:CAOjZz+=91d3QeSFM9CgrThEue12R3B-CO0c_7aWrq9ra5Z7+Rg@mail.gmail.com"
type="cite">
<div dir="ltr">Hey,
<div><br>
</div>
<div> 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. </div>
<div><br>
</div>
<div> 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. </div>
<div><br>
</div>
<div><br>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Wed, Mar 18, 2015 at 4:47 PM, Shaun
T. Erickson <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:ste@smxy.org" target="_blank">ste@smxy.org</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">Michael,<br>
<br>
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.<span class="HOEnZb"><font
color="#888888"><br>
<br>
-ste</font></span>
<div class="HOEnZb">
<div class="h5"><br>
<br>
On 12/22/14 11:22 AM, Michael Heilmann wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
<br>
option 2:<br>
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.<br>
<br>
option 3:<br>
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.<br>
<br>
A fourth option:<br>
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.<br>
<br>
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.<br>
<br>
Any other ideas, or changes to these are welcome.<br>
<br>
Michael Heilmann<br>
Research Associate<br>
Institute for Simulation and Training<br>
University of Central Florida<br>
<br>
On 12/19/2014 04:34 PM, Justin Clark-Casey wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
I didn't do any actual work so unfortunately I
have no detailed design and I can't guarantee this
would work.<br>
<br>
My initial thought was to have some syntax in the
ExternalHostName field that could allow two
addresses and specify when<br>
each would be used. For example, perhaps<br>
<br>
ExternalHostName = 192.168.1.2:192.168.1.0/24;63.3.19.155<br>
<br>
to specify that all requests originating from the <a
moz-do-not-send="true"
href="http://192.168.1.0/24" target="_blank">192.168.1.0/24</a>
subnet would be served the local IP 192.168.1.2 but
all<br>
others would receive 63.3.19.155. One requirement
for any scheme is that it is backward compatible
(i.e. just a single<br>
IP address/FQDN will behave as it does now).<br>
<br>
This then needs to flow throughout OpenSimulator so
that at the crucial UDP points (login/entity
transfer) one will<br>
serve back the correct address in response to a
client request. I expect this data will have to be
stored in the<br>
Regions db table which might require an expansion of
the current varchar(64) type for serverIP.<br>
<br>
Trying to match this to all the HTTP parts where an
address is separately specified would be a massive
pain but<br>
hopefully is completely unnecessary, as one can give
FQDNs at those points which are resolved dynamically
(I think!).<br>
<br>
The usual practice for code submission is to create
a patch and then put it on the Mantis database in
"Patch Included"<br>
state, as described at [1]. It is then assessed by
a core developer(s) and included or feedback given
as appropriate.<br>
In this case, though, I would also like to see some
feature proposal doc [2] before a patch, if only to
see what the<br>
proposed config format is and catch any early
problems. Also, this is the kind of significant
feature where I think we<br>
would want to have see a contribution agreement,
which core and other developers have done. More
details at [3].<br>
<br>
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<br>
public. In fact, I'd much prefer to discuss issues
as they come up so that myself and other people on
this list can<br>
identify problems early and even point out if there
are basic issues with the idea of serving different
IP addresses for<br>
UDP to different clients based on their requesting
IP.<br>
<br>
[1] <a moz-do-not-send="true"
href="http://opensimulator.org/wiki/Submitting_code_to_OpenSim"
target="_blank">http://opensimulator.org/wiki/Submitting_code_to_OpenSim</a><br>
[2] <a moz-do-not-send="true"
href="http://opensimulator.org/wiki/Feature_Proposals"
target="_blank">http://opensimulator.org/wiki/Feature_Proposals</a><br>
[3] <a moz-do-not-send="true"
href="http://opensimulator.org/wiki/Contributions_Policy"
target="_blank">http://opensimulator.org/wiki/Contributions_Policy</a><br>
<br>
<br>
<br>
On 18/12/14 14:07, Michael Heilmann wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
Justin<br>
<br>
The inability to pass a FQDN to the client is
interesting, I did not see that.<br>
<br>
Doug and I discussed our level of interest in this
functionality, and your solution. I will begin
work to explore and<br>
implement your solution immediately. As I am not
a core developer, and in fact this would be my
first contribution to<br>
opensim, I may need some guidance on your normal
code submission practices. We (MOSES) have our
own git clone of<br>
opensim master on github that I will be working
out of.<br>
<br>
</blockquote>
<br>
</blockquote>
<br>
_______________________________________________<br>
Opensim-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:Opensim-dev@opensimulator.org"
target="_blank">Opensim-dev@opensimulator.org</a><br>
<a moz-do-not-send="true"
href="http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev"
target="_blank">http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev</a><br>
</blockquote>
<br>
_______________________________________________<br>
Opensim-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:Opensim-dev@opensimulator.org"
target="_blank">Opensim-dev@opensimulator.org</a><br>
<a moz-do-not-send="true"
href="http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev"
target="_blank">http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</body>
</html>