ENet has no idea what threads are. So, yes, it is running in the same thread.
It's just a function pointer that is executed every time a raw UDP packet comes in. Unless you are trying to solve weather simulations in the intercept callback, it should have no real significant effect on performance. You get an intercept callback for every single raw UDP packet that comes in. It is happening below the ENet protocol layer, essentially, so it has no relation to relable/unreliable/retries/etc. You just get one incoming raw UDP packet = one intercept callback. On Tue, Oct 2, 2012 at 2:39 PM, Jay Sprenkle <[email protected]> wrote: > I can definitely see use for this. Thanks for posting it! > > I have a couple of questions: > > I'm assuming the callback will be running in the same thread as whatever > calls the host polling code? > > How does this affect efficiency and latency vs polling? > > Do we get interrupt callbacks during retries? > > If we use reliable delivery do wet get the interrupts in the correct order > or just whatever comes in? > > Thanks again. > > > > On Tue, Oct 2, 2012 at 5:48 AM, Lee Salzman <[email protected]> wrote: > >> Because there were some requests on github for things that would >> otherwise use the functionality, or direct appeals for the functionality >> itself, I finally bit the bullet and added a simple packet intercept >> callback to ENetHost, usage looks sorta like this: >> >> >> int intercept_callback(ENetHost *host, ENetEvent *event) >> { >> // the first two bytes of a valid ENet protocol packet will never be >> 0xFFFF, so you should ideally use this to distinguish user data packets >> from ENet protocol packets >> if(host->receivedDataLength >= 2 && *(unsigned short >> *)host->receivedData == 0xFFFF) >> { >> // host->receivedAddress contains the address the UDP packet came >> from >> // do magical stuff with packet here... >> // if event is non-NULL, you can also set event->type with your own >> non-zero event number that ENet will pass out of enet_host_service(), but >> this is not required, just optional >> // if event->type is untouched, ENet will still skip the packet so >> long as you return 1... >> return 1; // tell ENet to skip the packet >> } >> return 0; // tell ENet to continue processing the packet >> // returning -1 will propagate the -1 return value out of >> enet_host_service... >> } >> >> .... >> host -> intercept = intercept_callback; >> .... >> enet_host_service(host, event, timeout); // intercept gets called from in >> here when ENet receives a raw udp packet >> // if you propagated a custom event type from within the intercept >> callback, it will get returned out here too with enet_host_service >> returning 1 like for any other event >> >> This system can be used to implement all manner of fun things, from >> simulating packet loss to multiplexing your own data like pings or whatever >> over the ENet socket. >> This is currently in the github repo, going to let it stew a bit before I >> release anything in case people have suggestions. >> >> >> _______________________________________________ >> ENet-discuss mailing list >> [email protected] >> http://lists.cubik.org/mailman/listinfo/enet-discuss >> >> > > > -- > --- > *"Why do you have that banana in your ear?" > "To keep away the alligators." > "But there are no alligators here." > "See! It's working!"* > *--* > *The Democrats are the left wing.* > *The Republicans are the right wing.* > *We all know how well a bird flies with just one wing.* > > > _______________________________________________ > 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
