Just to chime in on this a bit:
I believe having the peer ID explicitly in the header also allows multiple connections between nodes. For instance, when I do NAT traversal, a peer attempts to connect to a remote peer both on the LAN address (e.g. 10.0.0.3) and via the public IP (e.g. 1.2.3.4). If the two peers happen to be on the same network, I've seen routers change the datagram header's IP source for the public IP packet to the local IP. So, when the remote peer receives the two UDP packets, it looks like they're coming from the same source (e.g. 10.0.0.2) even though they're actually two independent connections. Enet needs the peer ID in its header to properly figure out that it's two separate enet channels because the IP/host pair isn't enough. Just my experience. / Soren From: [email protected] [mailto:[email protected]] On Behalf Of Lee Salzman Sent: Thursday, May 24, 2012 6:53 AM To: Discussion of the ENet library Subject: Re: [ENet-discuss] Optimizing ENet Protocol ? One way to handle all the mess reliably that I could conceive: Hash on IP/port, just a big linearly probed array of pointers to peers would be sufficient. If not found, then send a sort of ack back to the client, requesting a re-connect packet. Once the other side receives the ack, that side sends a re-connect packet containing the long-form session id. So once the other end gets this, it uses the IP and session id to locate the correct peer, and set it up on the new port. But that only solves some of the problem. You still have to figure out what to do about protocol compatibility across all users of ENet... Trickier problem. :) On Thu, May 24, 2012 at 4:31 AM, Len Holgate <[email protected]> wrote: > Does the UDP packet's header contain the port of the Router or the > initial sender port ? I'd guess the later, as when you send some The datagram can only contain the address and port of the sender. BUT the sender, in the case of NAT routers, is the NAT and NOT the client machine where your code is running. > Anyway, I'll do a loose bind then, ie: if there's no perfect IP / > Port match, I'd do only a IP match, that should be ok in my case. Which will work just fine if you only have one peer coming in from that particular address... Len www.serverframework.com _______________________________________________ ENet-discuss mailing list [email protected] http://lists.cubik.org/mailman/listinfo/enet-discuss
_______________________________________________ ENet-discuss mailing list [email protected] http://lists.cubik.org/mailman/listinfo/enet-discuss
