Wishlist?
Anyone wants to speculate about good to add features?
My list is mostly contribs to add:
- websocket endpoint benchmarking tool
- basic demultiplexing example wrapper
- improved documentation, tutorials, cookbooks, etc
- easy installation from standard package managers (apt-get, brew, chocolatey, etc)
I'd also like to see if there's features we can remove or cleanup before hitting 1.0.0 stable (it becomes much harder after that).
Ah.. good point on 1.0
- we probably need to define what LEVEL means in --loglevel=LEVEL and clarify things
- make sure IPv6 works
- I personally really want to do --reverselookup=false as default
- think if we need custom error pages for 403/404 and other ones
- since devconsole, dir, staticdir, cgidir, and command are all forms of routing.... maybe we should have universal "--route plugin:src:dest" or similar sort of option... that would also make ability to mix devconsole and staticdir
Since we rolled out changes that were done in Server/Handler split we need to re-check how websocketd handles programs that ignore SIGTERM and/or take some time to terminate.
I'd prefer easy installation from standard package managers over any additional features.
Another vote for package manager integration.
Removal/non-removal of CGI also seems to be a candidate to decide before 1.0 (see #134, #138)
Sorry to be late in here!
- Broadcast support. Haven't seen any mentions of it.
I'd like to have the possibility to use separate chain certificates (intermediate certificate) and server certificates. So there would be another option like --sslkey and --sslcert, for example --sslchain
@Aginor404 why? They are concatenated eventually, I do not see benefit of splitting those.
I don't see any benefit either, in fact I don't like it, but some of the certificate authorities do split them nowadays, which is why, for example, the Apache guys have the option to just put them into the directory like they are and include both in the config file.
It looks like this: SSLCertificateFile /etc/ssl/crt/public.crt //Locate Certificate File SSLCertificateKeyFile /etc/ssl/crt/private.key //Locate Private Key File SSLCertificateChainFile /etc/ssl/crt/intermediate.crt //Locate the Intermediate File
Maybe I suck at concatenating, but I had the problem that after just putting them into one file together made them not work (not be recognized as valid). I ended up installing websocketd on another server that does not have an intermediate certificate.
Basic auth of some sort mentioned in #172
I'd like to have the possibility to send/receive multiple-line messages for integration Asterisk server API (AMI - Asterisk management interface) with my SuiteCRM.
Hi,
I've just started using websocketd and it's so nice. I like the developer console too.
I would love to use websocketd as a websocket client sending messages interactively in command line.
It can do that in the browser using --devconsole and change the address to the websocket server.
I wish I could do that in command line too.
I had a look through the documentation but I haven't figured out if this feature is already there (and if so so how to use it)
Is that something websocketd already supports ? If not, would that be something worth adding ?
Thank you, George
You kind of can ask your websocketd for stuff using curl:
curl -s -H "Connection: Upgrade" \
-H "Upgrade: websocket" \
-H "Host: localhost:8080" \
-H "Sec-WebSocket-Version: 13" \
-H "Sec-WebSocket-Key: ok" \
http://localhost:8080 \
| hexdump -C
But I doubt it's what you want... I used nodejs wscat before but it stopped installing cleanly for me now, not sure what's there... Anyone has other tools they use?
Thank for the quick answer.
Here's what I'm doing using the html interface:
open ws://127.0.0.1:7890/
send {"type":"list_connected_devices"}
onmessage {"type":"list_connected_devices","devices":[]}
I imagine a websocket client for nodejs/python/java/etc. will do the trick.
I wish I could do the same using command line instead of the web interface with websocketd.
Special very fast mode without start and stop application for each request. I do not tell about FastCGI, I tell about mode like FastCGI, I tell about mode without start and stop application for each request. I think this is very important for this project. If you do not make it then this make others and they will be faster than your project.
I would love to see the ability to subscribe to stderr on a second websocket.
@meisterluk I like this idea. Not sure if it should be on different port or same, just with query string in URL... Say url?stderr=true&stdout=false would give you only stderr socket...
What do you think? Any good potential usecases? IMO new ticket could be started for this.
Anyone else wants this? Problem is that subscribing to stderr and stdout on two different sockets requires coordination :( So when you subscribe to output you should specifically request "same stderr" and this is only possible via having some kind of ID for out/err pair.
Solution I suggest above with choices "out or err or out+err" is somewhat reasonable to keep things down to single socket but it might be not the best for people who want this feature for something practical.
- UDP connection to server program, for binary data
Correct me if I'm wrong, but I don't see a mechanism for websocketd to do packetized binary transfers to and from a the data-serving program. Since a simple datagram server is easy to write in most languages, and in Linux can be done using a local socket, UDP endpoint support in websocketd would simplify implementation of binary Websockets.
My personal wish is a rewrite of this in pure C
Can add support sending both stdout and stderr messages of the process to the websocket client? Personally I use the following code for the purpose.
https://github.com/joewalnes/websocketd/blob/master/libwebsocketd/process_endpoint.go#L98
func (pe *ProcessEndpoint) StartReading() {
//go pe.log_stderr()
if pe.bin {
go pe.process_binout()
} else {
//go pe.process_txtout()
go pe.process_txt(pe.process.stdout, pe.process.stderr)
}
}
func (pe *ProcessEndpoint) process_txt( readers ...io.Reader ) {
var wg sync.WaitGroup
for _, r := range readers {
wg.Add(1)
reader := r // this line to capture variables, without which, will always read the last reader
go func(){
defer wg.Done()
buf := bufio.NewReader(reader)
for {
buf, err := buf.ReadBytes('\n')
if err != nil {
if err != io.EOF {
pe.log.Error("process", "Unexpected error while reading STDOUT from process: %s", err)
} else {
pe.log.Debug("process", "Process STDOUT/STDERR closed")
}
break
}
pe.output <- trimEOL(buf)
}
}()
}
wg.Wait()
close(pe.output)
}
is anyway can A(client) send message to B(client)?