sgstair

Correction: It's not currently possible to communicate between two DSes without an access point acting as an intermediary. There is no need for a PC for communication. -Stephen

afaik the latest devkitpro installer doesn't include the latest version, though it will sometime in the near future. -Stephen

Hiya, well, there are some things you really should know about TCP; Firstly, you should not treat it as a packeted format, it's a stream format, so the only requirement is that bytes come out of the "pipe" on the destination side in the same order that they were put in on the source. Additionally though, you're not checking the return value of the "send" function, as it returns the number of bytes that have been sent, you must call the function again with the remaining data if the returned value does not match the size of the data you are trying to send. -Stephen

Ok, good luck - If I think of anything else it might be I'll post it here. -Stephen

Ok, to address a few issues here... No, it's not odd at all for the association to work but the sending/receiving to not work - the reason for this is 802.11 is handled almost 100% purely in the arm7, and anything on top of that (DHCP, UDP, TCP, ICMP) are all handled in the arm9. The transport mechanism for moving data from arm7 to arm9 and back is a large circular buffer, which is accessed without cache in the arm9 (unless you've managed to cache memory mirrors, which would royally screw the arm9 lib up) The 3 major points of failure for the wifi lib then are as follows: 1) malloc/free not working correctly 2) update/fifo functions not setup correctly (Wifi_Timer should be called periodically, and a fifo message interrupt would be very nice, though not essential) 3) (very rare to see this happen, unless you play with the memory protection) the "uncached memory mirror" might be cached, which would throw the lib into any number of crazy erroneous states. Those are just the big 3 points of failure, and I'd expect the lib to be able to work outside of libnds with only minor modification, so I'm interested to hear what you may have encountered. -Stephen (other side notes - using arm946e-s is more accurate, but arm9tdmi should be compatible with the cpu. - the malloc/free only need to be safe if you are using other code that malloc's or free's)

No, you don't need to buy anything to make it work, especially if the official stuff already works with it. If the wifi lib doesn't work for you but the official stuff does for whatever reason, I'd like to know a bit more about your situation. -Stpehen

(To clarify - this thread isn't very useful, the initial post was incomplete/garbled for whatever reason, and we've since talked via email to figure out the problems.) -Stephen

Have you tested your malloc/free functions at all? I can't be sure because I really have no idea what sort of environment you're in, however the problems you're having do sound like they are related to memory allocation. -Stephen

Captain'Cap: It's one of those things that's really hard to do, it is planned for the future but it's not possible with the current version of the lib. -Stephen

ssj9vegeto0: you've played on the official wifi? if so, the settings should already be in your DS, and the wifi lib should be able to automatically connect; If it's still not working, there are a few reasons why that might be, but for the most part if it works with the nintendo games, it'll work with homebrew wifi too. -Stephen

The socket system in general does not make any requriements on how quickly data is sent, but in my library they are sent as soon as is possible (usually within about 39ms, often sooner) So, if you're receiving stuff clumped together, it's either the wifi system being slow/unreliable and the wifi lib having to retransmit a lot, or it's possible your application is not receiving the data fast enough (due to some timing issue or something), and that's the reason for your data being clumped together. As far as how sockets work - TCP is pretty simple, only 2 things you need to know. (1) it's a "stream", bytes put in are taken out in the same order they're put in (2) TCP sockets, as all network systems, are designed to send data as quickly as possible; so there isn't any sort of delay beyond a few milliseconds potentially, for optimization if multiple small groups of bytes are being sent. -Stephen

(This is something I'm working on - I expect to be able to connect to the official USB stick soon...) -Stephen

Yes, this is indeed normal behavior - TCP is a stream protocol, so individual packets doen't matter; TCP only guarantees that the data you get out at the destination will be in the same order as you put it in at the source. If you want to, you can create a packet-like format, many programs do this because they'd rather have packet-style data instead of everything mashed together. One simple way to do this, in your case, would just be to insert line breaks after every command, then process one line at a time on the server when receiving data. Good luck, -Stephen

first of all 11==EWOULDBLOCK - of course it's going to be 11. Secondly, see the code loop I posted - though I didn't explicitly make mention of it, it is quite possible to do other things than check the accept() in the while(1) or in a similar construct - hope this gives you an idea of how to do it. don't use select() for this, of course.... though accept() in blocking mode should eventually return if you connect to the socket. Certainly use the non-blocking mode, but try to use it similar to a way I demonstrated. -Stephen

not via setsockopt, but broadcast addresses should work. -Stephen

I'm thinking of why this might be happening; and I've only come up with 2 solutions so far... either (1) you're missing or misreporting something, or (2) your router is coded poorly and freezes network if a wireless connection drops. Have you looked for new firmware or anything? -Stephen

Some of both - there are several working on them at the moment. -Stephen

Ok, firstly; since you've set the socket to nonblocking mode, all ordinarily blocking calls (including accept()) will return immediately, so you must wait in a loop if you want to use them; I'm assuming you are deallocating the socket right after it "fails to accept()", so of course the pc won't connect to it See the following: int newsock=0; if(listensock) { while(1) { newsock = accept(listensock,(sockaddr *)&sa,&dummy); if(newsock>0) break; if(errno!=EWOULDBLOCK) { // handle a more "fatal" error } } // shiny new socket in newsock, ready to be used. } Bug me if you need more infos. -Stephen

Well, I know for a fact that creating multiple sockets isn't a problem, and the process to create a UDP or TCP socket is quite nearly identical, so it's unlikely that's your problem. It's very unlikely that your problem is that the udp socket is becoming invalid, it is more likely a polling problem or some sort of stupid mistake :\ I'd check to be 100% sure you're not overwriting your socket handle with the TCP one, or doing anything else similarly silly. Other than that, I'm not sure - but I'm pretty sure it's not the lib's fault. -Stephen

details are available in several locations, but I'm sure a lot more will be available soon - yes, some info I get from IRC, but I have other sources too... -Stephen

If you're worried about latency, you should certainly use a custom realtime UDP protocol - you can be guaranteed latency under 30ms for small messages unless more than x number of retries have to be made (depending on the size of the packet, and other factors) Data is sent at 2mbit, which is 2 million bits per second exactly; If you'd like exact timing information, see the following data: --- 2mbit is exactly 2 million bits per second, or half a microsecond per bit. The following elements are present in a UDP packet: (802.11 phy overhead:) 96 bits plcp preamble 32 bits plcp header (total of 128 bits / 16 bytes) (802.11 protocol overhead:) 24 bytes 802.11 header 4 bytes extra (for WEP IV) (now, actual data:) 8 bytes LLC header 20 bytes IP header 8 bytes UDP header x bytes data (your data goes here) 4 bytes 802.11 CRC32 Soooo, adding all that together gets us: 84+x bytes (where x is the number of bytes in your packet) which is 672+8x bits (or 336 + 4x microseconds) as you can see, 802.11 is more than capable of delivering a message within 30ms, but the question is more one of whether the message gets received TCP is presently set up for reliable operation over long distances, so it's really not ideal for this sort of application; though this is one area I plan to improve in the future. Anyway, good luck -Stephen

A custom retransmitting UDP protocol should be sufficient for this sort of thing, and TCP will do a pretty good job too - for local connections you should be able to get a minimum of 2 to 3 times the performance necessary, even with a lossy connection. That being said, 11% packet loss isn't typical in my experience, and if it does occur, it's likely an issue with signal strength and distance between the DS and router/AP (actual wifi speed is approximately 2mbit, I've achieved transfer rates through tcp of roughly 80kbyte/sec - and this will improve with future libraries) -Stephen

Yes, actually this is a problem that will be addressed before too long... more details later. -Stephen

BasiX: this is likely due to lack of shared key authentication support, or possibly because your AP is not broadcasting it's SSID - both of these issues are in the pipeline and will be resolved soon though! -Stephen

khalil: could be a failed connection due to lack of shared key authentication support (mis-stated in previous posts, heh), or because your access point isn't broadcasting a SSID. Beyond that it's hard to tell -Stephen