[Opensim-dev] external host name

[Melanie]

I believe it happens in RegionUp code. Not certain, but maybe that 
will break neighbors.

Needs looking at.

Melanie

Stefan Andersson wrote:
>  
>> Then we should resolve all hostname fields int he LL stack, and feed > the client IP addresses. 
>  
> +1 and a pleading 'just do it' from the man responsible for the mess in the first place... ;)
>  
>> That should still allow us flexible handling.
>  
> But use DnsEndPoints in the core. I don't know if the local binding interface ('internal_ip') could/should be an DnsEndPoint as well, but I believe it should (so it would really be 'bind_to_host_interface')
>  
> (In some corporate settings, you use the DNS to resolve the internal/external IP - using DnsEndPoint for internal_ip would let you specify the same host for internal and external) - it's also a step towards IPv6 compliance.
>> Most importantly, we should not string-compare hostss. Not if (host > a == host b) but if (resolve(host a) == resolve(host b))
> Do we ever actually do that? Even after resolving, they might not match. If we compare hosts, I believe that's an indication we might be doing something wrong somewhere.
>  > Melanie
> /Stefan
>> > Diva Canto wrote:> > I agree. The problem is that the client doesn't understand that, and > > this causes problems with caps urls.> > > > Melanie wrote:> >> A host name can also be an IP address. IP addresses and hostnames > >> are interchangable and we can't assume DNS presence. So, the field > >> should accept a name or IP, and resolve names, like almost > >> everything else on the internet does.> >>> >> Melanie> >>> >>> >> Cristina Videira Lopes wrote:> >> > >>> The thing is that this can potentially create a RegionInfo data > >>> structure with> >>> nRegionInfo.ExternalHostName = regionData.IPADDR;> >>>> >>> This is inconsistent with certain queries on the Grid server, like "give > >>> me all my neighbors" which may send host names.> >>>> >>> So, back to the point: someone needs to decide what is it that > >>> RegionInfo.ExternalHostName is supposed to hold.> >>>> >>> Teravus Ovares wrote:> >>> > >>>> RegionUpData is my fault, and spawned from compatibility issues wi
th> >>>> .NET remoting and Mono remoting with complex types. It is only used> >>>> to notify a neighbor region that 'this region is up'> >>>>> >>>> Best Regards> >>>>> >>>> Teravus> >>>>> >>>> On 12/11/08, Cristina Videira Lopes <lopes at ics.uci.edu> wrote:> >>>> > >>>> > >>>>> Things are very messy right now. You can search for "sim_ip", for example,> >>>>> which is used in chatting with the grid server, and where it is being> >>>>> converted to an IP address in about half of the cases.> >>>>>> >>>>> To compensate, and before I noticed this inconsistency, Homer introduced> >>>>> another field called "sim_host", so not to mess with what was already there,> >>>>> that is supposed to carry the external host name, but this only works up to> >>>>> the point in which RegionInfo data structures are created. At that point, we> >>>>> need to decide what to place in m_externalHostName, sim_ip or sim_host.> >>>>> Which means changes in OGS1.> >>>>>> >>>>> I also noticed that there is yet
 another data structure called RegionUpData> >>>>> that uses IP addresses.> >>>>>> >>>>> So, messy. Someone should decide what this field is supposed to be, and make> >>>>> it a rule.> >>>>>> >>>>> Charles Krinke wrote:> >>>>>> >>>>> Dear Diva:> >>>>>> >>>>> You have a very good point and I would support harmonizing to one notion> >>>>> even at the expense of breaking some things for a while.> >>>>>> >>>>> In fact, if someone can identify what some of those things are, or come up> >>>>> with a couple of search strings or grep expressions, I would like to look at> >>>>> the anomalies myself.> >>>>>> >>>>> +1 on external_host_name> >>>>>> >>>>> Charles> >>>>>> >>>>> ________________________________> >>>>>> >>>>>> >>>>> From: Cristina Videira Lopes <lopes at ics.uci.edu>> >>>>> To: opensim-dev at lists.berlios.de> >>>>> Sent: Thursday, December 11, 2008 2:42:05 PM> >>>>> Subject: [Opensim-dev] external host name> >>>>>> >>>>> It turns out that a lot of problems with CAPs have to do wi
th> >>>>> inconsistencies surrounding the URL of the seed cap. Specifically, in> >>>>> some cases we're producing URLs with hostnames, other times we're> >>>>> producing URLs with IP addresses, for example:> >>>>>> >>>>> http://ucigrid03.nacs.uci.edu:9000/CAPS/4cfc94fa-09be-409b-b136-cda2cdde0000/> >>>>> vs.> >>>>> MailScanner has detected a possible fraud attempt from "128.200.71.43:9000"> >>>>> claiming to be MailScanner warning: numerical links are often malicious:> >>>>> http://128.200.71.43:9000/CAPS/4cfc94fa-09be-409b-b136-cda2cdde0000/> >>>>>> >>>>> The client is not smart enough to test if this is the same host, it> >>>>> assumes it isn't, so it decides someone's trying to game it.> >>>>>> >>>>> The inconsistencies are all over the code in OpenSim, and they pertain> >>>>> to the use of ExternalHostName in several data s! tructures. In some> >>>>> cases, an explicit conversion to IP addresses is made.> >>>>>> >>>>> We should converge to one single thing. And I believe 
that thing should> >>>>> be whatever it is given in external_host_name config. Is this right?> >>>>> However, I am a bit afraid this is going to break 17 different things...> >>>>>> >>>>> Crista> >>>>>> >>>>> _______________________________________________> >>>>> Opensim-dev mailing list> >>>>> Opensim-dev at lists.berlios.de> >>>>> https://lists.berlios.de/mailman/listinfo/opensim-dev> >>>>> ________________________________> >>>>>> >>>>> > >>>>> > >>>> _______________________________________________> >>>> Opensim-dev> >>>> > >>>> > >>>>> mailing> >>>>> list> >>>>> > >>>>> > >>>> Opensim-dev at lists.berlios.de> >>>> https://lists.berlios.de/mailman/listinfo/opensim-dev> >>>> > >>>> > >>>>> _______________________________________________> >>>>> Opensim-dev mailing list> >>>>> Opensim-dev at lists.berlios.de> >>>>> https://lists.berlios.de/mailman/listinfo/opensim-dev> >>>>>> >>>>>> >>>>> > >>>>> > >>>> _______________________________________________> >>>> Opensim-dev mailing list> >>>
> Opensim-dev at lists.berlios.de> >>>> https://lists.berlios.de/mailman/listinfo/opensim-dev> >>>> > >>>> > >>>> >>>> >>> ------------------------------------------------------------------------> >>>> >>> _______________________________________________> >>> Opensim-dev mailing list> >>> Opensim-dev at lists.berlios.de> >>> https://lists.berlios.de/mailman/listinfo/opensim-dev> >>> > >> _______________________________________________> >> Opensim-dev mailing list> >> Opensim-dev at lists.berlios.de> >> https://lists.berlios.de/mailman/listinfo/opensim-dev> >>> >> > > > > > > > > > > ------------------------------------------------------------------------> > > > _______________________________________________> > Opensim-dev mailing list> > Opensim-dev at lists.berlios.de> > https://lists.berlios.de/mailman/listinfo/opensim-dev> _______________________________________________> Opensim-dev mailing list> Opensim-dev at lists.berlios.de> https://lists.berlios.de/mailman/listinfo/opensim-dev
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev