Hi all,<div><br></div><div>Emmanuel it sounds good to try to optimize the bandwidth this way, but there are some things you may want to avoid.</div><div>- flushing after every send doesnt mean you'll send only 1 message, as some may need to be resent.</div>

<div>- sending 1 message per packet is bandwidth consuming because of UDP header. Concatenation is usually a good practice.</div><div><br></div><div>regards,</div><div>Ju</div><div><br></div><div><br></div><div><br></div>

<div><br><br><div class="gmail_quote">On Thu, May 24, 2012 at 9:32 PM, Lee Salzman <span dir="ltr"><<a href="mailto:lsalzman@gmail.com" target="_blank">lsalzman@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

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:<div>


<br></div><div>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.<br><br>So we can summarize and say that the peer id field is a feature, not a bug. </div>


<div><br></div><div>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. :)</div><div class="HOEnZb"><div class="h5"><div><br>

<div class="gmail_quote">On Thu, May 24, 2012 at 5:57 AM, Soren Dreijer <span dir="ltr"><<a href="mailto:dreijer@echobit.net" target="_blank">dreijer@echobit.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Just to chime in on this a bit:<u></u><u></u></span></p>


<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I believe having the peer ID explicitly in the header also allows multiple connections between nodes.<u></u><u></u></span></p>


<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">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.<u></u><u></u></span></p>


<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">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.<u></u><u></u></span></p>


<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Just my experience.<u></u><u></u></span></p>


<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">/ Soren<u></u><u></u></span></p>


<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p><div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">


<div><div style="border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0in 0in 0in"><p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> <a href="mailto:enet-discuss-bounces@cubik.org" target="_blank">enet-discuss-bounces@cubik.org</a> [mailto:<a href="mailto:enet-discuss-bounces@cubik.org" target="_blank">enet-discuss-bounces@cubik.org</a>] <b>On Behalf Of </b>Lee Salzman<br>


<b>Sent:</b> Thursday, May 24, 2012 6:53 AM<br><b>To:</b> Discussion of the ENet library<br><b>Subject:</b> Re: [ENet-discuss] Optimizing ENet Protocol ?<u></u><u></u></span></p></div></div><div><div><p class="MsoNormal">


<u></u> <u></u></p><p class="MsoNormal">One way to handle all the mess reliably that I could conceive:<u></u><u></u></p><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">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.<u></u><u></u></p>


</div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">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. :)<u></u><u></u></p>


</div><div><p class="MsoNormal"><u></u> <u></u></p><div><p class="MsoNormal">On Thu, May 24, 2012 at 4:31 AM, Len Holgate <<a href="mailto:len.holgate@gmail.com" target="_blank">len.holgate@gmail.com</a>> wrote:<u></u><u></u></p>


<div><p class="MsoNormal" style="margin-bottom:12.0pt">> Does the UDP packet's header contain the port of the Router or the<br>> initial sender port ? I'd guess the later, as when you send some<u></u><u></u></p>


</div><p class="MsoNormal">The datagram can only contain the address and port of the sender. BUT the<br>sender, in the case of NAT routers, is the NAT and NOT the client machine<br>where your code is running.<u></u><u></u></p>


<div><p class="MsoNormal" style="margin-bottom:12.0pt"><br>> Anyway, I'll do a loose bind then, ie: if there's no perfect IP /<br>> Port match, I'd do only a IP match, that should be ok in my case.<u></u><u></u></p>


</div><p class="MsoNormal">Which will work just fine if you only have one peer coming in from that<br>particular address...<br><br>Len<br><a href="http://www.serverframework.com" target="_blank">www.serverframework.com</a><u></u><u></u></p>


<div><p class="MsoNormal"><br></p></div></div></div></div></div></div></div></blockquote></div></div>
</div></div><br>_______________________________________________<br>
ENet-discuss mailing list<br>
<a href="mailto:ENet-discuss@cubik.org">ENet-discuss@cubik.org</a><br>
<a href="http://lists.cubik.org/mailman/listinfo/enet-discuss" target="_blank">http://lists.cubik.org/mailman/listinfo/enet-discuss</a><br>
<br></blockquote></div><br></div>