[ENet-discuss] Bandwidth throttling?

Pablo de Heras Ciechomski pablo.deheras at gmail.com
Sun Feb 22 15:18:18 PST 2015

Hi Mokhtar,

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.

Makes sense? Am I over complicating things? Too hackish?



On Sun, Feb 22, 2015 at 3:40 PM, Mokhtar Naamani <mokhtar.naamani at gmail.com>

> Hi Pablo,
> It's interesting point that you raised.
> 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.
> Would we have to disable throttling to do this?
> 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?
> Regards
> Mokhtar
> On Sunday, February 22, 2015, Pablo de Heras Ciechomski <
> pablo.deheras at gmail.com> wrote:
>> 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?
>> That I still have not understood.
>> Pablo
>> On Sun, Feb 22, 2015 at 1:10 AM, Pablo de Heras Ciechomski <
>> pablo.deheras at gmail.com> wrote:
>>> Yet again I win the Internet...
>>> So I answer my own question. Indeed as I feared when larger packets than
>>> the MTU are sent, they are sent reliably. Arghhhhhh...
>>> ENET_PACKET_FLAG_UNRELIABLE_FRAGMENT : packet will be fragmented using
>>> unreliable (instead of reliable) sends if it exceeds the MTU
>>> Sorry for the signal to noise distortion :-)
>>> Pablo
>>> On Sun, Feb 22, 2015 at 1:03 AM, Pablo de Heras Ciechomski <
>>> pablo.deheras at gmail.com> wrote:
>>>> 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.
>>>> So confused now,
>>>> Pablo
>>>> On Sun, Feb 22, 2015 at 1:00 AM, Pablo de Heras Ciechomski <
>>>> pablo.deheras at gmail.com> wrote:
>>>>> Hello Lee, hello all,
>>>>> 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.
>>>>> The packets are large and unreliable and broadcasted (tried it sending
>>>>> to individual peers but it did not change a thing).
>>>>> Confused,
>>>>> Pablo
> _______________________________________________
> 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/20150223/31ad16fd/attachment.html>

More information about the ENet-discuss mailing list