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