title: How does WebSockets server architecture work?
body: <p>I'm trying to get a better understanding of how the server-side architecture works for WebSockets with the goal of implementing it in an embedded application.  It seems that there are 3 different server-side software components in play here:  1) the web server to serve static HTTP pages and handle upgrade request, 2) a WebSockets library such as libwebsockets to handle the "nuts and bolts" of WebSockets communications, and 3) my custom application to actually figure out what to do with incoming data.  How do all these fit together?  Is it common to have a separate web server and WebSocket handling piece, aka a WebSocket server/daemon?</p>
  
  <p>How does my application communicate with the web server and/or WebSockets library to send/receive data?  For example, with CGI, the web server uses environmental variables to send info to the custom application, and stdout to receive responses.  What is the equivalent communication system here?  Or do you typically link in a WebSocket library into the customer application?  But then how would communication with the web server to the WebSocket library + custom application work?  Or all 3 combined into a single component?</p>
  
  <p>Here's why I am asking.  I'm using the boa web server on a uClinux/no MMU platform on a Blackfin processor with limited memory.  There is no native WebSocket support in boa, only CGI.  I'm trying to figure out how I can add WebSockets support to that.  I would prefer to use a compiled solution as opposed to something interpreted such as JavaScript, Python or PHP.  My current application using long polling over CGI, which does not provide adequate performance for planned enhancements.</p>