From xkazinx at gmail.com  Sun Apr  9 20:00:17 2017
From: xkazinx at gmail.com (Kazin Lujan)
Date: Mon, 10 Apr 2017 00:00:17 -0300
Subject: [ENet-discuss] Can modifying packet->dataLength cause leaks?
Message-ID: <CAAgLNQ3yH0E_HRxaWDN1f3BVpdTUTAL-WA9PJjOAdhcads-8cg@mail.gmail.com>

Could modifying packet->dataLength before being sent cause a leak?

I'm setting it to 0 after I create it and increasing the value based on the
data I'm writing into packet->data.

I'm doing this when I don't know what will be the exact size of the data to
be sent.

I assume enet will destroy all the data regardless of the dataLength value
since it uses packet->data = enet_malloc(...) to allocate in
enet_packet_create and enet_free(packet->data) to deallocate in
enet_packet_destroy(...), but I don't know about enet's internal processes.

Example code: https://pastebin.com/QdaHjqft
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cubik.org/pipermail/enet-discuss/attachments/20170410/563f319b/attachment.html>

From lsalzman at gmail.com  Sun Apr  9 20:25:09 2017
From: lsalzman at gmail.com (Lee Salzman)
Date: Sun, 9 Apr 2017 23:25:09 -0400
Subject: [ENet-discuss] Can modifying packet->dataLength cause leaks?
In-Reply-To: <CAAgLNQ3yH0E_HRxaWDN1f3BVpdTUTAL-WA9PJjOAdhcads-8cg@mail.gmail.com>
References: <CAAgLNQ3yH0E_HRxaWDN1f3BVpdTUTAL-WA9PJjOAdhcads-8cg@mail.gmail.com>
Message-ID: <CAPk1TVGjFBFeejtni5rReQv7UTsoQDYXrBxGF2FNSg9CeBVa_w@mail.gmail.com>

Use enet_packet_resize to grow the packet. That's what it exists for.

On Sun, Apr 9, 2017 at 11:00 PM, Kazin Lujan <xkazinx at gmail.com> wrote:
> Could modifying packet->dataLength before being sent cause a leak?
>
> I'm setting it to 0 after I create it and increasing the value based on the
> data I'm writing into packet->data.
>
> I'm doing this when I don't know what will be the exact size of the data to
> be sent.
>
> I assume enet will destroy all the data regardless of the dataLength value
> since it uses packet->data = enet_malloc(...) to allocate in
> enet_packet_create and enet_free(packet->data) to deallocate in
> enet_packet_destroy(...), but I don't know about enet's internal processes.
>
> Example code: https://pastebin.com/QdaHjqft
>
> _______________________________________________
> ENet-discuss mailing list
> ENet-discuss at cubik.org
> http://lists.cubik.org/mailman/listinfo/enet-discuss
>

From xkazinx at gmail.com  Sun Apr  9 21:49:29 2017
From: xkazinx at gmail.com (Kazin Lujan)
Date: Mon, 10 Apr 2017 01:49:29 -0300
Subject: [ENet-discuss] Can modifying packet->dataLength cause leaks?
In-Reply-To: <CAPk1TVGjFBFeejtni5rReQv7UTsoQDYXrBxGF2FNSg9CeBVa_w@mail.gmail.com>
References: <CAAgLNQ3yH0E_HRxaWDN1f3BVpdTUTAL-WA9PJjOAdhcads-8cg@mail.gmail.com>
 <CAPk1TVGjFBFeejtni5rReQv7UTsoQDYXrBxGF2FNSg9CeBVa_w@mail.gmail.com>
Message-ID: <CAAgLNQ3z3knwxaaxqd7DMqnYjttRV3EF+G8n6ox8M0jSTNY3TQ@mail.gmail.com>

Say you have to write 100 strings:

Would you consider it better (in benchmark terms) to write their content
into a big buffer and then memcpy(ing) it into a packet being created with
the written size, or writing directly into packet->data and resizing it
each time a string is being written when the written size exceeds the
packet's size?

I wanted to alter packet->dataLength to manipulate the amount of data being
sent so that a single allocation is needed in case the exact size is a bit
messy to calculate (I used strings as an example). If it's not viable,
sounds like the first option could work.

2017-04-10 0:25 GMT-03:00 Lee Salzman <lsalzman at gmail.com>:

> Use enet_packet_resize to grow the packet. That's what it exists for.
>
> On Sun, Apr 9, 2017 at 11:00 PM, Kazin Lujan <xkazinx at gmail.com> wrote:
> > Could modifying packet->dataLength before being sent cause a leak?
> >
> > I'm setting it to 0 after I create it and increasing the value based on
> the
> > data I'm writing into packet->data.
> >
> > I'm doing this when I don't know what will be the exact size of the data
> to
> > be sent.
> >
> > I assume enet will destroy all the data regardless of the dataLength
> value
> > since it uses packet->data = enet_malloc(...) to allocate in
> > enet_packet_create and enet_free(packet->data) to deallocate in
> > enet_packet_destroy(...), but I don't know about enet's internal
> processes.
> >
> > Example code: https://pastebin.com/QdaHjqft
> >
> > _______________________________________________
> > ENet-discuss mailing list
> > ENet-discuss at cubik.org
> > http://lists.cubik.org/mailman/listinfo/enet-discuss
> >
> _______________________________________________
> 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/20170410/a55b8ca0/attachment.html>

From randomuser2016 at yandex.com  Fri Apr 28 21:28:52 2017
From: randomuser2016 at yandex.com (dmk)
Date: Sat, 29 Apr 2017 14:28:52 +1000
Subject: [ENet-discuss] Protocol documentation? Performance benchmarks?
	Reference client?
Message-ID: <4695481493440132@web55j.yandex.ru>

An HTML attachment was scrubbed...
URL: <http://lists.cubik.org/pipermail/enet-discuss/attachments/20170429/81cb92e7/attachment.html>

From lsalzman at gmail.com  Sun Apr 30 15:45:16 2017
From: lsalzman at gmail.com (Lee Salzman)
Date: Sun, 30 Apr 2017 18:45:16 -0400
Subject: [ENet-discuss] Protocol documentation? Performance benchmarks?
 Reference client?
In-Reply-To: <4695481493440132@web55j.yandex.ru>
References: <4695481493440132@web55j.yandex.ru>
Message-ID: <CAPk1TVEffLNBn=4XFutTZYVddbGCmFAenWUsuo6Ahv+7grW9Bg@mail.gmail.com>

1. Currently whatever documentation is in the tarball/doxygen'd to the
main site is what exists. The code in protocol.c though isn't that
big, so it is viable to study it if you're not afraid to dig in.
2. Not so much, shouldn't be that hard to make something up from the
tutorial, though.
3. Not sure I understand the motivation here. ENet is not really about
data transfer throughput. It's about giving you tools to combat
latency in latency sensitive applications (basically games).

On Sat, Apr 29, 2017 at 12:28 AM, dmk <randomuser2016 at yandex.com> wrote:
> Greetings!
>
> I'm considering porting enet to a Zynq based platform running lwIp stack on
> bare metal.
> Just wondering:
>
> 1. Is there any RFC-style protocol documentation? At least, packet header
> format and basic sequence would be nice.
>
> 2. Is there a reference client? Something like command-line test/benchmark
> utility similar to iperf would be perfect.
>
> 3. Are there any benchmarks available? How close do you think can I get to
> wire speed on a dedicated 1Gb ethernet link?
>
> Thanks,
> VP
>
> _______________________________________________
> ENet-discuss mailing list
> ENet-discuss at cubik.org
> http://lists.cubik.org/mailman/listinfo/enet-discuss
>