Current version 2.0 (26 Sep 12)
Status:
5 stations,
2 listeners
Streamer p2p radio
This page was originally going to be all about how to configure NAT in a
router so that Streamer worked through NAT at all, but since now it almost never
fails to make direct connections between NAT listeners with no meddling, it isn't so neccessarry..
so, I will take a few moments to explain what all of that mess is about for your
entertainment if nothing else... :-)
What LAN's and NAT actually do:
Imagine you have 2 pc's, both with normal direct connections to the net. They each have an IP (Internet Protocol)
address, which is really just a number. Each pc on the net has a different IP.
These IP's are rather like the address of your house, and the messages PC's send to each other are rather like letters
being posted into the net. When one PC sends a message to another PC, it puts the IP address of the target
in the message, like writing the address on an envelope. It also puts it's own IP address in the message, so a reply
can be sent back. The message is then sent into the net, and hops from one net router to the next as it makes it's
way across the planet, eventually ending up at the target.
But, the number of possible IP addresses is limited, and we are running out of spare IP's, so a way was invented for
several PC's to share the same IP address. It is called Network Address Translation or NAT. In this
system a group of PC's are all connected together on a Local Area Network or LAN. This is like a
mini-internet. The PC's on it still have their own IP address, but these addresses are from a special range of numbers
just reserved for LAN's. They cannot be used on the real internet, and each seperate LAN can re-use the same IP's. All
the pc's on a single LAN can talk to each other using their LAN IP's, but some trickery needs to be done for them to
talk to PC's outside the LAN on the rest of the internet. This is where Network Address Translation comes in.
The LAN is connected to the rest of the net through a device that does the NAT-ing. When a LAN PC wants to send a
message to a PC on the outside net, it puts the target's non-LAN IP in the message, and puts it's own LAN IP as the
reply IP, then it
sends the message. The message passes through the NAT device, which replaces the 'reply' IP, which is a LAN IP, with the
real internet IP of the NAT (each NAT has one real world IP). The NAT makes it look like the message came from a PC with a normal net connection and
this normal net IP. All messages being sent from all the PC's on the LAN have their reply IP changed to this one IP that
belongs to the NAT. When the target PC sends a reply, it sends it back to this real internet IP belonging to the NAT,
it doesn't know it really came from a PC on a LAN. When the reply reaches the NAT, it 'remembers' which LAN PC sent the
original message, and replaces the 'to' address in the message (which is the NAT IP) with the LAN IP of the original
sender. Then it posts it into the LAN, and it reaches the LAN PC.
How does the NAT remember which LAN PC sent the original message?. It could remember the to/from IP's in all the
messages, but there are technical reasons why it cannot just do this. With every net message, as well as their being a
pair of to/from IP's, there are also a pair of to/from ports. These are like an extension to the IP, but all the
ports for a particular IP belong to the same PC. They are there so a PC can make several seperate connections to another
PC. Each connection will be sending from a different port, to a predefined port on the target, and getting replies back
to that port. It makes sorting the messages much simpler. Each program on a PC will send messages from and listen to
replies on a seperate port. For example, all web servers listen to incoming messages on port 80, and all web browsers send
requests for pages and images to that port. The port they send 'from' is random, and each request comes from a seperate port.
This allows a web browser to request several things all at the same time, with the replies not getting mixed up.
What NAT does is to replace the 'from' port in outgoing messages with a new one it chooses, and then remembers which LAN PC 'owns'
that port. When a reply arrives from outside, it replaces the 'to' port with the one the original LAN PC used when it sent
the message. Then it sends it back onto the LAN and it arrives at the original sender on the same port the sender used. The
NAT ensures that each port it assigns is only used for one connection at any one time.
So all the LAN PC's can now make connections to PC's on the outside net, all sharing the same IP. But there is a
problem, and it's a BIG one... What happens when a PC outside the LAN wants to make a connection to a PC inside the
LAN?... Well it can't!. It may know the LAN IP of the target, but you can't put LAN IP's in messages sent over the net,
because they just vanish. It may know the IP of the NAT, but the NAT won't know the LAN IP of the target to forward the
message to, so the NAT drops the message. If the sender knew a port that the NAT had recently assigned to the LAN PC,
then the
message may get through (unless the NAT is 'strict' and also checks the 'from' IP in the message). BUT there are 65,000
or so ports to choose from. The sender would have to send messages to each possible port, and even then the NAT may not
have assigned ANY ports to the LAN PC so the message would vanish. If it had assigned a port, it may belong to the wrong
program on the LAN PC, and the message would not just get lost, but could also confuse the other program.
This is the big problem for p2p systems, the 'firewalled/nat-ted' host effect. 'peer-to-peer' doesn't work very well
if the peers cannot connect to each other.