[ENet-discuss] Bandwidth throttling?

Wed Feb 25 03:40:39 PST 2015

You might want to discard my comment about the mac version as it was due to
an uninitialised message data structure causing a memory overwrite. Mutexes
going wild etc.

Best regards,

Pablo
On 25 Feb 2015 12:36, "Pablo de Heras Ciechomski" <pablo at sciencevisuals.com>
wrote:

> You might want to discard my comments on the mac version as it turns out
> that the problem was a buffer overrun/memory overwrite causing all kinds of
> secondary artifacts.
>
> Pablo
> On 24 Feb 2015 00:23, "Pablo de Heras Ciechomski" <pablo.deheras at gmail.com>
> wrote:
>
>> Hi Lee,
>>
>> First of all thanks for a great library.
>>
>> Well then how else to describe the behaviour of sending a message
>> reliably (becomes reliable since too big to not be fragmented) and then
>> when I have all good connection players we all enjoy good steady FPS and
>> when one laggy and bad quality connection player connects all of us get to
>> share his lag? I know that the server receives a steady stream from all
>> players inputs (sent as unreliable) as on the server machine the updates
>> are smooth.
>>
>> Also another thing, sometimes packets are sent before
>> ENET_EVENT_TYPE_CONNECT, so I moved all my player book keeping to be
>> strictly in the ENET_EVENT_TYPE_RECEIVE. It only happens on a MacBook Pro
>> though, iPad and Windows seem to play fair :-)
>>
>> Pablo
>>
>> On Mon, Feb 23, 2015 at 11:26 PM, Lee Salzman <lsalzman at gmail.com> wrote:
>>
>>> 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
>>>>
>>>>
>>>
>>> _______________________________________________
>>> 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/20150225/4a6934c4/attachment.html>