Bug in NETMF 4.1 HttpListener

NETMF & Gadgeteer
1

Hi,

After alot of investigration on different forums and revers engineering with Red Gate Reflector it is clear for me that there is a bug in the HttpListener in the NETMF 4.1

Eksample:

HttpListener listener;
HttpListenerContext context;

listener = new HttpListener(“http”, port);
listener.Start();

context = listener.GetContext();

The get GetContext() hides a Socket, the Socket is not released on context.Close() because of the Linger. And the Socket is defined as private, so one cannot call the socket properties and add

Socket.SetSocketOption(SocketOptionLevel.Socket, SocketOptionName.Linger, -2);

Which will release the Socket on Close, say no Linger.

The HTTPListener therefor eats Sockets and stops when 128 Sockets is used.

The full framework has methods to deal with this - NETMF has not.

How to get this bug fixed?

2

Just to complete the picture… you have posted about this before at:

http://www.tinyclr.com/forum/10/3169/

where you were pointed to

http://www.tinyclr.com/forum/10/1901/

Since the netmf is dealt with via www.netmf.com, you can go there and provide that feedback, contribute a code change, or just note your findings in a work item as you choose. You may already find it has been raised before.

3

This problem does not exists with the httplistener class for the Wiz5100 chip, which suffers from its own problems.With only 4 sockets, the lingering problem would appear quickly… I have an httplistener class that has been up and running for a week, and so far answered for over 120’000 requests ! Using a trick… when I get a problem, I just Abort() the Listener and start it over. It takes less than a ms… Temporary, untill the problem is fixed, you could have a counter on your pages, and reset the httplistener as well ?

4

[quote]After alot of investigration on different forums and revers engineering with Red Gate Reflector it is clear for me that there is a bug in the HttpListener in the NETMF 4.1
[/quote]
This is not a bug. The sockets linger for sometime till they are released. Give the system few minutes and the sockets will be released. I see how you can’t force sockets to not linger but as suggested in other posts, you can solve this by taking the HTTP code from the PK into your project then you can add the linger option. You can also pass this on to Microsoft so they may do something on next release. www.netmf.com

I do not think W5100 have “linger” feature so this is not a problem

5

I have not made a copy of this post on www.netmf.com.

What do you mean with PK?

6

PK stands for Porting Kit

7

Another solution (nasty hack) is to use reflection to access protected methods/members at runtime. Here’s a code snippet that does this:


            HttpListener test = new HttpListener("http", 83);
            test.Start();
            HttpListenerContext ctx = test.GetContext();


            Object clientInputStream = typeof(HttpListenerContext).GetField("m_clientInputStream", System.Reflection.BindingFlags.NonPublic | System.Reflection.BindingFlags.GetProperty | System.Reflection.BindingFlags.Instance).GetValue(ctx);
            Type cist = clientInputStream.GetType();
            Socket t = (Socket)cist.GetField("m_Socket", System.Reflection.BindingFlags.NonPublic | System.Reflection.BindingFlags.GetProperty | System.Reflection.BindingFlags.Instance).GetValue(clientInputStream);
            t.SetSocketOption(SocketOptionLevel.Socket, SocketOptionName.Linger, -2);

You could implement this as an extension method to the HttpListener class with the hope of being able to ditch it if/when MS fix the underlying problem.