[Opensim-dev] external host name

Fri Dec 12 07:57:38 UTC 2008

and it will break any failover system too.

On Fri, Dec 12, 2008 at 8:49 AM, Hurliman, John <john.hurliman at intel.com>wrote:

> Resolving all hostnames to IP addresses would break virtual hosting, a very
> common practice. I don't understand your earlier argument: we can't assume
> DNS presence*, so we should use DNS to resolve all hostnames? Can you
> clarify that?
>
> *If you're building a virtual world in an environment where there is no DNS
> service, why would you put a hostname in your config file?
>
> John
>
> > -----Original Message-----
> > From: opensim-dev-bounces at lists.berlios.de [mailto:opensim-dev-
> > bounces at lists.berlios.de] On Behalf Of Melanie
> > Sent: Thursday, December 11, 2008 9:31 PM
> > To: opensim-dev at lists.berlios.de
> > Subject: Re: [Opensim-dev] external host name
> >
> > Then we should resolve all hostname fields int he LL stack, and feed
> > the client IP addresses. That should still allow us flexible handling.
> > Most importantly, we should not string-compare hostss. Not if (host a
> > == host b) but if (resolve(host a) == resolve(host b))
> >
> > Melanie
> >
> >
> > 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
> >>>>> with .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 with
> >>>>>> 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- cd
> >>>>>> a2cdde0000/ 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- cda2cdde000
> >>>>>> 0/
> >>>>>>
> >>>>>> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20081212/12928642/attachment-0001.html>