Oh, damn, I'm going senile at 30. You reminded me why it is necessary, and I implemented it this way for this reason. Stupid brain. :( Multiple independent connections from the same host. Forget any sort of silly NAT/router trickiness. It's pretty stupid simple:
If one host opens more than 1 connection to another host, there will be multiple peers with the same IP/port. The only way to differentiate them is with a peer id. So we can summarize and say that the peer id field is a feature, not a bug. In my defense, I did write the initial implementation of this 10 years ago, so the exact reasons I did some things can require some brain excavation. :) On Thu, May 24, 2012 at 5:57 AM, Soren Dreijer <[email protected]> wrote: > 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
