[ENet-discuss] enet 1.3.6 dll for .net

Benoit Germain bnt.germain at gmail.com
Tue Feb 26 00:12:06 PST 2013

2013/2/26 James Bellinger <james at illusorystudios.com>

>  Hmm.
> The problem I see is this:
> Either using referenceCount or freeCallback, just going on destruction,
> there is no way to know why the packet was destroyed.
> ENet not needing it any more might just mean a disconnection as well. Or
> what about enet_host_broadcast (C# Host.Broadcast)?
> It sends to many different peers. So what does it really tell you about
> delivery for ENet to delete it?

I haven't checked the code, but I would think that packet reference count
is incremented for each recipient it is sent to. So when the count reaches
0, you know it was acked by all of them.
enet_host_broadcast isn't an issue either, because this isn't true TCP/IP
broadcasting, just a helper to send a packet to all connected peers.

> If it is good enough for you to know that ENet didn't need it any more,
> the Packet structure's NativeData property can be used
> to get the low-level ENet structure. That has referenceCount and
> freeCallback (for example, IntPtr refCount = p.NativeData->referenceCount,
> though you will need to enable unsafe code in your project).
> referenceCount does say internal use only as well...

I have a Lua binding where I manage packet acking at the Lua level by
exposing a custom packet flag not part of the standard ENet distribution.
When a packet is sent with this flag, I increment the refcount and store
the pointer somewhere. Then the binding to enet_host_service() calls
enet_host_service(), then processes all stored packets and calls a user
notification for those whose refcount says they have been received. No need
to expos refcounting at the Lua level.

> As for freeCallback, I could add helper functions to register callbacks on
> freeing, easy, but I worry it is incomplete for the reasons mentioned above.

The way I see it, the free callback is recorded inside the packet so that
ENet won't crash when freeing a packet memory after the memory callbacks
are modified. No to say you can't do it if you know what you are doing,

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cubik.org/pipermail/enet-discuss/attachments/20130226/0fff6146/attachment.html>

More information about the ENet-discuss mailing list