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
send with big buffer
-
- Site Admin
- Posts: 1986
- Joined: Tue Aug 09, 2005 3:21 am
- Location: UK
- Contact:
Re: send with big buffer
Did you try 1461 bytes by any chance?
Re: send with big buffer
I just tried 1461 bytes and it got truncated to 1420 bytes.
Re: send with big buffer
try use instead
this one
i found this snippet here at forum. this is dont' solve problem to perfect state but to usable
Code: Select all
shutdown(Socket, SHUT_RDWR);
closesocket(Socket);
Code: Select all
shutdown(Socket,0);
for(int i=0;i<60;i++) swiWaitForVBlank();
closesocket(Socket);
Re: send with big buffer
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
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
Who is online
Users browsing this forum: Ahrefs [Bot] and 3 guests