On 04/04/11 17:22, Fleep Tuque wrote:
Indeed, thanks to everyone for the help. We're investigating the possibility of a
"virtual NIC" sitting outside the
campus firewall since there doesn't appear to be any easier way to resolve the
issue, but I'm not sure yet how that will
work or if we'll get approval from the security dragons. ;)
Out of curiosity, is there a reason why the DNS resolution is done at the
server for the UDP region handshake instead of
sending the hostname to the client as seems to be done with the TCP traffic?
I'm guessing it can't be an easy thing to
change or someone probably would have done by now..
I'm not entirely sure - sometimes the reasons for these things get lost in the mists of time (often when people don't
document!). If nobody knows for sure then some experimentation might be in order.
Thanks again though, it's good to know how that bit actually works!
Thanks for the update and the contributions of everybody on this thread. I've clarified the "Internal IP address" line
at http://opensimulator.org/wiki/Configuration#Running_OpenSim_for_the_first_time
Sincerely,
- Chris/Fleep
Chris M. Collins (SL: Fleep Tuque)
Project Manager, UC Second Life
Second Life Ambassador, Ohio Learning Network
UCit Instructional & Research Computing
University of Cincinnati
406E Zimmer Hall
PO Box 210088
Cincinnati, OH 45221-0088
(513)556-3018
[email protected] <mailto:[email protected]>
UC Second Life: http://homepages.uc.edu/secondlife
OLN Second Life: http://www.oln.org/emerging_technologies/emtech.php
On Fri, Apr 1, 2011 at 9:40 PM, Justin Clark-Casey <[email protected]
<mailto:[email protected]>> wrote:
Thanks for the info Simon, that's cleared that up for me. And thanks to
the others contributing to this thread.
I think that a utility to test a connection and provide an explicit
diagnosis (rather than the clues provided by the
client just hanging in various places) would be rather nice to have.
On 01/04/11 12:59, Simon Slavin wrote:
On 1 Apr 2011, at 12:43am, Justin Clark-Casey wrote:
Some people on Stack Overflow think that IPAddress.Any means listen
on all NICs
(http://stackoverflow.com/questions/1777629/how-to-listen-on-multiple-ip-addresses).
But my reading of the
MS SDK reference above means that it only binds to one. Anybody
able to comment on this?
Stack Overflow is right. My reading of that SDK page is that it's
wrong, and should be corrected, but other MS
documentation is clearer on what '::Any' means, for example
http://msdn.microsoft.com/en-us/library/system.net.ipaddress.any.aspx
Returning to the standards, IP address 0.0.0.0 is reserved for specific
purposes for both sending and receiving.
It's called the 'anonymous' address (for historical reasons) or the
'broadcast' address (for current reasons).
If a computer SENDS a packet to 0.0.0.0 then it is multibroadcasting:
sending one message to every computer that
can hear it. This is done most often to announce the (un)availability
of a service, for instance that a printer
service has come online. Sending to address 0.0.0.0 is done by, for
example, DHCP and zeroconf (what Apple
calls 'Bonjour'). Things like routers are usually set up to drop
packets SENT to 0.0.0.0 so that you don't
announce to the entire world what address your printer can be found on.
When a computer LISTENS to the network interface bound to 0.0.0.0 then
it is telling its TCP stack that it
doesn't care which network interface a message comes in on, it wants it
anyway. Almost every Internet
application does this, especially now many have both Ethernet sockets
and WiFi capabilities: an app doesn't care
what its user is using right now, it just wants to 'use the internet'.
Under normal circumstances the only
programs which /don't/ listen on 0.0.0.0 are techie programs like
network utilities, or a web server on a
gateway computer which needs to present a web site to internal users
and make sure it isn't available to
external users.
I tried to find an RFC to point to as reference but nothing seems to
spell this out. The nearest thing i could
find was RFC950.
Simon.
_______________________________________________
Opensim-users mailing list
[email protected] <mailto:[email protected]>
https://lists.berlios.de/mailman/listinfo/opensim-users
--
Justin Clark-Casey (justincc)
http://justincc.org/blog
http://twitter.com/justincc
_______________________________________________
Opensim-users mailing list
[email protected] <mailto:[email protected]>
https://lists.berlios.de/mailman/listinfo/opensim-users
_______________________________________________
Opensim-users mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-users
--
Justin Clark-Casey (justincc)
http://justincc.org/blog
http://twitter.com/justincc
_______________________________________________
Opensim-users mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-users
