Nancy: WebSocket server on the same port

[jgillich]

I use Fleck as a WebSocket server together with Nancy, each on it's own port. Is it possible to run both on the same port?

It should be possible to proxy all non-HTTP requests to another tool and other frameworks are able to do that just fine (like express & SocketIO), but I have no idea where to start with Nancy.

[thecodejunkie]

This is perfectly do-able but you are doing to have to write some code yourself. Nancy uses the concept of Hosts which act like an adapter between something that communicates HTTP and Nancy's own Request and Response objects.

For instance Nancy.Hosting.AspNet implements a host based on an IHttpHandler, so it takes an incoming HttpWebRequest, translates it into Nancy's Request objects, pass that along to Nancy, takes Nancy's Response object, converts it back into a HttpWebResponse instance and passes it back to the caller. Same goes for Nancy.Hosting.Self, which is based around an HttpListener.

The source code for all our hosts are available in our main repository. You would need to write a custom host (probably similar to the Nancy.Hosting.Self one) that would be based around a raw socket. When you get incoming data to the socket, you would need to determine if it is an HTTP request and if so, pass it along to Nancy, otherwise pass it along to another handler.

Shouldn't be that hard - the biggest hurdle would be to setup a decent socket listener implementation :)

[thecodejunkie]

Closing this now, but feel free to continue discussing it in this thread

[damianh]

This is what OWIN was designed for. @jgillich we would all be better off if Fleck was made to be owin compliant instead.

[thecodejunkie]

:thumbsup: for Fleck being OWIN compliant

[jgillich]

Thanks a lot for the extensive answer!

I could easily replace Fleck with something else and OWIN sounds great, but unfortunately I can't find an implementation not based on System.Net.WebSockets - which only works on Windows 8 / Server 2012 and later. :disappointed:

[vincentparrett]

I have a need to do this too, Owin is not a option as I need to support older servers. Microsoft seem to be deliberately missing the point of owin.

[prabirshrestha]

@vincentparrett you can create an owin middleware for websockets using http://xsockets.net/

[vincentparrett]

Ummm... pretty sure I just said Owin is not an option.. I need to support < server 2012.. microsofts owin implementation does not.

[damianh]

@jgillich This is why I said "we would all be better off" ;)

@vincentparrett Owin is not restricting you from older servers, though you are restricted to .net 4.0 and later. Microsoft aren't missing the point of owin.

[vincentparrett]

Ok, I must be missing something here, because every reference I found to microsoft's owin points to needing 4.5.1 which is not supported on older servers. The reason I said that ms are missing the point, is that their owin implementations are full of non owin stuff, so if for example you wanted to run on another owin implementation (ie to run on mono/linux) you have a problem. I guess I need to do more research.

[prabirshrestha]

@vincentparrett at minimum u need net 4.0 for owin to work.

In fact this SimpleOwin ASP.NET host has been tested on mono on mac too.

https://github.com/prabirshrestha/simple-owin/blob/e3812bace503b9fb29572c6b9d62d9b6d580bde1/src/SimpleOwin.Hosts.AspNet/SimpleOwinAspNetHost.cs

add #define ASPNET_WEBSOCKETS if you want to support asp.net web sockets. (but this will require .net 4.5 which is not an option for @vincentparrett)

Here is what I meant by create an OWIN middleware that enable websockets. This example still uses the ASP.NET websockets. You could write a similar one that uses xsockets.net

https://github.com/prabirshrestha/simple-owin/blob/e3812bace503b9fb29572c6b9d62d9b6d580bde1/src/SimpleOwin.Middlewares.AspNetWebSocket/AspNetWebSocketMiddleware.cs

(That code looks ugly coz it uses reflection so the middleware will be a noop middleware when running on .net 4.0 but will use websockets when running on .net 4.5 without recompilation.)

[vincentparrett]

I can't used asp.net as I need nancy hosted in a service. I've been developing with self hosting (which is working well). Thanks for the info though, I will look into it.

[damianh]

Yes you are...

If a an OWIN middleware that stores session data in redis, and thus having
a dependency on redis, doesn't make it any less owin. In the same way, if
any of the MS OWIN middlewares depend on .NET 4.5 doesn't make it less
OWIN, just less portable to mono / older servers. OWIN defines
_composability_ and not portablity.

Yes, System.Net.WebSockets being .NET 4.5 only and incomplete support on
mono is a pain. Same goes for the System.Security.Claims namespace.

If the authors of Fleck / XSockets.net were to make their libraries owin
compliant, it would give a lot more options to a lot more people to compose
web applications as they need, which is better in every way than hacking
nancy's self host for a single scenario.

On 9 February 2014 23:55, Vincent Parrett [email protected] wrote:

Ok, I must be missing something here, because every reference I found to
microsoft's owin points to needing 4.5.1 which is not supported on older
servers. The reason I said that ms are missing the point, is that their
owin implementations are full of non owin stuff, so if for example you
wanted to run on another owin implementation (ie to run on mono/linux) you
have a problem. I guess I need to do more research.

Reply to this email directly or view it on GitHubhttps://github.com/NancyFx/Nancy/issues/1437#issuecomment-34590249
.

[TiagoOliveiraMarques]

Some time has passed since the last post but I had the same problem as described here and I made a simple library for that purpose.
For those interested, here is the repo

[rkgarcia]

@TiagoOliveiraMarques do you test the performance with your library?

[TiagoOliveiraMarques]

@rkgarcia Sorry for the late reply. I tested it with apache benchmark and made some "hot path" benchmarks. If I remember correctly it has something like 75% the throughput of a nancy self hosted server on a i7 machine serving a "Hello World" string. IIRC ab uses HTTP/1.0 requests (so one connection per HTTP request). The bottleneck is indeed in the connection creation.