[ENet-discuss] Optimizing ENet Protocol ?

[trash uj]

Hi all,

Emmanuel it sounds good to try to optimize the bandwidth this way, but
there are some things you may want to avoid.
- flushing after every send doesnt mean you'll send only 1 message, as some
may need to be resent.
- sending 1 message per packet is bandwidth consuming because of UDP
header. Concatenation is usually a good practice.

regards,
Ju





On Thu, May 24, 2012 at 9:32 PM, Lee Salzman <lsalzman at gmail.com> wrote:

> 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****
>>
>>
>>
> _______________________________________________
> 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/20120528/bf6b4172/attachment.html>