Connection Reset By Peer Error

[obsess5]

I have a consistent problem transferring data wirelessly from a Nintendo DS to a PC. (Data transfers in the reverse direction are not a problem.) The NDS writes out the data and then closes the socket. However, the receiving program on the PC is notified of the socket closure by the DS before all the data has been transferred. My setup is as follows:

 

NDS <-- wireless --> Router/AP <-- wired --> PCs (Windows, Linux)

The program running on the NDS is a tiny FTP/HTTP server ported from UNIX; it uses standard BSD socket calls with close() changed to closesocket(). The original program didn't perform shutdown()s on sockets, but adding shutdown()s before the close()s doesn't help. The main() function was modified to initially call consoleDemoInit(), fatInitDefault(), and Wifi_InitDefault(WFC_CONNECT).

 

Problem:

 

I see the problem whenever a temporary data connection is established to send data to a receiver on the PC:

1. FTP client on the PC reads a directory listing from the NDS.
   
2. FTP client on the PC retrieves a file from the NDS.
   
3. HTTP client on the PC receives a web page from the NDS.
   

In all 3 cases, the full data transfer is interrupted midway on the PC side by notification that the socket has been closed. On a Windows PC, the client's request just fails. Under Linux, I get a "Connection reset by peer" error message (when using a command-line client).

 

Hypothesis:

 

Some internet research on the Linux error message suggests that the problem is related to a firewall (in the Verizon FIOS router/AP?). Following that line of thinking, my guess is that the NDS connects to the router/AP, sends all the data, and then closes the router connection. The router hasn't fully transferred all the data on to the PC when it detects the closed connection; the remaining data is discarded and the PC is abruptly notified that the connection has been closed.

 

DSFTP Works:

 

I have Bjorn Gieslers' excellent DSFTP server on my NDS too. DSFTP works flawlessly for directory listings and file retrievals. File transfers from the PC to the NDS work also, although I'm seeing a 5x difference in the transfer rate between my program and DSFTP: 50KB/second versus 10KB/second, respectively. Similar slowdowns in the directory listings and file retrievals could account for them completing successfully. The source code for Bjorn's FTP library is not available, so I don't know how he accomplishes this. I used objdump to disassemble parts of his library's object code, but, taking into account that I don't know ARM assembly language, I didn't notice any out-of-the-ordinary system calls that might be the key to fixing my problem.

 

Help!

 

Does anyone have some ideas on what's causing my problem and how to fix it?

 

Or is it just a matter of putting in long enough delays before I close a socket? If so, what's the easiest way to do this? The UNIX sleep() and nanosleep() functions declared in the devkitARM include files are not present in the GNU libraries.

 

Thanks!

[sgstair]

Yes, this is a known issue. The DS library closesocket() abruptly terminates the connection rather than allowing it to wait to complete. This will be fixed in a future version - in the meantime though, it's suggested to use shutdown, and wait for the other end to close the socket before closing it. (use recv() and wait for it to return 0)

There isn't a better solution at this time

 

-Stephen

[obsess5]

Wow! Many thanks, Stephen, for the quick response and the workaround you suggested!