[ENet-discuss] Optimizing ENet Protocol ?

[Lee Salzman]

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 <dreijer at echobit.net> 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:* enet-discuss-bounces at cubik.org [mailto:
> enet-discuss-bounces at cubik.org] *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 <len.holgate at gmail.com>
> 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****
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cubik.org/pipermail/enet-discuss/attachments/20120524/e2409572/attachment-0001.html>