devkitPro

I reread your original message - is there a problem with the data being sent and received or are you just asking about duplicate packets that you see with a sniffer?

Yes I have problems with big packets, the send returns a correct value, but the FB server receives invalid request. Through a sniffer there are 2 o 3 packets, with Wintemute's code it works better, but the packets content are the same.
There is always POST .. HTTP/1.1 (the first packet) etc etc. I tried to insert some sleep, but it works well sometimes.

Excuse me again for my English, thanks.

Grasping at straws, but did you look at the headers or responses from the server that may indicate the connection was terminated prematurely?

Remove PAlib from your system and reinstall the latest tools, until then there will be no support for you here. Basically we can't guarantee *anything* will work as expected when you use that library.

http://wiki.devkitpro.org/index.php/PAlib

Now Im using the select before the send and it works well, but I have again problems.

Hi All,

I am having this same problem too and came here for a solution.

I have writen a small FTP server for the DS. I will upload it for all to use and enjoy once I fix this send problem.

I'll try to explain the problem as best as I can. I am a self taught programmer so be gental.

The short descrption of the problem is send() has trouble with sending data larger than say 10K bytes. Short burst of data come through as expected but larger bursts of data either lock up on the socket level or close the socket connection earily and the receiver gets a truncated version of the data sent.

My send buffer is allocated by the "new" command (which I assume returns an int alligned memory pointer, which should hopfully elliminate any allignment problem mentioned in this message thread before.)

Here is the guts of my send() loop:

On large data sends the above will either never return from the send() function or it will return with no error and the expected accumulated byte count BUT the receiver gets a truncated version of the data sent because the socket closed early. I assume the send() function is "blocking" by default so there should be no need to check all data is sent before closing the socket right?

Many thanks for your help,

laser

I'm no dswifi expert or anything. I know, however, that the DS hardware is rather limited in many ways, compared to, say, modern PCs, notebooks, or even smartphones. Evidently, there is some kind of bug in the dswifi library, and it should be corrected somehow; however, it looks like we might be hitting some kind of hardware limit in here. Even if the bug is corrected, does it make sense to send *that* much data in one go? Shouldn't you be limiting the size of the packets you sent through the socket, *even* if the library itself does some of the work?

Just my 0.02€ .

Thank you for your reply. I have tried limiting the data size to as little as 100 bytes per call to send() and it still truncates the data on the other side. I have also tried various delays in the send loop and delays before calling shutdown() / closesocket() yet still have problems. Bare in mind that with an FTP server implementation you need to have 2 active sockets at the same time so maybe this is showing a problem with the wifi lib? I think it is best I upload the code "as is" to help the devkitpro team debug the wifi lib. The server works well for sending files to the DS and you can start using it now. I’m getting up to 80KB/s sending to the DS. The server will have problems retrieving files from the DS and also have problems with long directory lists (eg. your games directory ) because of the send() bug. Enjoy.

Many thanks,

laser

Edit: Tried to update the ftp file attachment to new version (v0.40) but I get upload errors. Will try again later...

Error "Could not upload attachment to ./files/3562_cb1d88fad2c3cf911ad9cc45bcdf9411."

It's not a send bug, it's a closesocket bug - basically the socket is being closed while there's still data to send, you can work around that by inserting a delay after send completion before the closesocket. I've spoken to sgstair about this and he's of the opinion that dswifi needs rewritten ( the update he's been talking about for quite a while ). The dilemma now is how best to improve dswifi and/or encourage Steve to get the update done.

For what it's worth, there's no particular reason to limit the data sent at one time as long as you make sure to take account of send's return value and act accordingly.

Hi WinterMute,

Sorry for the slow response. I did respond a few days ago but the message got deleted by mistake by the admin here. I'll try to remember what I wrote...

I agree it is a closesocket() bug not send(). Believe me, I experimented with many delays in the send loop and before closing the socket but still had problems. When I tried a 30 second delay before calling shutdown() and closesocket() I found the DS failed to signal the other end that the connection had closed. The DS also fails to signal the other end that the connection has closed if you send less than 40 bytes just before calling closesocket(). I hope these extra clues will help fix the wifi lib.

You have my source code now so this should make it easier to track down the bug. Also feel free to release my code as an example for devkitPro - maybe best wait till after the wifi lib is fixed.

... or do I need to upload the source somewhere else for everyone to share? Not sure what is best. Please advise.

Many thanks,

laser