[ENet-discuss] 4 seconds stalls.. congestion problem?

Tue Nov 23 17:59:00 PST 2010

Look at the logs from both machines, and maybe the packet trace to see what
each side thought was going on in those 4 seconds.  For network bugs, our #1
step in debugging is turning on a super vocal dump that will tell us all
state changes, timeouts, packet receptions, everything.  Usually that shows
the problem pretty quick.

My guess is that your connection is just that bad.  Are you on wifi?
Wireless very frequently drops the connection entirely for seconds at a time
in just the manner you describe.  Try a ping -t for a while, and see if it
doesn't occasionally drop packets the same as your game is.

4 seconds of lockup is not really acceptable to a player.  I'd definitely
fix it.  We drop players at around that point of non-communication to keep
the rest of the peers able to play.  At some point, if someone turned off
their machine, the rest of the group has to agree to continue without them.

eNet knows about the stall under the covers, and will automatically resend
if you're using reliable packets and are calling update regularly.  Once
you've gone past 150% or 200% of the round trip time (the number is in the
code somewhere), it'll auto-resend assuming the packet dropped.  eNet will
retry a few times, with longer and longer timeouts before giving up with an
error (again, from memory, so the code might disagree).

Chris

On Tue, Nov 23, 2010 at 5:01 PM, Chris Meub <chrismeub at gmail.com> wrote:

> Thanks a lot guys, this is really helpful info. I can see light at the
> end of the tunnel.
>
> @Chris Jurney, if you were testing Brutal Legend with say 2 players
> and you noticed that randomly after a while your client just failed to
> communicate with the server for 4 or 5 seconds before it "regained
> consciousness" what would your course of action be? How would you
> narrow down the problem? Or would this just be considered an
> acceptable "lag spike" and ignore it?
>
> Also, during this stall, would your client/server detect this and
> react in some way to fix it?
>
> On Tue, Nov 23, 2010 at 3:59 PM, Chris Jurney <jurney at gmail.com> wrote:
> > Brutal Legend sends 30 updates a second for 4 players or less reliably
> with
> > no problems.  For 5 or more, we go down to 15 packets a second (although
> > each packet contains 2 game-messages) to reduce the UDP/VDP/eNet
> overhead.
> > If you're sending this many updates, the main consumer of bandwidth is
> the
> > headers, so be very careful that you're sending your enet ACKs in the
> same
> > packet as your next send.  You can tell if this is the case using any
> wire
> > sniffer and seeing if you're firing 30 or 60 UDP frames per second.  If
> it's
> > 60, you need to process incoming messages before sending new ones and
> > flushing.
> >
> > On Tue, Nov 23, 2010 at 2:22 PM, Chris Meub <chrismeub at gmail.com> wrote:
> >>
> >> Does anyone have experience using enet with a multiplayer game sending
> >> reliable packets ~20 times a second or more?
> >> I imagine most people sending that many packets are using unreliable.
> >>
> >> On Sun, Nov 21, 2010 at 6:01 PM, Lee Salzman <lsalzman at gmail.com>
> wrote:
> >> > 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.
> >> >
> >> > Lee
> >> >
> >> > On 11/21/2010 02:31 PM, Mark Palkow wrote:
> >> >
> >> > 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: enet-discuss-bounces at cubik.org
> >> > [mailto:enet-discuss-bounces at cubik.org]
> >> > 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 <lsalzman at gmail.com>
> wrote:
> >> >
> >> >
> >> > 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
> >> >
> >> >
> >> > all
> >> >
> >> >
> >> > 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 <jsprenkle at gmail.com>
> >> > wrote:
> >> >
> >> >
> >> > Have you tried running both on the same physical machine, or on two
> >> >
> >> >
> >> > machines
> >> >
> >> >
> >> > within your control?
> >> > Perhaps it's caused by comcast equipment.
> >> >
> >> > On Sat, Nov 20, 2010 at 6:52 PM, Chris Meub <chrismeub at gmail.com>
> 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
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > _______________________________________________
> >> > 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
> >
> >
> > _______________________________________________
> > 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/20101123/bae59b70/attachment.html>