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 proper broadcasts.) Is this a bug? On 1 July 2015 at 13:50, Nick Wiggill <[email protected]> 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 > { > handleEvent(&event); > > int result = 0; > if (enet_host_check_events(localhost, &event) < 0) > printf("enet_host_check_events failed (unknown reason).\n"); > else > { > while (enet_host_check_events(localhost, &event) > 0) > { > handleEvent(&event); > } > } > } > > 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 - > http://lists.cubik.org/pipermail/enet-discuss/2013-September/002238.html > ... 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. > > -- > Nick > -- Nick Wiggill *mobile* +27 (0) 825457544
_______________________________________________ ENet-discuss mailing list [email protected] http://lists.cubik.org/mailman/listinfo/enet-discuss
