Websocket transport #2
Labels
Comments
|
I think the solution here is not to support arbitrary HTTP. Instead what we should aim for is coexistence of multiple "sockets" on the same TCP port, using the path to discriminate different sockets. That likely means we need another higher level "endpoint" beyond the socket, specific to the websocket transport. The code we used to share common "Nodes" in the ZeroTier transport is something we can model on. |
|
Note also with the integration of #3 we should support TLS too! (i.e. https...) |
gdamore
added a commit
that referenced
this issue
Dec 26, 2017
This is a rather large changeset -- it fundamentally adds websocket transport, but as part of this changeset we added a generic framework for both HTTP and websocket. We also made some supporting changes to the core, such as changing the way timeouts work for AIOs and adding additional state keeping for AIOs, and adding a common framework for deferred finalization (to avoid certain kinds of circular deadlocks during resource cleanup). We also invented a new initialization framework so that we can avoid wiring in knowledge about them into the master initialization framework. The HTTP framework is not yet complete, but it is good enough for simple static serving and building additional services on top of -- including websocket. We expect both websocket and HTTP support to evolve considerably, and so these are not part of the public API yet. Property support for the websocket transport (in particular address properties) is still missing, as is support for TLS. The websocket transport here is a bit more robust than the original nanomsg implementation, as it supports multiple sockets listening at the same port sharing the same HTTP server instance, discriminating between them based on URI (and possibly the virtual host). Websocket is enabled by default at present, and work to conditionalize HTTP and websocket further (to minimize bloat) is still pending.
This was referenced May 7, 2020
Closed
xinyi-xs
pushed a commit
to xinyi-xs/nng
that referenced
this issue
Dec 2, 2021
Resolved compile warning
muryliang
pushed a commit
to muryliang/nng
that referenced
this issue
Mar 30, 2023
This adds support for Windows Named Pipes as ipc:// URLs that are compatible with nanomsg and NNG. It also includes (untested) support for SecurityDescriptor and InputBufferSize and OutputBufferSize tunables. It is built on the github.com/Microsoft/go-winio library. Note that legacy libnanomsg (all versions 1.1.3 and earlier) is very fragile in it's handling of IPC, and assumes that senders will only send a single atomic write. This assumption requires us to make an extra data copy. (Note that NNG has no such assumptions, and we could easily dispense with the data copy for NNG.)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We need a websocket transport.
The websocket client support is straightforward, and providing equivalent server functionality to nanomsg would be easy. It might be worth looking at (thinking about) richer integration into extant web frameworks. That said, its unclear how that would work with C.
The text was updated successfully, but these errors were encountered: