dx9s

I read up on AutoResetEvent class: https://msdn.microso...v=vs.100).aspx (I've never used them before). My question is basically answered.

I think I would setup a different handler:

Microsoft.SPOT.Net.NetworkInformation.NetworkChange.NetworkAvailabilityChanged += (...);
Microsoft.SPOT.Net.NetworkInformation.NetworkChange.NetworkAddressChanged += (...);

that would setup and destroy the network code in it's own thread instead of using the AutoResetEvent to effectively cause a pause via WaitOne(). As in my case I would need to respond to the NF3Wifi going in and out of range multiple times instead of just once.

Just my thinking.

--Doug

I did read that and I know that options 1,2,3 not correct for my scenario. option #4 is a little confusing but is probably the closest to what I am thinking.

In networking terms, checking the networking link state (regardless if the IP layer is good or not). I keep on seeing in #4 reference to Network Address / Network Available and other things "network" layer 3 related or what I believe to be layer 3 related code.  One can derive / approximate the 'wireless' layer 1/2 link state from that, but it isn't exactly the same thing. (Darn my background in 'link state routing' -- I am sure it is making me seem problematic). It be also cool to get things like RSSI/RCPI readings from the wireless adapter.

A complete reference (working program) using option #4 would help clarify some things for me.

--Doug

I was talking through MSDN and System.Net .. I know there is a WebClient class ( https://msdn.microso...(v=vs.110).aspx-- not this not NETMF ) for non-micro framework .NET.

So I went searching for the MSDN on .NET Micro Framework -> System.net -> https://msdn.microso...y/ee435218.aspxand spotted the HttpListener and related Http related things under the System.Net Namespace (that link is 4.1, but I think 4.3 includes all of the things from 4.1's System.Net Namespace).

I also stumbled on: http://blogs.msdn.co...work-netmf.aspxwhich references http://netmfwebserver.codeplex.com/ -- but the download/source code links appear broken.

This is good reference for re-using as much as possible from the framework. I thought I'd share it here for others to "stumble on" as well.

--Doug (dx9s)

Yeah I know it is a "cooperative" Threaded model (hence no MUTEX support if my memory is correct). Perhaps I should review how NGINX (almost as popular as Apache) does it's (for lack of putting it better) "round-robin-like" approach. In reality, this might be overkill as only one network packet can be received at a time anyhow, and the IP stack will throw that into a buffer at some point. Perhaps simply accepting the connection into an array and then walking the array for incoming data and attempting to parse the HTTP header data into another structure until some flag (two new lines) for end of request. It could be done as an array, but the parsing (at least) and possibly responding would be an interesting framework for processing HTTP request.

I don't know enough of the NETMF IP stack to know how it deals with setting up multiple TCP-SYN's / SYN-ACK / ACK (typical TCP setup at the "3rd" layer) at a time. Time to break out Wireshark (formally Ethereal) and do some testing at least. I will have to look into writing some custom code to really stress the TCP portion of the NETNF stack.

Not sure how and when the TCP connect is established and then buffered/handed off to the application and further how incoming data is buffered. Perhaps most of this is already a non-issue (handling multiple connections at once like any decent web server). Offloading as much into the existing IP (and TCP) stack that exists in the NETMF should end up making the application simpler/smaller/more reliable (the goal is at least more reliable).

--Doug (dx9s)

Nevyn: I did stumble on that after posting this. It looks possible -- I only skimmed over the source code but it might be a start or at least reference.

Wernfried: I am inerested but not in a hurry at this time.

All: My primary thing is to make sure the listener is threaded (each connection at least) to handle a single web browser making (usually) up to 4 parallel request at once as well as basic file serving with a "CGI" like gateway (for AJAX) to a service which really does the work behind the scene. That way the entire "UI" can be a static webpage with javascript that runs in client and the exposed interfaces (SOAP like perhaps but as simple as one can get it) over the HTTP protocol.

I plan to pick apart the Neon Mika web server initially as I see it had some reference to JSON in the source code some place. It also looked like that source code had a framework for extending. It might be the project that I use entirely.

(cryptic back-story): I plan to adapt some / simplify one of my Microchip source code to hand off some of the very time sensitive (talking nanoseconds, fractions of milliseconds) tasks and talk via serial. I got an original Netduino and was happy with the high level C# functions but needed higher deterministic timing resolution which I never moved forward on. Now with the N3 and Wifi, I have a crazy wireless redesign idea in mind using both a Netduino and 18F (K22 series) PIC (that should work). I am once again excited.

--Doug (dx9s)