title: Options to stack native protocol over http?
body: <p>We have a client/server system where all communications are done using a native protocol over a binary/SSL stream on TCP.  All of our code is written in C# .NET 2.0 and some parts in 3.5.  Our protocol is designed to support a variety of messaging patterns, namely Request/Response, and for lack of a better term, one-way messages from either the client or the server on an irregular basis.</p>
  
  <p>Our objective is to add a feature to our system to carry our protocol over HTTP.  There are several reasons for doing so, but I don't need to explain that here I think.  Please tell me if I should.</p>
  
  <p>The thought is to embed our protocol as application/binary in HTTP requests using the standard request methods ie., GET, PUT, POST, but not DELETE, and following the HTTP specification.  This would be rather straight forward to do if our protocol was only request/response.  The main concern comes from the one-way messages, and more specifically the unsolicited messages coming from the server.  Another important concern is that HTTP is not oriented for persistent connections, but I believe with HTTP/1.1 this can be overcome.  A third concern is that the server connections are not stateless.</p>
  
  <p>We've been designing and prototyping this for a couple weeks, and we've come up with a couple ideas:</p>
  
  <ol>
  <li>Refactor the code in the communication and protocol layers on both server and client sides. Although much of the code is shared, it is a lot of work that in all likely hood will not be a success.  The question here is can this even be done with our poorly designed protocol?</li>
  <li>Use a proxy approach.  That is create an HTTP server using WCF and unwrap the HTTP messages and relay the native messages to and from our server over persistent connections.  This would require a layer of abstraction on the client side that would actually maintain two connections to the proxy.  One connection to perform request/response and the other to carry the unsolicited messages using a delayed response technique.</li>
  <li>HTTP Tunneling which we haven't yet researched.</li>
  </ol>
  
  <p>We're hoping that someone has encountered this challenge before and could lend some sound advice?</p>
  
  <p>Please accept my apologies if this is the wrong place to post this question.</p>