[Gambas-user] odd gb3 issue

[Kevin Fishburne]

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: sales at ...1887...
phone: (770) 853-6271