server will find the external IP address of each client, and tell both clients to connect to that address at the same time. If that fails, each client will attempt to estimate the ports used by the other. If that fails, the process repeats once again, in case later port estimation opened a prior port ...
With some poor quality or homemade routers, it is possible that NAT punchthrough will not work. For example, a router that picks a new random port for each outgoing connection, and will only allow incoming connections to this port, will never work. This happens about 5% of the time. To handle this case, RakNet provides the UDPProxy system. Essentially, it uses a server that you run to route messages between the source and destination client transparently. This even works to route datagrams from games not using RakNet (though you need RakNet to setup the forwarding). The combination of NATPunchthrough and UDPProxy should enable any system to connect to any other system with a 100% success rate, provided you are willing to host enough proxy servers to forward all the traffic.
RPC... supports return values by blocking in the Receive() call until a message is returned or until a timeout elapses.
The NetworkIDObject class provides the ability for systems to refer to common objects and is used by object member remote function calls. It is a fairly simple system that has the server assign a number to objects as they are created. When a client creates an object, it is responsible for sending this event to the server, getting the number to use when the object is created on the server in turn, and then assigning this number to the object. This way systems can refer to objects on multiple systems which would otherwise be impossible since pointer addresses would probably not be the same.... The disadvantage of this architecture is that it relies on a single system being present to assign network IDs. This can be addressed by having NetworkIDs be a SystemAddress / NetworkID pair instead of a simple number.
The autopatcher is a class that manages the copying of missing or changed files between two or more systems ... Autopatchers are used in all online only games and most AAA commercial games.
* http://www.hawksoft.com/hawknl/ (litsents: LGPL). Mingi jutt UDP ja TCP ühenduste automatiseerimisest ja UDP probleemide lahendamisest (One of my early ideas behind HawkNL (NL) was to not only provide a low level porting layer for HawkNLU, but also hide most, if not all, of the differences of UDP and TCP. I wanted HawkNLU to be able to use either TCP or UDP, and to use the same code for both... But UDP connections do not work as well as they should... Since UDP is a connectionless protocol, NL must provide the code to emulate TCP connections... Some good points about this algorithm are that it is simple, it helps to eliminate forged packets since the sockets are connected and will only accept packets from the connected remote address, and it works well on a LAN. Some bad points are that the server opens up a new port with each new socket, so firewalls and NAT cause problems. This is a major difference from TCP, which uses the same server port for all the accepted connections. ... Finally, there is no way to gracefully close the connection when the other side closes.): http://www.hawksoft.com/articles/hawknl/nludpconnections.shtml
* http://linide.sourceforge.net/nat-traverse/ - UDP NAT traverse package using simple Perl script (Comment:This ought to work very well since NAT implementations need to have a relatively long timeout - 30 minutes is the standard on some NATs - since UDP is stateless.NB:nat-traverse does not work with gateways which change the port numbers. This is a fundamental problem of nat-traverse's design, as the changed port numbers are (in general) not predictable.)
* http://enet.cubik.org/ ja http://enet.bespin.org/ - provides a relatively thin, simple and robust network communication layer on top of UDP (User Datagram Protocol). The primary feature it provides is optional reliable, in-order delivery of packets.
... Cube necessitated low latency communcation with data sent out very frequently, so TCP was an unsuitable choice due to its high latency and stream orientation. UDP, however, lacks many sometimes necessary features from TCP such as reliability, sequencing, unrestricted packet sizes, and connection management. ... TCP lacks multiple streams of communication without resorting to opening many sockets and complicates delineation of packets due to its buffering behavior. UDP lacks sequencing, connection management, management of bandwidth resources, and imposes limitations on the size of packets. ... ENet thus attempts to address these issues and provide a single, uniform protocol layered over UDP to the developer with the best features of UDP and TCP as well as some useful features neither provide. ENet works on Windows and any other Unix or Unix-like platform providing a BSD sockets interface. MIT-style license.
* veel mingi libra: http://www.projectdarkstar.com/ - GPL from Sun for the server portion and Apache for the client. To sum up its 100% free with no restritions. It manages persistance as well something of a pain. The server side is java only but the client libraries are available in Java and C++ (http://forums.sagamedev.com/topic.aspx?topicid=113).
* http://nutss.gforge.cis.cornell.edu/ - network architecture that uses signaling before establishing the data channel. The goal is to enable middle boxes like firewalls and NATs ... While the data channel is a direct TCP/IP connection between two IP addresses and ports, the signaling is through SIP, which uses stable endpoint identifiers for routing.
... Most NAT firewalls keep a time-out for these connections; these time-outs vary from 10 minutes (on some really broken residential firewalls) to several hours. As long as some traffic flows within the time-out, the connection is remembered and future traffic will keep working. ...
... This server can also conveniently act as a gatekeeper, login server, and authenticator for anyone wanting to participate in the network ...
Probleem:the NAT firewall may, if it's paranoid, keep a list of addresses that are allowed to send data in. - see on siis probleem, kui mõlemad masinad on paranoid NAT taga. Lahendus:if the firewalls keep lists of allowed IP addresses, then some of the early packets will be dropped, until each side of the connection has sent outgoing traffic to the other side, and thus put that side on its "white list".
Veel:No doubt, some firewall set-ups, and some rather broken NAT boxes will not allow this punch-through to happen. There are work-around, such as searching for ports in the range nearby to the server connection port, because that's where the NAT box is likely to allocate the UDP port for the "unused" peer connection.
ja
I know that some mad people are actually doing punch-through without introducers, basically by using heuristics and the "try many ports" approach.
Veel üks probleem:Some firewalls will reject a packet they're not expecting, and then keep rejecting the packet even if they would later want to expect that. This leads to a race when starting to negotiate the connection. To fix that, the two sides should first send a packet with a short TTL (typically, 2) to "open" their firewalls, and when both sides have done that, start communicating with each other for real. This ready-ness can either be brokered using extra negotiation through the introducer, or it can be done using some reasonable time-outs.
* http://www.brynosaurus.com/pub/net/p2pnat/ - statistics on how common NAT traversal connectivity actually is. t also talks about a similar TCP punch-through technique, which is less supported than UDP, but still surprisingly well supported.
Users connect to the address server first, and send it the IP address they think they have; the server notes both that address and the address it sees in the UDP header. The server then sends both addresses to the other peers. ...
To open up peer-to-peer connections, all old peers send a UDP packet to the new peer, and the new peer sends a UDP packet to each of the old peers. Since nobody knows at first whether they are behind the same NAT, the first packet is always sent to both the public and the private address.
Once the first reply comes back from each peer, the sender knows which return address to use, and can stop sending to both addresses.
* http://www.cynicalstuff.com/nat-traversal-solutions-for-independent-developers - NAT traversal (I searched a bit for NAT traversal solutions, and this seemed to be the only way that would work in all(?) instances, and at the same time wouldn't require a complete proxy server. The basic idea is to use the stateless property of UDP in combination with a co-ordinating webserver which will ensure that both clients start the punch-through at almost the same time, and that they use matching ports etc. So, something external is needed; but nothing more than (for example) a PHP script. If I don't remember incorrectly, this would ensure better compatibility than STUN and simpler punch-through methods. [Edit: Right, sorry. There I was thinking in my DIY way again; forget this post - it's not applicable to indie developers who want to be productive.])
Lõik artiklist:
Instead, I’ve been looking at some solutions to the basic NAT problem. There’s of course STUN for UDP traffic - but that one has problems, since it won’t work on all NAT implementations. UPnP is another proposed solution to this, used in Gaim for example; but UPnP’s not exactly wide-spread and supported in all cases. Other solutions like TURN include proxies of various kinds, but that’s not exactly feasible for a hobby developer - or even for most companies, due to the relatively unnecessary extra cost of a dedicated server.
Theoretically, the following ought to work and requires nothing more than a webserver:
A client sends an HTTP request to a known server, indicating that it wants to connect to another client for a game or a transfer or something.
The server has a PHP script that processes the request, and places it in a pool of clients waiting for a game/transfer/whatever - possibly with their desired destination client specified as well. The server responds with a "yo, keep it up" message.
The client repeatedly sends HTTP requests to show that it’s ready. Once the PHP script determines that there’s a match in the pool, it responds with a "yo, here’s your destination’s IP and port" message. This means unnecessary traffic, but possibly affordable if there’s not much data.
The clients (who hopefully both have received responses with IP/port) start sending 10 garbage UDP packets.
Allow for some delay and possible delivery problems: resend if no connection is established the first time. A maximum of five attempt sequences ought to be enough.
If the connection is established, data UDP packets can be sent.
... Peers Behind Multiple Levels of NAT : In some topologies involving multiple NAT devices, two clients cannot establish an "optimal" P2P route between them without specific knowledge of the topology.
... UDP Idle Timeouts : There is unfortunately no standard value for this timer: some NATs have timeouts as short as 20 seconds. If the application needs to keep an idle UDP session active after establishing the session via hole punching, the application must send periodic keep-alive packets.
... Unfortunately, many NATs associate UDP idle timers with individual UDP sessions defined by a particular pair of endpoints, so sending keep-alives on one session will not keep other sessions active even if all the sessions originate from the same private endpoint. Instead of sending keep-alives on many different P2P sessions, applications can avoid excessive keep-alive traffic by detecting when a UDP session no longer works, and re-running the original hole punching procedure again "on demand."
... When a NAT receives a SYN packet on its public side for what appears to be an unsolicited incoming connection attempt, it is important that the NAT just silently drop the SYN packet. Some NATs instead actively reject such incoming connections by sending back a TCP RST packet or even an ICMP error report, which interferes with the TCP hole punching process. Such behavior is not necessarily fatal, as long as the applications re-try outgoing connection attempts as specified in step 4 of the process described in Section 4.2, but the resulting transient errors can make hole punching take longer.
... Leaving Payloads Alone : A few existing NATs are known to scan "blindly" through packet payloads for 4-byte values that look like IP addresses, and translate them as they would the IP address in the packet header, without knowing anything about the application protocol in use. This bad behavior fortunately appears to be uncommon, and applications can easily protect themselves against it by obfuscating IP addresses they send in messages, for example by sending the bitwise complement of the desired IP address.
... Some multi-level NAT situations require hairpin translation support in order for either TCP or UDP hole punching to work, as described in Section 3.5. The scenario shown in Figure 6, for example, depends on NAT (C) providing hairpin translation. Support for hairpin translation is unfortunately rare in current NATs, but fortunately so are the network scenarios that require it. Multi-level NAT is becoming more common as IPv4 address space depletion continues, however, so support for hairpin translation is important in future NAT implementations.
