Added a quiet mode - Githubissues

websockets / wscat

WebSocket cat

MIT License

2.25k stars 223 forks source link

Added a quiet mode #86

Open nebloc opened 5 years ago

nebloc commented 5 years ago

I was testing a service that pinged a lot, and would interrupt typing, so I added a flag -q, --quiet that would silence the ping control frame (pong and close control frames handled same as usual) from the console.

May be useful for others 🤷‍♂️ 😄

lpinca commented 5 years ago

Thank you for the PR. Some thoughts:

I think --quiet is not a good name for the option. It's too general when in reality it only prevents ping messages from being printed.
A server or client could spam pong frames for no particular reason so I think the option should also silence the pong messages or we need two separate options, one for pings and one for pongs.
Doesn't this also happen with data messages? If the other peer sends a lot messages while the user is typing, doesn't it cause the same problem?

nebloc commented 5 years ago

Agreed about wording, but also didn't want it to be too long (i.e .--silence-incoming-pings) any suggestions? 😅
A server could spam pongs, but I was under the impression that the tool was geared towards debugging and so if it is spamming pongs when you aren't pinging then it is a bug... would you ever want to silence it?

At the same time wouldn't hurt to have, but should not be under the same flag. I am testing a service that will ping often and I don't need to know, just pong back, but when I ping I want to ensure it pongs me.

Unsure, I have not tested with incoming messages; probably would but unsure how to handle... before ping store what is being written and write it back out in the correct order after?...

lpinca commented 5 years ago

My point is, if this happens with everything that is written (data messages, pings, pongs) why this only take into account pings? Not sure if it's possible or how hard it will be but isn't it better to try to solve the issue differently? Ideally what is written should not mess up user input.

jonbo372 commented 5 years ago

Perhaps a slightly different view of the same problem. To me, ping/pongs are part of the underlying protocol. In the same way I don't see the HTTP upgrade request, I don't want to see the websocket control frames in normal operation. Based on that, perhaps another option for verbose control frames? By default, no control frames are printed but --verbose-control-frames would enable it. This would then include all control frames, which currently there are only three defined (as far as I know). Close, Ping & Pong.

Does that make sense?