theturtle32
added the wsf protocol
Hi,
i added the wsf protocol to support the websocket to run over socket files. I still think it is alittle fishy but how you think we should define a socketPath in a ws: url.
wsf:///absolute/path/to/socket/ wsf://./relative/path/to/socket/
i did not implemented the pathname of the url function. The pathname on wsf protocols is this is set to the "kaputt".
I build a test which tests wsf and ws connections
Thx
Meno
This is new to me... I've never heard of a "wsf" protocol. Google search doesn't turn anything up either.
I'm not necessarily fundamentally opposed to extending the library to support using unix socket files, but If we do so, I want to make sure to do it carefully and in the best way possible. I'm not really much of a Windows guy, but Windows doesn't support socket files of any sort, does it? Is there an equivalent? If not, should we instrument some kind of error messaging/handling when someone tries to use that functionality on a platform that doesn't support it?
What's the use case for this?
@ibc - Do you have any thoughts or opinions about this?
I have no idea regarding what "wsf" is. I understand that it intends to be a message boundary protocol (in fact, the WebSocket protocol) over Unix Sockets in STREAM mode.
Honestly, I don't understand why this stuff should be added into a WebSocket library.
I created the wsf protocol name by my own. so it's just to make clear that the host part ist not a DNS name. We could name it like we want. there is something out with http that looks like http:://Unix://socket:/ but this is pretty ugly also.
the usecase could be to enable the communication between two node processes running on the same machine. And wants to avoid the exposure of a IP:port.
I use it for a command line tool which talks to a background process like SSH and ssh-agent
if you.look in my added code you will see that this is only a changes the connection establishment. it uses features which are build in the http client and server of node for ages now.
cheers
meno
On Thu, Jun 16, 2016, 22:37 Iñaki Baz Castillo [email protected] wrote:
I have no idea regarding what "wsf" is. I understand that it intends to be a message boundary protocol (in fact, the WebSocket protocol) over Unix Sockets in STREAM mode.
Honestly, I don't understand why this stuff should be added into a WebSocket library.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/theturtle32/WebSocket-Node/pull/240#issuecomment-226606141, or mute the thread https://github.com/notifications/unsubscribe/AABLJuOsNdMb2__rZKqHT5xCZnsSdjVpks5qMbPmgaJpZM4I3T8z .
for the windows guys it should also work, they have also named sockets. I could try to test it tomorrow.
meno
On Thu, Jun 16, 2016, 23:21 Meno Abels [email protected] wrote:
I created the wsf protocol name by my own. so it's just to make clear that the host part ist not a DNS name. We could name it like we want. there is something out with http that looks like http:://Unix://socket:/ but this is pretty ugly also.
the usecase could be to enable the communication between two node processes running on the same machine. And wants to avoid the exposure of a IP:port.
I use it for a command line tool which talks to a background process like SSH and ssh-agent
if you.look in my added code you will see that this is only a changes the connection establishment. it uses features which are build in the http client and server of node for ages now.
cheers
meno
On Thu, Jun 16, 2016, 22:37 Iñaki Baz Castillo [email protected] wrote:
I have no idea regarding what "wsf" is. I understand that it intends to be a message boundary protocol (in fact, the WebSocket protocol) over Unix Sockets in STREAM mode.
Honestly, I don't understand why this stuff should be added into a WebSocket library.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/theturtle32/WebSocket-Node/pull/240#issuecomment-226606141, or mute the thread https://github.com/notifications/unsubscribe/AABLJuOsNdMb2__rZKqHT5xCZnsSdjVpks5qMbPmgaJpZM4I3T8z .
Well. I must say that this feature may be interesting. It still is "WebSocket", it's just that the transport is not TCP but named sockets.
Node.js provides inter-process communication mechanisms, but that is just for processes spawned by a parent process.
Node.js uses libuv internally, which has a uv_stream_t handler that manages both TCP connection or Unix Sockets in STREAM mode in the very same way, so the feature in this PR looks like the same abstraction at a higher level.
Adding @saghul to the conversation as he probably has something to add.
just some thoughts about wsf what is if we switch back to wss and ws and adapt the ipv6 literal nr notation for our needs like:
ws://[/the/file]
if will change this tomorrow, with the windows test
meno
On Thu, Jun 16, 2016, 23:42 Iñaki Baz Castillo [email protected] wrote:
Well. I must say that this feature may be interesting. It still is "WebSocket", it's just that the transport is not TCP but named sockets.
Node.js provides inter-process communication mechanisms, but that is just for processes spawned by a parent process.
Node.js uses libuv internally, which has a uv_stream_t handler that manages both TCP connection or Unix Sockets in STREAM mode in the very same way, so the feature in this PR looks like the same abstraction at a higher level.
Adding @saghul https://github.com/saghul to the conversation as he probably has something to add.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/theturtle32/WebSocket-Node/pull/240#issuecomment-226622483, or mute the thread https://github.com/notifications/unsubscribe/AABLJtyBzxbLcvhV95QeLZxptZdvE9C2ks5qMcNGgaJpZM4I3T8z .
Hi there! I haven't looked at the code, but what you propose has been used in the Python world for a while, so there is precedent. Python uses WSGI (sort of CGI) for webservers and indeed it makes some sense to communicate over a Unix domain socket instead of using localhost.
As for the URI identifier I'd personally go for something more explicit like ws-unix:// but I don't have a horse in this race :-)
Some bonus nachos for Linux: you can use abstract sockets and also avoid using a file for the Unix socket. See https://github.com/saghul/node-abstractsocket, written by yours truly :-)
Hope that helps!
So I tested on windows and it works only the pipe names are special:
?\pipe\path\to\pipe.file
but the rest is fine.
Do you think you will merge this in the main line?