[ENet-discuss] Bandwidth throttling?

[Pablo de Heras Ciechomski]

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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cubik.org/pipermail/enet-discuss/attachments/20150222/768a9c4e/attachment.html>