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
