[ENet-discuss] Bandwidth throttling?

[Lee Salzman]

That is... confused. Each peer has its own independent set of channels.
There is no such thing as a global channel.

On Sun, Feb 22, 2015 at 3:18 PM, Pablo de Heras Ciechomski <
pablo.deheras at gmail.com> wrote:

> 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?
>
> Regards,
>
> Pablo
>
> On Sun, Feb 22, 2015 at 3:40 PM, Mokhtar Naamani <
> mokhtar.naamani at gmail.com> wrote:
>
>> 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
>>
>>
> _______________________________________________
> 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/5c5344d3/attachment.html>