No subject
Sat Apr 19 02:14:48 UTC 2014
leport =3Bpackets (and possibly some others=2C like IM?) =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>
 =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>
 =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>
 =3B<BR>
So=2C really=2C the endpoint info should be =3Bstored in =3B_DnsEnd=
Point_ not _IPEndpoint_ all thru core.<BR>
 =3B<BR>
and<BR>
 =3B<BR>
Unless anybody knows of a reason not to=2C I suggest moving any =3BIP r=
esolving into the =3BLL client stack=2C as close to the actual needed c=
onversion as possible=2C and let core =3Buse hostnames=2C via DnsEndPoi=
nt=2C =3Ball over.<BR>
<BR>Best regards=2C<BR>Stefan Andersson<BR>Tribal Media AB<BR> =3B<BR>J=
oin the =3B3d web revolution : <A href=3D"http://tribalnet.se/">http://=
tribalnet.se/</A><BR> =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> =3B =3B =3B =3B =3B =3B =3B&n=
bsp=3B =3B =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 =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"><=3Blopes at ics.uci.edu>=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"><=3Blopes at ics.uci.edu>=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