I’ve been trying to use my spider as a web server and noticed it not being stable at all. basically after i start the server and call and of the WebEvents, the spider hangs and trows teh following exception after about 10 minutes of stand by… and for the life of me i just can’t track the cause of the issue…
the exception:
The thread '<No Name>' (0x8) has exited with code 0 (0x0).
#### Exception System.Net.Sockets.SocketException - CLR_E_FAIL (9) ####
#### Message:
#### Microsoft.SPOT.Net.SocketNative::getpeername [IP: 0000] ####
#### System.Net.Sockets.Socket::GetEndPoint [IP: 0026] ####
#### System.Net.Sockets.Socket::get_RemoteEndPoint [IP: 0005] ####
#### Gadgeteer.Networking.WebServerManager+Server::ProcessRequest [IP: 0027] ####
#### SocketException ErrorCode = 10057
#### SocketException ErrorCode = 10057
A first chance exception of type 'System.Net.Sockets.SocketException' occurred in Microsoft.SPOT.Net.dll
#### SocketException ErrorCode = 10057
#### SocketException ErrorCode = 10057
and i got the same exact exception after 10 minutes from calling the hello webevent…
can someone with a spider try the above example and call their IP Address with /hello and wait about 10 minutes and check the output window of their VS2010… and let me if they get the exception…
i really hope this can be fixed… because of it i haven’t touch my micro controller for over three weeks now hoping the new update will be release with a fix… but i can no longer wait so please anyone report back…
nope i didn’t look it up … thanks for that, but it still doesn’t help in tracking the issue, and since I’m using the Gadgeteer Web API, does it mean it’s a bug in the API…?
can you please try that demo from codeshare i linked on a spider if you have one.
@ Jay Jay - I did some quick tests and these are my results
Hit the web server from IE 9, waited 12 minutes and hit the server again device responded as expected, no messages in output window other than the expected ‘Hello World’
Hit the server continuously using a console application, server stopped accepting connections after 126 requests
Hit the server continuously using a console application with forced GC on device every 50 requests, server stopped accepting connections after 126 requests
Hit the server continuously using a console application with a 10 ms delay between requests, server stopped accepting connections after 126 requests
Hit the server continuously using a console application with a 100 ms delay between requests, server stopped accepting connections after 126 requests
Hit the server continuously using a console application with a 500 ms delay between requests, server stopped accepting connections after 126 requests
Hit the server continuously using a console application with a 1 sec delay between requests, server handled requests indefinitely
In summary, I could not reproduce your exact error. It does seem that the Gadgeteer Webserver might have some issues, the number 126 is interesting because it is right there at the limit of the number of TCP Connections that the NETMF stack can handle. I looked closer and the network traffic and realized that NETMF WebServer is using http 1.0 which means that every request is a new connection, which means that each request would result in it’s connection moving to the TIME WAIT state (2xMLS normally 240 seconds). This would explain why the delay exceeding 1 second alleviates the problem, it gave the connections enough time to expire from the TIME WAIT state and start being reused.
It is a pity that the WebServer is not using HTTP 1.1 which supports persistent connections, but I guess if you keep in mind the typical usage scenarios for a web server on this kind of device this is probably not a real issue.
For my tests I used the following code on the desktop (192.168.0.101 is the IP assigned to the spider)
using System;
using System.Net;
using System.IO;
namespace WebClientTest
{
class Program
{
static void Main(string[] args)
{
while (true)
{
var request = (HttpWebRequest)WebRequest.Create("http://192.168.0.101/hello");
using(var response = request.GetResponse())
using (var stm = response.GetResponseStream())
using (var rdr = new StreamReader(stm))
{
Console.WriteLine(rdr.ReadToEnd());
}
}
}
}
}
Thank you for your test…
my guess is this is a bug in the GADGETEER WebServer API… not the standard NETMF…
well something is causing my Spider to receive a request from my router which it can’t handle… or the spider is sending a request that lingers around and only receives the response after the connection has closed… which throws the exception (causing the whole system to freeze)… the crazy part about this is i can’t handle the error… I’ve included the source code of the webserver from codeplex and tried to trap it but i couldn’t get to it…
Maybe it is a UPNP or something on my router that keeps broadcasting… none the less my error is persistent and the same every time… so it is definitely an Issue with Gadgeteer web server…
So now i just need more data to know if someone else can reproduce the error so we can narrow it down to something useful before i report it as a bug…
the part that worries me is, if this happened in my network and i can’t handle the error, there is no guarantee that it will work ok on the next network i move my spider to… which is a big problem of reliability…
Have you used something like Fiddler (Fiddler | Web Debugging Proxy and Troubleshooting Solutions) to check the traffic between the browser and the spider for anything suspicious? If that does not show anything then maybe a packet sniffer like wireshark or Microsoft Network Monitor would show something.
Hi taylorza,
i have fiddler but it will only check traffic generated and received by my system and not necessarily the one hitting the spiders which is exactly what i would need to see to know what is causing the issue…
wireshark does the same again related to my PC Network card… unless i can share my spider connection trough my PC network card… i guess then i can monitor the traffic… but that would require setting up the wifi and share that connection with the NIC and connect the spider there… maybe I’ll mess wit this setup next if i get no where.
At least our firmware match, so we are on the same build…
i hope someone else can run the test on their rig and report back…
i did the following tests and here is what i found out…
after i ran the above linked example and called the hello link http://10.255.218.97/hello … from the browser next i unplugged the Network cable from the spider… and left it unplugged… after a while my output window showed the exact same error messages… now I’m wondering why did that happen? the cable was unplugged so no traffic was generated… and yet i got the exception… so this has to be a bug somewhere don’t you think? at least i know it has nothing to do with my Router or Network…
and after the error POP UP i plugged the cable back and hit the link again, waited few seconds to get the network is up again …
and hit refresh, which showed the correct message from the Spider and the output windows was updated with the right messages…
Good idea… i think i may have one of those somewhere in storage…
well the issue is not with the router or NIC traffic, that’s what my last test shows since the cable was unplugged… so it is CODE (Gadgeteer Code i think) that is causing the issue…
at least i know the system doesn’t freeze just Sockets stops working because unplugging the cable and replugin it back again after few minutes seems to reset the connection and it’s back to normal until the next exception…
i just can’t figure it out… why would the connection just die…
here is the code that is causing the issue:
//WebServerManager.cs in the WebServer41 Project from Gadgeteer Source Code...
clientSocket.RemoteEndPoint.ToString();
// this is the one that is throwing the exception so obviously there is no RemoteEndPoint in the clientsocket.
what is confusing me is what is causing the Connection to kick in … since the cable is already disconnected.
COULD SOMEONE FROM GHI PLease test this and report back…
WHY would such exact code work on one board (Spider) and not another (Spider) (Where both are identical in terms of firmware and builds) ? Please help me understand and figure a way out…
can you please run the example i linked in my Post above and call the Hello query and let it sit for a while maybe 10 to 20 minutes and see if you get the exception…
From the second reply, delay works fine but with speeds you get exception after 126 connection, this is normal as sockets “linger” after they are closed. There was an option to disable linger by using socket option and the number -2 IIRC.
Thank you for taking the time to read the replies, but that is not what I’m experiencing GUS…
What I’m experiencing is simple… i start the WebServer call a WebEvent from the browser (hello), the Spider serves the page… i unplug the Ethernet cable completely from the spider to make sure that is not related to what you described… and after a while i get the exception…
if i leave the cable plugged i get the same exception…
then the spider doesn’t response to any browser queries (after i get the exception with cable plugged in of course)… the only way to get it working again is by unplugging and re plugin the cable which restarts the WebServer… so for whatever reason after a certain amount of time the WebServer Stops… and i can’t trace why… this is where i need your help. remember if it happened to my Spider chances are it will happen to someone else
[quote] i unplug the Ethernet cable completely from the spider to make sure that is not related to what you described… and after a while i get the exception…
if i leave the cable plugged i get the same exception… [/quote]
I am totally lost. If it is same then why unplug the cable?!
On any level, we will not be doing any work on 4.1 as we are moving to 4.2 plus 4.2 uses a totally different TCP/IP stack.
