gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

DS development > Flooding the Wi-Fi channel?

#140666 - Jesse - Wed Sep 19, 2007 12:00 am

When sending a larger amount of data over Wi-Fi to a server ::send seems to cause flooding of the radio channel. This disrupts the Wi-Fi for all my equipment as well. I'm just using normal ::send and I've tried both blocking and non-blocking mode. If I make sure not to go over the "speedlimit" by waiting a few VBlank for each kB I send everything is well, but as soon as I send too much everything seems to be clogged up and while it continues to send, it's going very slow.

Last edited by Jesse on Wed Sep 19, 2007 7:55 pm; edited 2 times in total

#140707 - jetboy - Wed Sep 19, 2007 11:09 am

And LAN after the wifi router gets flooded too.
I killed the net in my company by trying to send some data with Jesse's softweare.
The line is afaik 8Megabits up/down @_@.
All people in the building lost conectivity when i was sending anything.
_________________
Colors! gallery -> http://colors.collectingsmiles.com
Any questions? Try http://colors.collectingsmiles.com/faq.php first, or official forums http://forum.brombra.net

#140714 - Jesse - Wed Sep 19, 2007 1:46 pm

I found the problem for this. My Arm9/Arm7 communication was all messed up. It's wonder it worked in the first place.

#140715 - pas - Wed Sep 19, 2007 1:47 pm

What prog are you talking about ? *wants do a lil flooding * ^^

#140717 - Jesse - Wed Sep 19, 2007 1:54 pm

It's easy. Just write a wifi-app and mess up your code "just enough". :)

#140720 - Lynx - Wed Sep 19, 2007 2:24 pm

Yeah.. even I can do that!

Or do you have to be able to write good code for it to be messed up?
_________________
NDS Homebrew Roms & Reviews

#140782 - Jesse - Wed Sep 19, 2007 7:55 pm

I was a bit premature in declaring this solved. I just released a new version of Colors!, and a lot of people seem to have this problem. I though I had fixed it, since it dissapeared for me after fixing my arm7-arm9 communication and updating to the CVS version of dswifi (which also made my DS Lite behave much better). Apparently it wasn't fixed all the way. Anyone who has noticed this behaviour?

#141339 - jetboy - Mon Sep 24, 2007 7:45 am

Still anyone dont have a slightest idea what might be causing this?
Tepples? You usually have solutions for everything... I count on you :)
_________________
Colors! gallery -> http://colors.collectingsmiles.com
Any questions? Try http://colors.collectingsmiles.com/faq.php first, or official forums http://forum.brombra.net

#141837 - Jesse - Sun Sep 30, 2007 6:25 pm

I'm still stuck at this. melw was gracious enough to help me out, and we managed to narrowed down the problem a bit. To exclude mistakes from my side regarding Wi-Fi-setup and Arm7/Arm9 communication, I hijacked a test-function in wifi_lib_test. That didn't make any difference. As soon as I send too much data at the same time, the network chokes. It's a bit random and appears around 50% here, but I think it was more consistent for melw.

Here is the code from my modified wifi_lib_test:

Code:
void Do_Play_TCPConnect() {
   struct hostent *pHostInfo = gethostbyname("80.244.71.104");

   int Socket = socket(AF_INET, SOCK_STREAM, 0);
   if(Socket < 0)
      Error("Could not create socket");

   struct sockaddr_in ServerAddress;
   ServerAddress.sin_family = pHostInfo->h_addrtype;
   memcpy((char *)&ServerAddress.sin_addr.s_addr, pHostInfo->h_addr_list[0], pHostInfo->h_length);
   ServerAddress.sin_port = htons(27691);
   if(connect(Socket, (struct sockaddr *) &ServerAddress, sizeof(ServerAddress)) < 0)
      Error("Failed to connect");

   int Size = 32 * 1024;
   char *pBuf = malloc(Size);
   memset(pBuf, 0, Size);

   const int PacketSize = 4096;
   int BytesLeft = Size;
   while(BytesLeft > 0)
   {
      int Len = BytesLeft;
      if(Len > PacketSize)
         Len = PacketSize;
      int Res = send(Socket, pBuf + Size - BytesLeft, Len, 0);
      if(Res > 0)
      {
         BytesLeft -= Res;
         char buf[256];
         sprintf(buf, "Sent %i bytes", Res);
         printtop(buf);
      }
   }

   free(pBuf);
   printtop("Done");
}


I can get around the problem by waiting a few vBlanks for each ::send, but how many that is needed seems to differ from DS to DS (probably connection to connection) and of course slows things down considerably. I also tried using ::select to make sure only to call ::send when the buffer was ready, but ::select doesn't seem to be implemented yet.

Is there something wrong with my code? Does anyone have any ideas of what I could try?
_________________
http://www.collectingsmiles.com/colors & http://www.collectingsmiles.com/hyena

#141845 - jetboy - Sun Sep 30, 2007 8:49 pm

Just guessing.

Isnt it like that you try to send and never check if the data was already sent, then try to send another packet again? I dont know the inner working of the lib, but it could mean that the packet is never completely sent, or the checksums dont match or possibly any other unfriendly scenario...
_________________
Colors! gallery -> http://colors.collectingsmiles.com
Any questions? Try http://colors.collectingsmiles.com/faq.php first, or official forums http://forum.brombra.net

#141846 - Jesse - Sun Sep 30, 2007 8:50 pm

In an bold move I managed to track down the man responsible, Sgstair. Sadly, we didn't really get any new info. It seems to be a problem with dswifi and it wasn't really possible to check if there is outgoing data in the buffer with the current lib. I did get a suggestion to manually send a snippet of data back from the server on regular intervals, which would allow me to make sure I don't send too much data to clog things up.
_________________
http://www.collectingsmiles.com/colors & http://www.collectingsmiles.com/hyena


Last edited by Jesse on Sun Sep 30, 2007 8:55 pm; edited 3 times in total

#141848 - Jesse - Sun Sep 30, 2007 8:53 pm

jetboy wrote:
Isnt it like that you try to send and never check if the data was already sent, then try to send another packet again?

Yes, and that is supposed to work using TCP. :)
But that is probably related to the problem and it's just too bad there is no way to know if the data was properly sent.
_________________
http://www.collectingsmiles.com/colors & http://www.collectingsmiles.com/hyena

#141910 - HyperHacker - Mon Oct 01, 2007 2:41 pm

The impression I got from his post was that you're trying to send one packet before the hardware has finished sending the previous one, confusing it and/or garbling the packets. Is that possible?
_________________
I'm a PSP hacker now, but I still <3 DS.

#141915 - Jesse - Mon Oct 01, 2007 5:06 pm

HyperHacker wrote:
The impression I got from his post was that you're trying to send one packet before the hardware has finished sending the previous one, confusing it and/or garbling the packets. Is that possible?

Ah. No, that's not really the case. Since I only use the high-level functions, I shouldn't have to worry about sending too much data. Depending on if I've set the socket to blocking or non-blocking, ::send will either wait until there is room in the outgoing buffers, or return with an error if there is no room. Also, since I have no way of checking the buffers manually, I couldn't do it any other way.
_________________
http://www.collectingsmiles.com/colors & http://www.collectingsmiles.com/hyena