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" <[email protected]> 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" <[email protected]> > 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 <[email protected]> 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 < >>> [email protected]> 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 < >>>> [email protected]> 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 < >>>>> [email protected]> 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 < >>>>>> [email protected]> 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 < >>>>>>> [email protected]> 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 < >>>>>>>> [email protected]> 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 >>>>> [email protected] >>>>> http://lists.cubik.org/mailman/listinfo/enet-discuss >>>>> >>>>> >>>> _______________________________________________ >>>> ENet-discuss mailing list >>>> [email protected] >>>> http://lists.cubik.org/mailman/listinfo/enet-discuss >>>> >>>> >>> >>> _______________________________________________ >>> ENet-discuss mailing list >>> [email protected] >>> http://lists.cubik.org/mailman/listinfo/enet-discuss >>> >>
_______________________________________________ ENet-discuss mailing list [email protected] http://lists.cubik.org/mailman/listinfo/enet-discuss
