[ENet-discuss] [Receive, process, send] vs. [Receive AND Send, process]
nick.wiggill at gmail.com
Wed Jul 1 05:58:30 PDT 2015
OK, some further testing revealed the following. I queued various message
types back to back on the host and watched what happened on the receiving
peer, on enet_host_flush().
Queueing 2 messages using enet_host_send() works fine;
Queueing 1 broadcast followed by 1 message sends only the broadcast;
Queueing 1 message followed by 1 broadcast sends only the message.
Queueing 2 broadcasts sends only 1 broadcast (presumably the first);
For anything with broadcasts, the first called function takes effect, the
second does not. (I can use a loop of enet_host_send() for now to replace
Is this a bug?
On 1 July 2015 at 13:50, Nick Wiggill <nick.wiggill at gmail.com> wrote:
> ENet seems to handle send AND receive in one strangely mangled loop when
> it comes to realtime applications... not sure if this is exactly right, but
> close enough:
> ENetEvent event;
> if (enet_host_service(localhost, &event, 0) > 0) //0 arg for realtime
> - non-blocking
> int result = 0;
> if (enet_host_check_events(localhost, &event) < 0)
> printf("enet_host_check_events failed (unknown reason).\n");
> while (enet_host_check_events(localhost, &event) > 0)
> What I'd like is to receive incoming messages, do my processing based off
> the incoming data, then send out a new set of messages (which feeds back
> into other peers' receive cycles), *without* pulling newly received
> messages out of the enet events list, at a stage when all I want is to
> *send*... I want those receives still sitting in the event queue when I
> next do receiving (next frame).
> enet_host_flush sadly doesn't seem to send out all the messages when I
> have multiple messages queued up to the same peer, which I confirmed here -
> ... so I'm forced to use enet_host_service / enet_host_check_events which
> then leads to unwanted receives while I'm trying to send.
*mobile* +27 (0) 825457544
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ENet-discuss