I am seeing another needed improvement. The while loop needs a sleep if it will be active for a long time.
@ samjones3
I don’t know how long it will take GHI to implement the proper fix (which impacts Socket.Receive and all the things that use it), but in the meantime with the code that they have provided, you can get HttpWebRequest to work properly.
- Get the source code package from the CodePlex link in the first post of this thread.
- Extract the zip file to your projects folder.
- Open the SLN file.
- Project --> GHIElectronics.NETMF.W5100.Http Properties… --> Assembly Information… --> Assembly version: minor number to 1
File version: minor number to 1 - Open NetworkStream.cs
- Go to line 84 to find the Read(byte[] buffer, int offset, int count) method
- Go to the end of the method about line 111.
change this line
return this._socket.Receive(buffer, offset, count, SocketFlags.None);
to this:
int currentTimeout = this._socket.ReceiveTimeout;
this._socket.ReceiveTimeout = currentTimeout * 1000;
int retValue = this._socket.Receive(buffer, offset, count, SocketFlags.None);
this._socket.ReceiveTimeout = currentTimeout;
return retValue;
- Rebuild the solution (probably should do this both for debug and release)
- In your other project, remove the reference to GHIElectronics.NETMF.W5100.Http
- Add reference --> Browse --> find the DLL that you created in step 8.
- Build this project
- Run it
that should solve the too short timeout problem. The reason this problem isn’t more widespread, is because the sample code for sockets usually shows checking Socket.Available and waiting till something is available and/or using Socket.Poll with the correct factor for converting to microseconds.
@ Frogmore:
You are my hero.
Thank you very much for the detailed steps (I need em, but they look totally doable).
It will be a couple of days before I get back to this area, but I will be there RSN !
Thank you!
@ Frogmore: Thank you again, but bad news.
I followed all your steps carefully, and had no trouble implementing every step. However the final result is the same: NUL result on the response.
HttpWebResponse is null (or has null elements) and throws an exception.
The same code works correctly on the Netduino platform.
I have made sure that the project reference the dll I built.
I can send the project privately to you. The url being hit is up in the cloud, but I should not publish.
@ samjones3
My guess is that your project is not actually using the new code. To verify, you can add a Debug.Print() to line before the one you changed. It doesn’t matter what you have it print. If it prints something, then you know you are executing that code. If it doesn’t print then you are still using the standard SDK code. You will need to add a reference to Microsoft.SPOT.Native and remember that Debug.Print is in Microsoft.SPOT. So either add a using statement at the top or fully qualify it.
@ Frogmore: Fair call. I followed your suggestion and added a debug print as shown below.
In the below shot, you can see that this is executing, and the exception is still thrown.
Microsoft.SPOT.Debug.Print("!!! modded per http://tinyclr.com/forum/2/5565/#/2/ !!! ");
int currentTimeout = this._socket.ReceiveTimeout;
this._socket.ReceiveTimeout = currentTimeout * 1000;
int retValue = this._socket.Receive(buffer, offset, count, SocketFlags.None);
this._socket.ReceiveTimeout = currentTimeout;
return retValue;
@ samjones3
That is strange. You can send me the project and I can try it here. There must be something else that is also not working correctly. I am in the chat now.
@ frogmore: Sorry, I went to bed… let’s try to sync up! (it is 12:45 pm pacific now, and I think I will be at PC for a few hrs)
@ Frogmore: Thanks a lot for the great help. Recv() has been fix and it will be available in the next release.
Do you like to be added to http://netmfw5100http.codeplex.com/ as a contributor? This way you can add the fixes to HTTP library yourself.
That’s fine if you are not interested in that. I can add the fix. But I lost track of what the issue and the proposed fix are. Could you please post that at the libraries codeplex issue tracker?
@ Joe: Thank you for the note. I added the open issue to the codeplex tracker.
@ Frogmore: We don’t need this anymore if we got the recv() fixed, do we?
string line;
do
{
line = inStream.Read_HTTP_Line(maxHTTPLineLength).Trim();
Debug.Print("Read some stuff: " + line.Length.ToString());
} while (line.Length == 0);
@ Joe,
If recv() is fixed, the changes I made to the HTTP library are not needed. They were there to work around the underlying issue with the socket code. Did you do a search for other instances of Socket.Poll() to make sure they did not have the same mistake of using milliseconds instead of microseconds?
Yes I did and found couple. 
Is this fix set going to make it into the (really close now) SDK release ?