Simultaneous WebServer request/response

Hi dear community! I need to implement simultaneous webserver request/response behavior. I will try to explain what i mean. I want to be able to control my robot directions during the picture streaming response. If i already sent the picture streaming request to the WebServer port 8080 and picturestreaming webevent handling is in progress(it response pictures bytes back to the http client) is it possible to send another request for example “move forward” to WebServer port 8080 and activate the move forward WebEvent simultaneously when the picture streaming response still is in progress.

Now i can control my robot directions only when picture streaming is off, but i want to be able to control the robo position and send another commands during picture streaming.

I use WIFI RS21 module, Gadgeteer WebServer, 2014 R5 SDK, firmware 4.3.6

Here is WebServer code:

public void RunServer()
WebEvent picturestreaming = WebServer.SetupWebEvent("picturestreaming");           
WebEvent moveforward = WebServer.SetupWebEvent("moveforward");           
moveforward.WebEventReceived+=moveforward_WebEventReceived;            WebServer.StartLocalServer(, 8080);  
        void picturestreaming_WebEventReceived(string path, WebServer.HttpMethod method, Responder responder)

void moveforward_WebEventReceived(string path, WebServer.HttpMethod method, Responder responder)
            \\control position code
            responder.Respond("moving forward");   

Can you guys advice me please what is the best way to implement that behavior?

The fastest way to get an answer to your question is to experiment…

Or, look at the code for the web server and see how multiple simultaneous requests are handled. Are individual requests handled with separate threads? Is locking used to limit the processing to a single request?

One of the great “features” of Gadgeteer open source is you can look and the code and quickly see how how processing is done.

1 Like

Most web server implementations create a separate thread for each request.

@ Cowboy -
Yes, but I think that this is not enough. As far as I know and if I don’t think wrong, in the NETMF / Gadgeteer world an event in the Program Class is not called, until the previous event is finished. This means, if you send the response directly from the WebEventReceived handler to send a picture, there will not occur another event until the entire picture is sent. So you cannot react on webevents for steering of your robot while a picture is transmitted. A solution might be, to start a new thread in the WebEventReceived handler which then transmits the picture, and let the WebeventReceived handler finish to be ready to receive succeeding events.

Thank all of you guys for helpful advices!!! Now it’s time to experiment!

@ RoSchmi - That’s what I was referring to. The receiver just starts a thread to process the request and goes back waiting for another request.

@ Cowboy -
So why the reciver cant process another request when responder.Respond() is not completed in my scenario? Before the responder job for sending picture to the client is not completed. no one event handler doesnt trigger the event. I think RoShcmi is right about the eventhandlers behavior in NETMF.

@ Alex Bilityuk - I have a converted version of the Gadgeteer Web Server that runs under Mono on the Raspberry PI 2. I was just looking at the debug output and I see two or three threads terminating each time a web response is prepared. It looks like each command might be running on its own thread. Or, the multiple threads could be a Gadgeteer artifact.

BUT, the only way to be absolutely sure what is happening is to read the code.

@ Alex Bilityuk - Don’t do the respond in the event handler. Start a thread that does that. Then just exit the event handler.

Make sure that a new response object is created for each request, and is not being reused. Check the code!

@ Mike - @ Cowboy
what do you think of this solution:
I think it should work.

@ RoSchmi - i think I have expressed by opinion on verifying the workability of any solution. Due diligence!