[ENet-discuss] Optimizing ENet Protocol ?
Lee Salzman
lsalzman at gmail.com
Thu May 24 04:52:51 PDT 2012
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/df870e40/attachment.html>
More information about the ENet-discuss
mailing list