ok I need some experianced directions (virtual lans)
 

So I have this system with lots of peers and a master server. There are no problems with connections to the master server but when one peer connects to another peer, he can't unless the peer being connected to has the specified port forwarded in his router. They can also connect through 3rd party virtual lan programs like Hamachi using their vlan IPs but well... cant tell everyone to get another program. So I would really appreciate a few directions on how to overcome this problem.

And how does virtual lan products like hamachi work without port forwarding where normal TCP/UDP/IP fails?

Lost of thanks in advance

Re: ok I need some experianced directions (virtual lans)
 

There are several methods.

UPnP is supported and enabled by default on many home routers these days. Applications can automatically request port forwards. I've seen this used by Xbox Live and various bittorrent clients among other things. It's a solution that may "just work" -- it certainly doesn't hurt to try -- but you'd want to include an option to disable it so that your users can forward ports manually.

I can't remember if Hamachi attempts to use UPnP. I do know that it's strongest point is in its udp hole punching algorithm. It works very reliably in my experience, even behind corporate firewalls and the like. But it's certainly not the first or only program to function in this way.

NAT is an ugly but necessary hack. Typically (but not always) one is multiplexing a single public address for use by many private ones. This is done by rewriting packet headers on the fly. Doing so requires maintaining a certain amount of state. Client A sends a packet from port 4567 (random available port chosen by OS) to google.com on port 80. The router creates a mapping. The packet is rewriten such that the source is the public address on port 1234. When the response comes back from google on port 1234, the router knows to change the destination to client A on port 4567. 'Port forwarding' is just setting up a static mapping, so that external hosts can initiate communication.

UDP hole punching is a hack of a hack. Various routers differ on how exactly they maintain state for NAT purposes. In the previous example, what if client X sends a packet to port 1234? Does it still go to client A? Or does the source IP have to match as well? How does the router select ports? If it uses 1234 for a mapping, will 1235 be next? With use of a mediator and a little guesswork, one can often times successfully establish communication between two hosts that are each behind some form of NAT by having them simultaneously trying to contact each other.

Poke around on wikipedia and find technical docs for protocols incl. UPnP, STUN, and ICE.

Looking purely at return on investment, I'd say that you should try UPnP (I think theres a library included on most recent versions of windows) and tell your users to forward manually if it fails.

Re: ok I need some experianced directions (virtual lans)
 

Thanks again. I'm looking into UPnP.

I have another network related question but its not exactly in the same area as above. With this system, RTT size between the peers is not a big issue but it's value consistency is. If a packet comes early, its buffered for when the data is needed. There is no problem there. However, if it comes late and the buffer is empty, its network section has to block and wait for the packet or its sequel/retransmission. Some users tend to use an option to allow for greater RTT error margin which just adds to their response delay and it already implements CPU heavy algorithms to mask that response delay so the less the better. Since I can't control the state of the network, I wanted to know if I am doing everything right on the end points: I am using UDP/non blocking sockets. I've modified the system reception buffer size to 32 kb but most of my packets (app layer) rarely exceed 30-40 bytes. It's also a single threaded implementation. I am also taking the average of 5-10 RTT values to determine this critical RTT point.

Also, how would this compare to a multithreaded blocking sockets implementation? Would I be able to reduce packet loss rate and increase consistency? My understanding of blocking vs non-blocking socket is that the former waits till what is being sent is sent and then sends vs adds to system's send queue and at the end of the day both gets sent at the same time.

Thanks