Main Site Documentation

Show stopper: Lack of solid HttpWebResponse / HttpWebRequest in Fez Connect


#1

This relates to the inability to do high level httpWebRequest reliably from a Panda II with the Fez Connect board.

I have found that I am spending %80 of my time dealing with networking, because I have to use sockets, and I have to build out masses of code to handle all the exceptions, address types, etc.

On Netduino, I spent ZERO time on networking. The native networking just works, works at a high level, and stays out of my way.

We discussed this here:
http://www.tinyclr.com/forum/2/5364/
and here:
http://www.tinyclr.com/forum/2/5313/

I am a hobby dude, with only a couple of hours a day for my embedded project work. I have a couple hundred $ of GHI gear, I hope to build a dozen of my boxes (when I get it done), and I love the support here in the GHI community.

But the networking stuff just doesn’t work, and I do not have days to make the sockets approach solid enough to use in real life. I have documented the issue fully on the thread linked above.

For me to roll out on Panda boards (the path I have been on), we need the high level networking to work %100.

Is there an ETA for this?

Thank you!


#2

I totally agree with you! It also applies to EMX with built-in ethernet. I’ve spent an amazing amount of time to get the WebServer class (that was based on HttpListener) somewhat stable.

Recent use of that class on the www, showed that it even hangs forever, how great is that. Now I totally rewrote the webserver (not online yet) with Sockets instead of the HttpListener object. And I still get strange errors. F.e. I get a 10035 WSAWouldBlock socket error once in a while. And as far as I know the .NET MF doesn’t even expose non-blocking sockets, so how can one ever get the WSAWouldBlock error?

If you ask me, the whole TCP/IP stack contains tons of bugs that need to be solved urgently.


#3

@ Wouter he is using Panda and you are talking about EMX so networking is completely different. On EMX, it is a commercial TCP/IP stack running there so I would be really surprised if it has “tons of bugs”! We have hundreds of customers with thousands of EMX in the field today so I think you comment is not fair. With that said, I know there was many enhancements in NETMF4.2 when it comes to HTTP so things may run smoother once we move to 4.2 in near future.

@ samjones3 no need to create another thread. There is already 2 other threads talking about the same thing. As we said in other threads, we are looking into this.


#4

I agree a bit with Wouter, I also rewrote a http listener based on sockets, but i also wanted to implement websocket support and have fine grain control. Hopefully i will be able to share this websocket code soon.
(see who is faster, me or .net 4.2 :wink: )

@ wouter… Is see socket error 10035 mainly when streaming video.MP4 files and moving back or forward the position slider in a client media player. The player closes the socket at the client side and perform a new http request with other positions from the video file. this abrupt closing generates 10035 at the server side.


#5

@ mrPositive If you see an error then you should report to us and even on the Microsoft forum so we, and Microsoft, can work on the fix.


#6

Sure i will and do, once i am convinced the error is not in my own code :slight_smile:


#7

@ Gus: the HttpListener is in such a condition, that it can’t be used in a final product. It is almost impossible they (Microsoft) have ever tested there implementation. Therefore, I do hope the problem is not with the stack, otherwise the Socket based version will also fail.

Because of the HttpListener problems, I could not propose the NETMF board to the hardware guys at work for a recent web based project.


#8

@ Gus: Sorry, I do not mean to clutter the board. But I needed to call out that networking on Panda is useless for the real world. To me, this means the Panda board (which I really like, generally) is not viable.

I really want to work with GHI gear, but this issue is pushing me back to netduino, which is not where I want to be.

I felt a need to call this issue out as such (e.g. not as a coding question or issue, but as a meta issue with the Panda product line itself).

As far as Panda goes, I think the problem is not related to NETMF at all, as netduino appears to use more NETMF networking code than the Panda world, and netduino does not suffer from this issue.


#9

As said before, GHI is working on making this better, maybe release the HTTP source code. This will take a while, maybe few weeks unfortunately.

Note that our free ebook uses HTTP and we didn’t see any problems so we do not even know if you are doing something wrong or there is a bug in the libs. Maybe try the examples in the book.


#10

Gus,

I wrote a clear example in one of the threads noted above showing that it is a bug in the GHI client side libs that are sensitive to response timing.

The free ebook is great! But it lacks any http client get/put examples, so is not useful for me or for this discussion.

This issue is, I am sorry to say, fully in GHI’s lap.


#11

Gus,
See http://www.tinyclr.com/forum/2/5364/


#12

Here is the source code for GHIElectronics.NETMF.W5100.Http library:
http://netmfw5100http.codeplex.com/


#13

Joe,
Thank you. This will be very helpful.


#14

Total noob question:

How do I use the source?

E.g. I am in VS, I currently use the ghi w5100 library.

How do I instead use these sources?


#15

@ samjones3
You can’t use the source that way.
You can go to the codeplex site (follow the link from Joe), download the source code to your computer, open the solution in VS, and examine the code.


#16

@ jasdev,
Thanks. That means I have nothing to contribute… no way I could find such an issue via static code analysis. If I were to have a prayer of finding the problem in the ghi libs, I would need to be able to consume them and debug (and note, this issue is far far outside my abilities and available time).


#17

@ samjones: can you try the HttpServer class on your devices from here: http://code.tinyclr.com/project/243/webserver-extension-for-fez-cobra/

Since it now uses sockets it should be possible to use it on non-EMX based devices. You might need to change some ‘usings’


#18

@ Wouter: Code for fez cobra is compatible with Panda II and the wiz 5100 ethernet?

But wait… I can’t use a web server piece… I am writing a web CLIENT


#19

Oh, idd. Can’t you use the Socket class for you webclient instead of the HttpWebxxx classes?


#20

@ Wouter: I am using sockets, but am having to do a lot of work and low level work to make the socket examples give simple, reliable functionality, it is taking too much time. (I am a hobbyist)