send with big buffer

laser
Posts: 17
Joined: Sat Aug 14, 2010 5:49 am

Re: send with big buffer

Post by laser » Fri Aug 27, 2010 8:30 am

I revisited this problem today and have done some more testing and have some more clues to offer to help fix the problem.

1420 bytes seems to be the upper limit to a successful socket send and close.
Sending 1421 bytes or more and the socket will signal a closed connection to the other side before the full data is sent.
Putting delays in before closing the socket only causes the socket to fail to signal the other end the connection has been closed.
Sending large amounts of data (e.g. retrieving a file using my uFTP server) and is will always be truncated on a multiple of 1420 bytes.
I guess this is because 1420 bytes is the packet size being used for wifi.

41 bytes seems to be the lower limit to a successful socket send and close.
Sending 40 bytes or less will cause the socket to fail to signal the other end the connection has been closed.

Remember, the above test is based on sending data and then closing the socket. Keeping the socket open and sending data appears to be okay.
Therefore it is confirmed this is a closesocket() problem not send(). This is a problem with an FTP server implementation as the closing of a connection is used to signal the client "end of data".
If, when sending data and the other side knows exactly how much data to expect, you will probably not see this issue with closesocket().

So as a work around for my uFTP server program I am now padding empty directory lists to 50 bytes and padding directory lists larger than 1420 bytes with 7100 bytes of empty lines.
7100 bytes is equal to 5 x 1420 bytes. After some testing this seems to be right amount of padding to successfully get the unpadded part of the directory list through to the FTP client.
Fortunately the FTP client knows to ignore the empty lines of padding and display the real directory list. Well, at least this was the case with the "Core FTP LE" Window's application I was using.

This seems to work for now and I have up loaded this version to the "contributions" area of this forum.

Feel free to distribute this source as an example for devkitARM. I give it freely.

Please ensure the correct people (I think you said Steven?) get the above information to help fix the closesocket() function.

Many thanks,

laser

WinterMute
Site Admin
Posts: 1845
Joined: Tue Aug 09, 2005 3:21 am
Location: UK
Contact:

Re: send with big buffer

Post by WinterMute » Fri Aug 27, 2010 10:19 am

Did you try 1461 bytes by any chance?
Help keep devkitPro toolchains free, Donate today

Personal Blog

laser
Posts: 17
Joined: Sat Aug 14, 2010 5:49 am

Re: send with big buffer

Post by laser » Sat Aug 28, 2010 12:37 pm

I just tried 1461 bytes and it got truncated to 1420 bytes.

z.g
Posts: 22
Joined: Thu Dec 18, 2008 8:33 pm

Re: send with big buffer

Post by z.g » Thu Sep 02, 2010 8:17 am

try use instead

Code: Select all

shutdown(Socket, SHUT_RDWR);
closesocket(Socket);
this one

Code: Select all

shutdown(Socket,0);
for(int i=0;i<60;i++) swiWaitForVBlank();
closesocket(Socket);
i found this snippet here at forum. this is dont' solve problem to perfect state but to usable :)

laser
Posts: 17
Joined: Sat Aug 14, 2010 5:49 am

Re: send with big buffer

Post by laser » Fri Sep 03, 2010 2:07 pm

Thanks z.g!!

Yes, putting a 1 second delay in before closesocket() works!! Well done. :)

I did try this before BUT I was putting the delays in before the shutdown() function not before the closesocket(). Putting the delay in before shutdown() causes the socket to fail to signal the other end the connection has closed. But putting the delay in before closesocket() works.

Thank you very much for this work around. I have updated my uFTP server source code and build to v0.70 now in the contributions section. File retrieves now work! Woot! :)

laser

Post Reply

Who is online

Users browsing this forum: No registered users and 11 guests