No subject


Sat Apr 19 01:31:08 UTC 2014


leport&nbsp=3Bpackets (and possibly some others=2C like IM?)&nbsp=3Bwhere t=
he viewer can only accept IP. That is why it is implicitly resolved in some=
 places. (Or rather=2C that's the rationale for why those places need it)<B=
R>
&nbsp=3B<BR>
The remoting issue=2C I don't know what that actually means=2C but remoting=
 should be resolved thru hostname as well.<BR>
&nbsp=3B<BR>
It pains me to admit that I'm probably the source of all this confusion=2C =
as I=2C way back then=2C did the DNS resolve as a quick fix to fix some net=
working issues - but at that time I was not aware of the DnsEndPoint class.=
<BR>
&nbsp=3B<BR>
So=2C really=2C the endpoint info should be&nbsp=3Bstored in&nbsp=3B_DnsEnd=
Point_ not _IPEndpoint_ all thru core.<BR>
&nbsp=3B<BR>
and<BR>
&nbsp=3B<BR>
Unless anybody knows of a reason not to=2C I suggest moving any&nbsp=3BIP r=
esolving into the&nbsp=3BLL client stack=2C as close to the actual needed c=
onversion as possible=2C and let core&nbsp=3Buse hostnames=2C via DnsEndPoi=
nt=2C&nbsp=3Ball over.<BR>
<BR>Best regards=2C<BR>Stefan Andersson<BR>Tribal Media AB<BR>&nbsp=3B<BR>J=
oin the&nbsp=3B3d web revolution : <A href=3D"http://tribalnet.se/">http://=
tribalnet.se/</A><BR>&nbsp=3B<BR><BR><BR><BR><BR><BR>

<HR id=3DstopSpelling>
<BR>
Date: Thu=2C 11 Dec 2008 17:38:04 -0800<BR>From: lopes at ics.uci.edu<BR>To: o=
pensim-dev at lists.berlios.de<BR>Subject: Re: [Opensim-dev] external host nam=
e<BR><BR>The thing is that this can potentially create a RegionInfo data st=
ructure with <BR>&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&n=
bsp=3B&nbsp=3B&nbsp=3B nRegionInfo.ExternalHostName =3D regionData.IPADDR=
=3B<BR><BR>This is inconsistent with certain queries on the Grid server=2C =
like "give me all my neighbors" which may send host names.<BR><BR>So=2C bac=
k to the point: someone needs to decide what is it that RegionInfo.External=
HostName&nbsp=3B is supposed to hold.<BR><BR>Teravus Ovares wrote: <BR>
<BLOCKQUOTE cite=3Dmid:34cc66250812111718j3b5b1092w90dbb7d45131f5c8 at mail.gm=
ail.com><PRE>RegionUpData is my fault=2C and spawned from compatibility iss=
ues 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=2C Cristina Videira Lopes <A class=3DEC_moz-txt-link-rfc2396E h=
ref=3D"mailto:lopes at ics.uci.edu">&lt=3Blopes at ics.uci.edu&gt=3B</A> wrote:
  </PRE>
<BLOCKQUOTE><PRE>Things are very messy right now. You can search for "sim_i=
p"=2C for example=2C
which is used in chatting with the grid server=2C and where it is being
converted to an IP address in about half of the cases.

To compensate=2C and before I noticed this inconsistency=2C Homer introduce=
d
another field called "sim_host"=2C so not to mess with what was already the=
re=2C
that is supposed to carry the external host name=2C but this only works up =
to
the point in which RegionInfo data structures are created. At that point=2C=
 we
need to decide what to place in m_externalHostName=2C 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=2C messy. Someone should decide what this field is supposed to be=2C 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=2C if someone can identify what some of those things are=2C or come=
 up
with a couple of search strings or grep expressions=2C I would like to look=
 at
the anomalies myself.

+1 on external_host_name

Charles

________________________________


From: Cristina Videira Lopes <A class=3DEC_moz-txt-link-rfc2396E href=3D"ma=
ilto:lopes at ics.uci.edu">&lt=3Blopes at ics.uci.edu&gt=3B</A>
To: <A class=3DEC_moz-txt-link-abbreviated href=3D"mailto:opensim-dev at lists=
.berlios.de">opensim-dev at lists.berlios.de</A>
Sent: Thursday=2C December 11=2C 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=2C in
some cases we're producing URLs with hostnames=2C other times we're
producing URLs with IP addresses=2C for example:

<A class=3DEC_moz-txt-link-freetext href=3D"http://ucigrid03.nacs.uci.edu:9=
000/CAPS/4cfc94fa-09be-409b-b136-cda2cdde0000/">http://ucigrid03.nacs.uci.e=
du:9000/CAPS/4cfc94fa-09be-409b-b136-cda2cdde0000/</A>
vs.
MailScanner has detected a possible fraud attempt from "128.200.71.43:9000"
claiming to be MailScanner warning: numerical links are often malicious:
<A class=3DEC_moz-txt-link-freetext href=3D"http://128.200.71.43:9000/CAPS/=
4cfc94fa-09be-409b-b136-cda2cdde0000/"><FONT color=3Dred><B>MailScanner war=
ning: numerical links are often malicious:</B></FONT> http://128.200.71.43:=
9000/CAPS/4cfc94fa-09be-409b-b136-cda2cdde0000/</A>

The client is not smart enough to test if this is the same host=2C it
assumes it isn't=2C so it decides someone's trying to game it.

The inconsistencies are all over the code in OpenSim=2C and they pertain
to the use of ExternalHostName in several data s! tructures. In some
cases=2C 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=2C I am a bit afraid this is going to break 17 different things...

Crista

_______________________________________________
Opensim-dev mailing list
<A class=3DEC_moz-txt-link-abbreviated href=3D"mailto:Opensim-dev at lists.ber=
lios.de">Opensim-dev at lists.berlios.de</A>
<A class=3DEC_moz-txt-link-freetext href=3D"https://lists.berlios.de/mailma=
n/listinfo/opensim-dev">https://lists.berlios.de/mailman/listinfo/opensim-d=
ev</A>
________________________________

    </PRE></BLOCKQUOTE><PRE>_______________________________________________
Opensim-dev
  </PRE>
<BLOCKQUOTE><PRE>mailing
list
    </PRE></BLOCKQUOTE><PRE><A class=3DEC_moz-txt-link-abbreviated href=3D"=
mailto:Opensim-dev at lists.berlios.de">Opensim-dev at lists.berlios.de</A>
<A class=3DEC_moz-txt-link-freetext href=3D"https://lists.berlios.de/mailma=
n/listinfo/opensim-dev">https://lists.berlios.de/mailman/listinfo/opensim-d=
ev</A>
  </PRE>
<BLOCKQUOTE><PRE>_______________________________________________
Opensim-dev mailing list
<A class=3DEC_moz-txt-link-abbreviated href=3D"mailto:Opensim-dev at lists.ber=
lios.de">Opensim-dev at lists.berlios.de</A>
<A class=3DEC_moz-txt-link-freetext href=3D"https://lists.berlios.de/mailma=
n/listinfo/opensim-dev">https://lists.berlios.de/mailman/listinfo/opensim-d=
ev</A>


    </PRE></BLOCKQUOTE><PRE>_______________________________________________
Opensim-dev mailing list
<A class=3DEC_moz-txt-link-abbreviated href=3D"mailto:Opensim-dev at lists.ber=
lios.de">Opensim-dev at lists.berlios.de</A>
<A class=3DEC_moz-txt-link-freetext href=3D"https://lists.berlios.de/mailma=
n/listinfo/opensim-dev">https://lists.berlios.de/mailman/listinfo/opensim-d=
ev</A>
  </PRE></BLOCKQUOTE><BR></body>
</html>=

--_c138cece-0090-4e59-bc4e-3ff653ac7430_--



More information about the Opensim-dev mailing list