Hi,
first off, I love the Playdate and the addition of the new networking APIs — it's really fun developing on it.
While working on a small online game (in C), I encountered the issue that the Playdate stops receiving data from a server I'm connected to via a TCP socket after running for a short time, and eventually crashes. The same setup works fine in the Simulator.
To reproduce, I built a simple test app:
- The Playdate sends a newline-terminated "PING" message to a TCP server ~10 times per second
- The server responds with "PONG" each time.
- Everything works great for a while, then the Playdate stops receiving any data but still sends out "PING" messages
- Eventually, the connection stalls and crashes the app.
I used Wireshark to debug the TCP stream (please see the attached screenshot, the server is on port 24567), I observed the following:
The server occasionally retransmits a packet with the same TCP sequence number and same payload length (Seq=940).
After this retransmission, the Playdate only acknowledges the data that was sent before (in this case the first 940 Bytes)
The server continues (re-)transmitting until it eventually resets the connection.
The Playdate does not appear to detect the reset — the SDK callback for a closed connection isn't triggered — and keeps sending "PING" messages until the write operation stalls and the app crashes.
I tried various mitigations like reducing the message frequency, enabling/disabling Nagle’s algorithm, and inserting delays — they delay the issue but don’t prevent it. Although in the real game I don't have nearly that frequency that I have in my test app.
I'm not an expert for the TCP protocol by any means, but it seems to me, that there might be a problem in the implementation of the stack that occurs when packages are resent or composed.
Note: This issue does not occur in the (Windows) Simulator — only on actual hardware.
Please let me know if I can provide any additional information.
Thanks again for the amazing platform, I hope this helps
