sgIP_TCP: either buggy or awkward

L'implémentation de TCP sur DS me surprend un peu, et pourrait bien expliquer les "fuites de données" observées pendant les transfers DS->PC. Ou les "deadlocks" qui se produisent en cours de transmission". Sur la sellette, la gestion des ACK, ces signaux qui indiquent qu'un paquet a bien été reçu.
I've never seen a TCP implementation behaving like dswifi, and chances are that it might explain the "data losses" and deadlocks I'm experiencing with runme uploads recently. I've compared my version (2005-2006) against the latest version in devkitpro and did not noticed significant changes in the TCP protocol handling.
What looks odd is the management of ACKnowledgements, those little packets that just tell the sender that "okay, i've got your data, go ahead". First, the DS seems to acknowledge everything, including ACKs from the PC. Moreover, it doesn't look to take all ACKs into account when sending a packet, but only the oldest one ...

• d'abord, la DS émet un ACK même pour un paquet qui ne contenait aucune donnée (un ACK du PC, par exemple)
• ensuite, elle ne semble pas tenir compte du dernier ACK reçu au moment de renvoyer des données, si bien que la DS réémet des données que le PC a déjà acquittées.
  

Mon analyse est encore un peu imparfaite (la DS a-t-elle ou non reçu les ACK du PC ? difficile à dire)
En regardant les lignes 4060 et 4061 de la capture, il est évident que la DS a reçu un ack du PC, puisque le n° de séquence évolue pour la 1ere fois depuis la ligne 4050, mais alors que le PC vient de valider tous les bytes jusqu'à 101796 (compris), la DS retransmet tout de même à partir de 100633 (ç.a.d. seulement 256 bytes plus loin que le packet précédent).

Je travaille toujours avec la version 2005-2006 de la bibliothèque dswifi de Stephen Stair. Je devrais sans doute tenter une mise à jour.

edit: the third pass on my own code revealed a subtle error on how I handled "EWOULDBLOCK" when uploading from a file. sgIP_TCP thus did not lose any data and is just a bit awkward. Sgstair himself took the time to point me out that there are much more levels of queueing in the DS networking stack (including hardware buffers), which sheds another light on the problem ... I think I can live with small performance issues. But I'll keep on investigating the issue anyway.