Maybe you can use ping, and use delay with low latency clients. However, 100 ms sounds pretty long time...
Jussi On Fri, Jun 3, 2011 at 09:36, Kevin Fishburne < [email protected]> wrote: > On 06/01/2011 02:06 AM, Kevin Fishburne wrote: > > On 05/30/2011 03:31 PM, Benoît Minisini wrote: > >>> Any reason a compiled app would behave differently than an app run in > >>> the IDE? My app stalls half-way through receiving network packets from > >>> the server when compiled, but when both are running in the IDE it works > >>> fine. Didn't have this problem earlier tonight. This is new to me. I'm > >>> using build 3866. > >> > >> Mmm. Very hard to guess as soon as you do network programming. > >> > >> When your program is stalled, do that in a terminal: > >> > >> $ gdb /usr/bin/gbx3<pid of your application> > >> ... > >> (gdb) bt > >> ... > >> > >> And send me the result of the 'bt' command, which should tell where the > >> program is stalled. > >> > >> Note: replace /usr/bin/gbx3 by where the gambas interpreter is actually > >> installed. > > > > When I said "stalled" I meant it continued execution but without > > processing the expected events (it didn't freeze or raise an error). I'm > > sorry for not being more specific. I've also discovered it has nothing > > to do with whether or not the program has been compiled. That was a red > > herring. This is what is happening: > > > > The client sends its username and password to the server. The server > > tells the client that it has authenticated, then begins to send it > > multiple transactions (packets) with the information that it needs to > > start the game. All the transactions use the same procedures (client and > > server share transaction processing code), so the theory is that if one > > works they should all work. It has worked in the past, so I think a > > change in programming logic (multiple medium-sized packets in sequence) > > may have exposed a bug. > > > > The weird thing that started happening is that a series of similar > > transactions being sent by the server began to be received irregularly > > by the client. Frequently the number of successful transactions changes > > between sequential program runs. Usually I expect something to fail > > consistently, not work sometimes then fail other times, so it's very > > confusing. Also it seems like the smaller the packet size the less > > frequently it fails. > > > > For example, if the server sends a series of nine packets to the client, > > each around 25K, the client will receive less than nine 100% of the > > time. If the server sends nine 15K packets the client may fail to > > receive them all 75% of the time. If the packets are under 10K then it > > may fail 25% of the time. > > > > Also sometimes the client receives packets with packets missing in the > > middle. For example, the client may receive packets 0 - 8, miss packets > > 9 - 11, and finally receive packet 12. > > > > The server is actually sending all the UDP data properly. I've > > step-traced the client and the UDP_Read event is simply not triggered > > for the missing packets. It's like they're lost in the wire...like they > > disappeared. > > > > I thought it might be a hardware problem, so I tried it with different > > combinations of bare metal and VMs. I even upgraded my kernel and used > > more recent NIC firmware. No effect at all, so I don't think it's > > hardware or my code. > > > > Anyone have any insight? > > After doing an insane amount of network testing and debugging I > discovered that sending multiple consecutive UDP packets over a loopback > interface or reliable and fast LAN cause the recipient to overflow its > buffer and lose packets. I could be wrong, but this seems to be the > case. I found no problems in my network. > > I inserted a 100 ms delay between packet transmission and this corrected > the issue. Any insight still appreciated, as I may have to differentiate > between LAN clients and WAN clients so the delay is only inserted when > necessary. > > -- > Kevin Fishburne > Eight Virtues > www: http://sales.eightvirtues.com > e-mail: [email protected] > phone: (770) 853-6271 > > > > ------------------------------------------------------------------------------ > Simplify data backup and recovery for your virtual environment with > vRanger. > Installation's a snap, and flexible recovery options mean your data is > safe, > secure and there when you need it. Discover what all the cheering's about. > Get your free trial download today. > http://p.sf.net/sfu/quest-dev2dev2 > _______________________________________________ > Gambas-user mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/gambas-user > ------------------------------------------------------------------------------ Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Discover what all the cheering's about. Get your free trial download today. http://p.sf.net/sfu/quest-dev2dev2 _______________________________________________ Gambas-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/gambas-user
