<div dir="ltr">You can have timing without having a real time clock. Real time clocks strongly imply persistence between power cycles.</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Aug 9, 2013 at 4:35 AM, Ruud van Gaal <span dir="ltr"><<a href="mailto:ruud@racer.nl" target="_blank">ruud@racer.nl</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Running ENet without some kind of timing? I'd say that would be pretty hopeless of trying to achieve, as ENet is targeted to handling resends of packets. For which you need, well, something that is time to make any sense.<br>
</div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Aug 8, 2013 at 11:00 PM, Doug Warren <span dir="ltr"><<a href="mailto:dwarren@thebigwave.net" target="_blank">dwarren@thebigwave.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">And actually from Patricks point of view that's even worse. What if the embeded device has no RTC then every random seed on startup would be the same. Perhaps enet_random_entropy() in each platform would be more clear.</div>
<div><div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Aug 8, 2013 at 1:18 PM, Lee Salzman <span dir="ltr"><<a href="mailto:lsalzman@gmail.com" target="_blank">lsalzman@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Not quite, enet_time_get() is for returning a running time counter, and is not really intended for providing a time-differentiated random seed. If you start up enet in quick succession making connections, then the random seeds can more easily accidentally overlap. The idea here is to get actual time in seconds so that on successive startups of enet the chance of collisions is much smaller. And it's intended that time() is pretty standard, and originally that's all that was used... Except that Win32 in its usual rebelliousness, doesn't quite like this without linking against more extra libraries, so I opted for timeGetTime() there. Chill out. It's not the end of the world.<div>
<br>
<br>
On 08/08/2013 10:56 PM, Patrick Klos wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
On 8/8/2013 2:00 PM, Doug Warren wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
You'd have to define your terms a bit better. It's straight C, if you have berkley sockets and anything even vaguely resembling POSIX there should be no need for extra support. I use the same build scripts for iOS/Android/OSX/Linux.<br>
</blockquote>
<br></div>
The platform in question uses lwIP <<a href="http://savannah.nongnu.org/projects/lwip/" target="_blank">http://savannah.nongnu.org/<u></u>projects/lwip/</a>> (a lightweight IP stack). Not real close to POSIX, but the basic functions are there. It's not quite _extra_ support, but it's _different_ support. I have it essentially working.<div>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<a href="https://github.com/lsalzman/enet/blob/master/host.c" target="_blank">https://github.com/lsalzman/<u></u>enet/blob/master/host.c</a> shows a single check for a platform specific check regarding how to get a uint32 timestamp.<br>
</blockquote>
<br>
Which is completely unnecessary when the platform abstraction layer (win32.c and unix.c) provides the enet_time_get() function!?! It doesn't make sense why that function wouldn't be used?<br>
<br>
Patrick<br>
<br>
<br>
<br></div><div>
______________________________<u></u>_________________<br>
ENet-discuss mailing list<br>
<a href="mailto:ENet-discuss@cubik.org" target="_blank">ENet-discuss@cubik.org</a><br>
<a href="http://lists.cubik.org/mailman/listinfo/enet-discuss" target="_blank">http://lists.cubik.org/<u></u>mailman/listinfo/enet-discuss</a><br>
</div></blockquote><div><div>
<br>
______________________________<u></u>_________________<br>
ENet-discuss mailing list<br>
<a href="mailto:ENet-discuss@cubik.org" target="_blank">ENet-discuss@cubik.org</a><br>
<a href="http://lists.cubik.org/mailman/listinfo/enet-discuss" target="_blank">http://lists.cubik.org/<u></u>mailman/listinfo/enet-discuss</a><br>
</div></div></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
ENet-discuss mailing list<br>
<a href="mailto:ENet-discuss@cubik.org" target="_blank">ENet-discuss@cubik.org</a><br>
<a href="http://lists.cubik.org/mailman/listinfo/enet-discuss" target="_blank">http://lists.cubik.org/mailman/listinfo/enet-discuss</a><br>
<br></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
ENet-discuss mailing list<br>
<a href="mailto:ENet-discuss@cubik.org">ENet-discuss@cubik.org</a><br>
<a href="http://lists.cubik.org/mailman/listinfo/enet-discuss" target="_blank">http://lists.cubik.org/mailman/listinfo/enet-discuss</a><br>
<br></blockquote></div><br></div>