[ENet-discuss] Optimizing ENet Protocol ?

[Soren Dreijer]

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


_______________________________________________
ENet-discuss mailing list
ENet-discuss at cubik.org
http://lists.cubik.org/mailman/listinfo/enet-discuss

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cubik.org/pipermail/enet-discuss/attachments/20120524/19687b51/attachment.html>