6 ms·
Basically the same thing in Node.coffee, just because: { Server } = require 'ws' { spawn } = require 'child_process' command = process.argv[2]
by tlrobinson 13y ago
Basically the same thing in Node.coffee, just because:
{ Server } = require 'ws'
{ spawn } = require 'child_process'
command = process.argv[2]
args = process.argv[3..]
wss = new Server port: 8080
wss.on 'connection', (ws) ->
ps = spawn command, args
ps.stdout.on 'data', (data) -> ws.send data.toString()
ws.on 'message', (data) -> ps.stdin.write data.toString()
ws.on 'close', -> ps.kill()
ps.on 'close', -> ws.close()
(Needs a bit more error handling)
- thomasahle 13y agoA nice example on Node. Only I don't quote get the ',' syntax. Is it a scoping thing?
- jbrooksuk 13y agoIt's a Coffee syntax thing. ws.on 'close', -> ps.kill() That compiles to: ws.on('close', function() { return ps.kill(); });
- thu 13y agoI have never done any Coffee but it looks like arguments are separated by commas, and, in this case, the second argument is a function of no argument (so the left hand side of the arrow is empty). Edit: it was meant to be a reply to the parent.
- kaoD 13y agoNice! I love Node for these kind of asynchronous handling of data, it fits perfectly. Keep in mind you can go down the stream route. Instead of: ps.stdout.on 'data', (data) -> ws.send data.toString() ws.on 'message', (data) -> ps.stdin.write data.toString() Just do: ps.stdout.pipe ws ws.pipe ps.stdin I started using Node before Streams and I often forget piping too! I still have a question for Node.js experts... would the 'close' events had to be handled then? Streams handle and propagate the 'end' event just fine, but should the underlying resource be closed? I guess killing `ps` is mandatory since ending `stdout` won't kill the process (or will it?), but is closing `ws` still mandatory too?
- tlrobinson 13y agoI thought about using pipe but the WebSocket library doesn't implement the Stream API, does it?
- secoif 13y agohttps://github.com/maxogden/websocket-stream https://github.com/maxogden/websocket-stream
- wpears 13y agoIf the socket is terminated mid-command (thus emitting 'close'), one would want the process to be killed. Also, the socket doesn't know that no more transmission is required just because one particular stream is over. That is why close is called manually on the socket after the stream emits a 'close'. This all provided you use a streaming web socket module like https://github.com/maxogden/websocket-stream https://github.com/maxogden/websocket-stream
- pmelendez 13y agoSorry if the question is too basic (I don't code in Node.js) but where is the websocket handshaking and the envelop management on this?
- deleted 13y ago[deleted]
- alexkus 13y ago{ Server } = require 'ws'
- CGamesPlay 13y agoCreating a new server will start listening for connections, and the connection event will only be emitted after the handshake has finished. http://socket.io/ http://socket.io/ has more info on how the node api works. wss = new Server port: 8080 wss.on 'connection', (ws) ->
- joewalnes 13y agoAuthor here. Indeed! The very first version of websocketd was actually written in Node. It's great for this kind of stuff. The reason I switched to Go was to make distribution/installation for end users easier.
- AsymetricCom 13y agoOf course, Perl has been doing this for over a decade. Nobody thought it was remarkable enough to write an article about it though.
- deleted 13y ago[deleted]
- huhtenberg 13y agoNot just Perl. This is basically inetd re-invented. [0] http://en.wikipedia.org/wiki/Inetd http://en.wikipedia.org/wiki/Inetd
- joewalnes 13y agohuhtenberg: I believe AsymetricCom was referring to being able to compile an executable using perlcc. He wasn't referring to the networking aspects of it (WebSockets have not been around 10 years). huhtenberg: You're right. It's very similar to inetd - that's why the first sentence in the websocketd description is "Like inetd, but for WebSockets". The thing it adds on top of inetd is it takes care of the protocol so the underlying app doesn't need to. Namely HTTP WebSocket handshaking and data framing.
- bsg75 13y agoCurious as to the approach of pulling a project local Go distribution instead of using the default. Is this to ensure Go version compatibility?
- chimeracoder 13y ago> Is this to ensure Go version compatibility Huh? There are no version compatibility issues with Go. Just use the most recent version of the compiler to compiler your code. Anything written since Go 1.0 is compatible with all the 1.x compilers. Anything written before that (which is truly ancient code at this point) can be updated automatically with the 'go fix' command.