fix linker error and update README

.gitignore

+!.gitignore
+*.o
+.DS_Store
+*.swp

Makefile

@@ -4,7 +4,7 @@ CFLAGS  = -g -Wall
 all:  nat_traversal
 
 nat_traversal:  main.o nat_traversal.o nat_type.o 
-	$(CC) $(CFLAGS) -o nat_traversal main.o nat_traversal.o nat_type.o
+	$(CC) $(CFLAGS) -o nat_traversal main.o nat_traversal.o nat_type.o -pthread
 
 main.o:  main.c
 	$(CC) $(CFLAGS) -c main.c

README.md

@@ -3,3 +3,4 @@ A implementation of this paper: [A New Method for Symmetric NAT Traversal in UDP
 According to [RFC 3489](http://tools.ietf.org/html/rfc3478), a symmetric NAT is one where all requests from the same internal IP address and port, to a specific destination IP address and port, are mapped to the same external IP address and
 port. If the same host sends a packet with the same source address and port, but to a different destination, a different mapping is used. Furthermore, only the external host that receives a packet can send a UDP packet back to the internal host.  
 So, if we know the port allocation rule of the Symmetric NAT, we can traverse Symmetric NAT. This paper proposes a new method for traversing Symmetric NAT which is based on port prediction and limited TTL values.  
+It's just a experience project, I just wanna test whether UDP punching is possible if both nodes are behind symmetric NAT. To run it, you should run `punch_server.go` in a machine with public IP, so both nodes can connect to it to exchange info(just node info, not to relay like [RFC 6062](https://tools.ietf.org/html/rfc6062)), then run `nat_traversal [-s punch server] [-d id]` on both nodes, you can also specify other arguments, such as, STUN server by `-H` option, source IP by `-i`, source port by `-p`.
\ No newline at end of file