[ENet-discuss] New experimental feature: packet intercept callbacks

[Lee Salzman]

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 <jsprenkle at gmail.com> 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 <lsalzman at gmail.com> 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
>> ENet-discuss at cubik.org
>> 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
> ENet-discuss at cubik.org
> http://lists.cubik.org/mailman/listinfo/enet-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cubik.org/pipermail/enet-discuss/attachments/20121002/7a89eb2d/attachment.html>