Quote:
Ok, finally got control back. Looks like fetching the Winsocks info was a bit slow. I'm sure it's Windoze fault.
Looking up IP addresses involves DNS - I warn on the functions page for GetHostName that this might be slow.
Quote:
So: Why not just have a global 'validated_ip' variable somewhere which is set to our ip after connection when this information is available to us?
Hmm - the area of IP addresses, NAT, port forwarding and private IPs is quite muddy. Here is what happens, I believe.
First, because there is a shortage of IP addresses (the 4-byte IP address range is running out, partly because early allocations were very inefficient, in that some people got allocated large blocks of addresses that they don't necessarily use), a lot of places (schools, companies, ISPs) are now using NAT - Network Address Translation - where a local, or "private" IP address on their internal network is rewritten, by the router, as it is sent to the "real" Internet.
For example, John at School A might have address 10.0.0.3 (one of the private addresses which will never appear on the real Internet) and Mary at School B might also have the exact same address: 10.0.0.3.
To talk to the Internet they go through their routers, and the NAT part rewrites the packets, inserting their own (the router's) IP address, and changing the port number to one of the router's choosing. Then when the reply comes back, by inspecting the port number, and consulting an internal table, the (reply) packet can go back to the originating PC.
For instance, of School A's router was IP address 1.2.3.4 and School B's router was 5.6.7.8, then the packet flow would look like this:
10.0.0.3 -->(router) --> 1.2.3.4 --> (internet) --> 5.6.7.8 --> (router) --> 10.0.0.3
Now you can see that both PCs (John and Mary's) are set to IP address 10.0.0.3, and that is what any tools will tell them that their address is. However clearly John cannot set up a call (a chat call, say) to 10.0.0.3 because that would simply go to himself.
This is where "port forwarding" comes into it. The administrator for School B (router 5.6.7.8) might configure "port forwarding" - in fact s/he probably would if there was a web server on the internal network somewhere that was supposed to be accessible to the Internet.
How this works is that, if configured, you might send a call to 5.6.7.8 port 5000. The router would see that incoming call, and look at its internal rules. They might say, "incoming calls to port 5000 are to be forwarded to 10.0.0.3 port 4000". Then Mary would get the incoming call to port 4000 at her PC.
Say that had been done, Mary could look at the chat message and see that it had come from IP 1.2.3.4. However she could still not make a call back to 1.2.3.4 unless the router there was similarly configured to direct calls back to John's PC.
The upshot is, there is no easy way of knowing the address if you are behind NAT, and even if you find out (for instance, it might very well be your router address) that won't help you unless port forwarding is configured to send the packets on to you anyway. If you have gone to the trouble of doing that you probably already know the IP address and port, so you don't really need MUSHclient to find it for you automatically.
The simple solution is for everyone to call someone who is not behind NAT. eg. if Peter has a "real" IP address then both John and Mary can call Peter, however neither Peter nor John can call Mary, nor Peter nor Mary can call John.
|
![[Next page]](/images/thin_next.gif){kind=small}
![[Go to top]](/images/gototop.gif){kind=small}
top