I recently discovered WebSockets and their possible usage in my project. Currently, I use raw web sockets, but I have been exploring the possibility of making a custom transport binding/channel that would handle everything and allow me to host it in IIS.
I've started work on this, but I'm having issues figuring out how to get IIS to forward the appropriate requests to me. I've been reading through the UDP transport example from Microsoft, but it doesn't host it the same way I do, so it's not very useful in that regard. The example creates a UDP Socket in the WCF code itself, which doesn't seem like the proper way to do it. I could make my binding manually create a port to listen to, but then I'd have to re-implement things that are covered by IIS/ASP.NET.
As a WebSocket starts out as a normal HTTP request then escalates to a protocol similar to HTTP, I need to get IIS to give me a stream that I can read from and write to.
I've been using .NET Reflector to look through the webHttpBinding to see how they do it. They seem to use httpapi.dll to P/Invoke HttpCreateRequestQueue. Is this what I want?
This is very similar to the webBindingSocket in the way that it generates client proxy JavaScript, but I will automatically generate callback methods to allow the server to easily invoke methods on the browser.
Example:
http:// localhost/WebSocket.svc - Service Metadata Stuff
http:// localhost/WebSocket.svc/jsdebug - JavaScript Client Proxy
http:// localhost/WebSocket.svc/stream - Where the WebSocket is located
I'm sorry if my question seems confusing, but I've just been staring at tons of code trying to figure out how it works. Basically I want to make it easier to use WebSockets in my code, instead of having to worry about serializing messages to/from the server and calling the right method, I'm going to handle all that in WCF.
Thanks