<div dir="ltr">That is... confused. Each peer has its own independent set of channels. There is no such thing as a global channel. <br></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Feb 22, 2015 at 3:18 PM, Pablo de Heras Ciechomski <span dir="ltr"><<a href="mailto:pablo.deheras@gmail.com" target="_blank">pablo.deheras@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div style="font-size:12.8000001907349px">Hi Mokhtar,</div><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px">Seems throttling does nothing to change that. Maybe the EnetSockets fix that? Is there something more higher level than peer in the protocol. To me it seems that all peers share the same channel (also written in the tutorial) so basically sending a message reliably on a special channel should not then block all but then this means we need as many channels as there are peers? In this way to allocate a channel index to a peer "index" such that whatever goes on that channel the peer only blocks himself. This would I guess require that all that connect also allocate as many channels as there are maximum peers. Seems overkill to me.</div><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px">Makes sense? Am I over complicating things? Too hackish?</div><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px">Regards,</div><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px">Pablo</div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Sun, Feb 22, 2015 at 3:40 PM, Mokhtar Naamani <span dir="ltr"><<a href="mailto:mokhtar.naamani@gmail.com" target="_blank">mokhtar.naamani@gmail.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">Hi Pablo,<div>It's interesting point that you raised.</div><div>I'm using enet in a chat application, and I'm also concerned about making sure sending reliable packets to a peer does not block or delay packet delivery to other peers.</div><div>Would we have to disable throttling to do this?</div><div><br></div><div>I wonder is this a feature of enet since it was designed primarily for use in a game engine to keep peers in sync with game data from the server and with each other?</div><div><br></div><div>Regards</div><span><font color="#888888"><div><br></div></font></span><div><span><font color="#888888">Mokhtar</font></span><div><div><br><div><br>On Sunday, February 22, 2015, Pablo de Heras Ciechomski <<a href="mailto:pablo.deheras@gmail.com" target="_blank">pablo.deheras@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Is there a way to do that in ENet to send reliable packets to individual peers such that the packets do not "block" all outgoing reliable packets to other peers? Or is it rather that I filled up some maximum buffer size of reliable data that can exist at the same time?<div><br></div><div>That I still have not understood.</div><div><br></div><div>Pablo</div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Feb 22, 2015 at 1:10 AM, Pablo de Heras Ciechomski <span dir="ltr"><<a>pablo.deheras@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Yet again I win the Internet...<div><br></div><div>So I answer my own question. Indeed as I feared when larger packets than the MTU are sent, they are sent reliably. Arghhhhhh...</div><div><br></div><div>ENET_PACKET_FLAG_UNRELIABLE_FRAGMENT : packet will be fragmented using unreliable (instead of reliable) sends if it exceeds the MTU <br></div><div><br></div><div>Sorry for the signal to noise distortion :-)</div><span><font color="#888888"><div><br></div><div>Pablo</div></font></span><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Feb 22, 2015 at 1:03 AM, Pablo de Heras Ciechomski <span dir="ltr"><<a>pablo.deheras@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Is it because I should allow fragmentation too? Meaning that if I don't allow fragmentation a packet that has not yet arrived will stall the others? All packets are sent unreliable.<div><br></div><div>So confused now,</div><div><br></div><div>Pablo</div><div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Feb 22, 2015 at 1:00 AM, Pablo de Heras Ciechomski <span dir="ltr"><<a>pablo.deheras@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hello Lee, hello all,
<div><br></div><div>I have a streaming server where I have a rather high outgoing bandwidth (14Mbit) and I set the server and client to 0 limit that is unlimited or no bandwidth limitation. I have several clients connecting on LAN and at most if one gets lagged behind that is that (a low end machine that has to cope with the bandwidth but it does not affect the rest). Now the weird part. I told a friend of mine to connect from the other side of the globe and all of a sudden both of us are lagged. I see on the server that it gets updated and indeed generates the data as it should but now both of us are throttled to the very limited bandwidth of my friend even if my other client is on the LAN. I am sending with ENET_PACKET_FLAG_UNSEQUENCED so neither of us should be affected by the other (waiting for a packet to arrive). What gives? I tried it to someone geographically not far away and it was smooth.</div><div><br></div><div>The packets are large and unreliable and broadcasted (tried it sending to individual peers but it did not change a thing).</div><div><br></div><div>Confused,</div><div><br></div><div>Pablo<br></div></div></blockquote></div></div></div></div></blockquote></div></div></div></div></div></blockquote></div>
</div></div>
</blockquote></div></div></div></div>
<br></div></div>_______________________________________________<br>
ENet-discuss mailing list<br>
<a href="mailto:ENet-discuss@cubik.org" target="_blank">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><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>