devkitPro

Is there an existing define or some other construct available that I can use to select which code to use to target either the DS or my local Linux system? I've been using my own NDS define: #ifdef NDS int caddrlen; /* client address length */ #else socklen_t caddrlen; /* client address length ...

Your findings for when a DS game is running mirrors the behavior of a normal DS.

When in homebrew, though, swapping the card does not affect the running program. Several programs that deal with the DS card (including my old savehost) depend on this, actually.

Here's where I may or may not be able to help out, and my interest. I started writing a program called savehost that was intended to provide access to the save chip (arbitrary reads/writes and card ID) to PC-based server programs. Beyond backup/restore this would also permit people who can't write ...

Third, DS library transmits packets with 1420 bytes of data, this produces packets with near maximum ethernet packet size. This makes them more unreliable than most packets. (Most TCP libs use packet sizes of closer to 500 bytes data, for this reason). Out of curiosity—have you ever tried a 500-odd ...

Well, not precisely. MTU/MRU dictate the maximum size of a single packet. MTU is the biggest packet that can be sent—this is where the 1420-byte TCP sends I got was coming from (or at least I believe so) since the MTU appears to be 1460 and the IP+TCP headers add up to 40 bytes if TCP options aren't ...

As I understand it, the MTU for dswifi is 1460 (SGIP_MTU_OVERRIDE in sgIP_Config.h).

Is the MRU the same? More to the point, what is the biggest UDP payload I can expect to recvfrom() (MRU - IP - UDP)?

(edited; MRU doesn't include Ethernet headers)

sgstair, while I have your attention and to give myself another shot at crackpottery did you have any ideas about the TCP problem? It's a different issue than the hang.

Check the first 5 posts: http://forums.devkitpro.org/viewtopic.php?f=23&t=1425

By the way this patch doesn't purport to (nor does it, in fact) fix the TCP congestion problem. Though it seems that at least experimentally, it means it doesn't eventually hang anymore. I certainly haven't given it the hardcore testing I gave the UDP code.

With all due humility, because yes, I certainly am really green with this stuff: Please go back and reread the fifo code. interrupts are always disabled when callback functions are called, this was a very important design feature to allow stuff like this to work properly. This is what I'm looking at ...

Patch submitted: https://sourceforge.net/tracker/?func=d ... tid=668553

Thanks for all your help, everyone!