Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Vitaly Shukela
    @vi
    Anyway discussing the error without showing the full command line here is rather pointless.
    Alkor San
    @alkorsan
    I use broadcast-reuse: only in the exemple you gaves to me using nc
    ok
    I will update the same issue to continue there
    Vitaly Shukela
    @vi
    Pushed major README update. Please review.
    Alkor San
    @alkorsan
    ok thank you
    Vitaly Shukela
    @vi
    There are still remaining "specifier" term usages, but that ubiquitous as before.
    Your Chromium example is included as one of opener README examples.
    Alkor San
    @alkorsan
    good
    Vitaly Shukela
    @vi
    "Websocat v1.0.0 release" is near.
    (although there are known bugs and thigs to improve)
    Alkor San
    @alkorsan
    good
    I like the new doc :)
    Vitaly Shukela
    @vi
    There also new --queue-len option that helps to battle against A client's sink is NotReady.
    Alkor San
    @alkorsan
    oh good
    Vitaly Shukela
    @vi
    Also you can use reuse-raw: instead of reuse-broadcast: if you plan to have only one active incoming TCP connection at a time.
    Alkor San
    @alkorsan
    please now where is the -l ? is it integrated now ?
    Vitaly Shukela
    @vi
    -l is now the default in --text mode (which is also default now).
    Alkor San
    @alkorsan
    great , yes multiclient is an extreme case I think
    ah good to know
    Vitaly Shukela
    @vi
    There is --no-line and more radical --no-fixups instead.
    Note that in reuse-raw: mode it may stop reading from a WebSocket (which in turn makes Chromium stop writing to WebSocket) if there are no connection clients.
    In reuse-broadcast: mode messages simply got dropped when nobody is connected.
    Alkor San
    @alkorsan
    it seems safer to use then reuse-raw: , right?
    Vitaly Shukela
    @vi

    Also instead of this TCP-in-the-middle way maybe you can just use

    websocat cmd:./your_script.sh ws://...

    to drive the session?

    Alkor San
    @alkorsan
    ah yes this solution have a problem I couldn t solve:
    Vitaly Shukela
    @vi
    Depending on definition of "safer".
    Alkor San
    @alkorsan
    I will test both then and compare
    Vitaly Shukela
    @vi
    Even with reuse-raw: there expected to be lost messages, because of there is no good propagation of "can't write to this connection" status (which happens when somebody disconnects).
    Alkor San
    @alkorsan
    using sh-c: or cmd: I remember I could n t make for exemple the command timeout to work inside the subshell, that is why I prefered to use reuse-broadcast: , because I can use it in the same shell without limitation
    Vitaly Shukela
    @vi
    -E (--exit-on-eof) option can also improve this, as dead connections would go away sooner rather than later.
    What is the problem with command timeout?
    Alkor San
    @alkorsan
    it stops working inside sh-c:
    Vitaly Shukela
    @vi
    What is the command timeout?
    it stops working inside a subshell as I had read in stackoverflow
    Vitaly Shukela
    @vi
    So it is the timeout I was thinking about... Should websocat itself be timed-out or some particular command inside script executed by websocat?
    I don't expect any surprises involing timeout with websocat a top of usual timeout's trickiness.
    Alkor San
    @alkorsan
    I needed the timeout because I dodnot know how to make websocat cut the conexion and continue withe next step
    but you gaved me other solutions after that solved that
    Vitaly Shukela
    @vi
    Very basic example works for me:
    websocat -t - cmd:'while true; do timeout 1 sh -c "echo Type something; read A; echo You typed \$A." || echo timed out; sleep 1; done'

    cut the connection and continue withe next step

    Cut the entire WebSocket connection or just a step in WebSocket session?

    Alkor San
    @alkorsan
    oops sorry , yes just a step in WebSocket session
    Vitaly Shukela
    @vi
    Just use bash's read -t?
    Alkor San
    @alkorsan
    read -t had problems too: I have to know the number of lines I will receive to use it
    and chrome send diferent lines everytime ; i can t teel read how much lines I will receive
    Vitaly Shukela
    @vi
    In websocat's default text mode 1 line == 1 message. As soon as you receive a message, exactly one read -t should return, as far as I understand.
    Alkor San
    @alkorsan
    yes true; but I need to receive more than one message sometimes so read did t gave this flexibility
    Vitaly Shukela
    @vi
    Are you familiar with expect(1) program? It should be able to drive websocat too. Maybe it is a good choice when there are multiple line types and timeouts involved.
    Alkor San
    @alkorsan
    yes