<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#c0c0c0" bgcolor="#000000">
No, the point is to get all available packets in this frame and not
stall, i.e. it is polling. You wouldn't use a non-zero timeout in a
game's client loop like that.<br>
<br>
Lee<br>
<br>
On 11/21/2010 02:31 PM, Mark Palkow wrote:
<blockquote cite="mid:04c901cb89cb$e1763d20$a462b760$@com" type="cite">
<pre wrap="">Couldn't the problem be
while( enet_host_service (client, & event, 0) > 0 )
because it takes all the CPU (100%)?
shouldn't it be something like:
while( enet_host_service (client, & event, 10) > 0 )
so that the CPU gets a chance to handle other task like the network stack?
regards Mark
-----Ursprüngliche Nachricht-----
Von: <a class="moz-txt-link-abbreviated" href="mailto:enet-discuss-bounces@cubik.org">enet-discuss-bounces@cubik.org</a> [<a class="moz-txt-link-freetext" href="mailto:enet-discuss-bounces@cubik.org">mailto:enet-discuss-bounces@cubik.org</a>]
Im Auftrag von Chris Meub
Gesendet: Sonntag, 21. November 2010 08:39
An: Discussion of the ENet library
Betreff: Re: [ENet-discuss] 4 seconds stalls.. congestion problem?
I am doing this every 1/60th second:
while( enet_host_service (client, & event, 0) > 0 )
{
switch (event.type)
{
case ENET_EVENT_TYPE_RECEIVE:
// ( handle packet )
enet_packet_destroy (event.packet);
break;
case ENET_EVENT_TYPE_DISCONNECT: // (handle disconnect here)
}
}
As I understand it that will process all available events.
On Sat, Nov 20, 2010 at 9:47 PM, Lee Salzman <a class="moz-txt-link-rfc2396E" href="mailto:lsalzman@gmail.com"><lsalzman@gmail.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">In the client, make sure you repeatedly call enet_host_service() until it
returns no events, otherwise it may possibly not service the network at
</pre>
</blockquote>
<pre wrap="">all
</pre>
<blockquote type="cite">
<pre wrap="">if it gets backlogged.
Lee
On 11/20/2010 07:41 PM, Chris Meub wrote:
It does *not* exhibit the stalling behavior when I run on LAN or on
the same machine.
On Sat, Nov 20, 2010 at 6:44 PM, Jay Sprenkle <a class="moz-txt-link-rfc2396E" href="mailto:jsprenkle@gmail.com"><jsprenkle@gmail.com></a> wrote:
Have you tried running both on the same physical machine, or on two
</pre>
</blockquote>
<pre wrap="">machines
</pre>
<blockquote type="cite">
<pre wrap="">within your control?
Perhaps it's caused by comcast equipment.
On Sat, Nov 20, 2010 at 6:52 PM, Chris Meub <a class="moz-txt-link-rfc2396E" href="mailto:chrismeub@gmail.com"><chrismeub@gmail.com></a> wrote:
The server is hosted on a dedicated hosting provider M5, but I have
also tried putting the server on a friend's home Ubuntu server with
the exact same intermittent stalling behavior.
The client is under a router and cable modem with comcast
pinging the server averages 49ms at the moment, 32ms from another
network ive tested
</pre>
</blockquote>
<br>
</blockquote>
<br>
</body>
</html>