Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Alkor San
    @alkorsan
    thank you very much
    Vitaly Shukela
    @vi
    (Actually I've checked and found that zero-length messages are not handled properly currently: it thinks that it's EOF and exits)

    so sleep 1 ... wait for \n

    Yes.

    Such arbitrary message splitting is OK if you, for example, trasfer large file using a websocket.
    Alkor San
    @alkorsan
    yes
    Alkor San
    @alkorsan
    I think that --linemode-retain-newlines will never be needed, because you told me that --line means 1 line = 1 message , so a message will never have more than one \n ? right?
    Vitaly Shukela
    @vi

    --linemode-retain-newlines does not affect number of messages.

    printf 'A\nB\nC\n | websocat --line --linemode-retain-newlines should result in messages A\n, B\n and C\n.
    printf 'A\nB\nC\n | websocat --line should result in messages A, B and C.

    Alkor San
    @alkorsan

    in an attempt to test your last message I created a server and tested with, but the following is happening:
    a created a server with websocat

    websocat ws-l:127.0.0.1:8888 -

    then I used websocat as client to connect to this server (using the simple one-argument mode)

    printf 'A\nB\nC\n' | websocat ws://127.0.0.1:8888

    interactively also doesn't work
    what works is the two-arguments mode like this websocat ws://127.0.0.1:8888 -

    using websocat one argument mode, wireshark shows that the server is receiving the messages and responding correctly with [ACK] . the strange thing is that the server seems to buffer the messages when I use the one argument mode, and if I use two argument mode then the server will print all the old messages that he received when using the client as one argument mode.
    should I open an issue in github?

    Alkor San
    @alkorsan
    maybe it s better to open a new issue in github , like that the people can follow what s happen and how things evolvs, and learn from your answers, no?
    Alkor San
    @alkorsan
    i think i did understand one thing at less:
    --linemode-retain-newlines only tells to --line don t remove the new lines that you remove secretly, because --line is removing every \n that it found.
    could you explain please why --line have to remove the new lines? the expected is to send every line as a message, now if the server accepts messages without \n it s ok , but what if the server don t accept messages without \n like in the case of websocat server? it is a puzzle
    i think i found the answer:
    Alkor San
    @alkorsan
    you are right we have to have both options --line and --linemode-retain-newlines, because when using --line we are telling websocat to cut the message by new lines and considere every line 1 message, so \n here now is considered a delimiter and not part of the data (payload), so it s obvious and obligatory to remove \n , and if i want to preserve \ns then I have to use --linemode-retain-newlines
    Alkor San
    @alkorsan
    so the problem in fact was not in websocat but in the description of the manual , because it doesn't tell you it will remove \n. --line short description should contain i think this : \n will be removed and if you want to preserve them use --linemode-retain-newlines.
    the actual short description of --line doesn't even talk about --linemode-retain-newlines , and --linemode-retain-newlines short description which is a child of --line is talking about --line, it should be the inverse i think or both which is better.
    Alkor San
    @alkorsan

    Alkor San
    @alkorsan

    using two-argument mode:
    this will send my multi-line payload as 1 message and will retain \n . that is good

    $  printf 'A\nB\n' | websocat - ws://echo.websocket.org/
    A
    B

    now look please when using one-argument mode:
    this will send 2 messages, every line is considered a 1 message!, and it will remove the \n from every message sent.

    $  printf 'A\nB\n' | websocat ws://echo.websocket.org/
    A
    B
    Alkor San
    @alkorsan
    why both examples don't have the same behavior? can one-argument mode have the same behavior like two-argument mode?or i miss something?
    Vitaly Shukela
    @vi
    It was already discussed before.
    1-arg 2-arg
    text binary
    2 messages 1 message
    no newlines with newlines
    1-arg mode is user-friendly mode, 2-arg mode is raw mode.
    There should be a way to send both messages without newline and with newline. It is not certain which mode should be default. But I expect WebSocket messages to be typically 1-line serialized JSON (without a newline at the end).
    Maybe in future I also add special JSON powers to websocat, so that you can specify {a:5, b:qwer} and it would send {"a":5, "b":"qwer"} (or something like that).
    Alkor San
    @alkorsan
    aaah it is caused by text then , ok ok, then it s logic now , i don t know how new comers will know this by them self, it s imposible to know that difference alone
    Vitaly Shukela
    @vi
    What caused by text?
    In your example you should probably see ABC (without newlines).
    Alkor San
    @alkorsan
    when mode is text websocat will parse the message , that s why it removes \n. and in binary mode websocat don t touch the message, so i think the behavior i had was caused by the text mode as you just explained to me, no?
    Vitaly Shukela
    @vi
    What behaviour?
    Alkor San
    @alkorsan
    the behavior of the 2nd exemple, the message is cutted by \n , and sent without \n
    Vitaly Shukela
    @vi
    websocat ws-l:127.0.0.1:8888 - + printf 'A\nB\nC\n' | websocat ws://127.0.0.1:8888 should give ABC (withhout newlines)
    Alkor San
    @alkorsan
    oops sorry , are you talking about my first issue or my second? i wrote two diferent issues
    maybe I open an issue in github? this is becoming dificult to follow?
    Vitaly Shukela
    @vi
    Of course.
    Alkor San
    @alkorsan
    ok I will open two issues now
    Alkor San
    @alkorsan
    is it correct to say that websocat uses \n as a delimiter? the json may contain \n, or the server may force you to send \n
    why it is not EOF the delimiter?
    Vitaly Shukela
    @vi
    JSON may only contain \n as a whitespace, not as a proper content.

    EOF the delimiter

    What if you want to send multiple messages?

    Alkor San
    @alkorsan
    then -0 is what we need I think
    this will solve a lot of problems
    Vitaly Shukela
    @vi
    is it correct to say that websocat uses \n as a delimiter?
    In --line mode websocat uses \n as a line terminator. In non---line-mode it is just another byte.
    ("delimiter" or "separator" is like , in JSON; "terminator" is like ; in C)
    Alkor San
    @alkorsan
    thank you
    Vitaly Shukela
    @vi
    But in mode without --line, but with --one-message it is indeed more reasonable to read until EOF insteadd of just doing one read operation.
    In TODO list...
    Alkor San
    @alkorsan
    yes
    Vitaly Shukela
    @vi
    Do you think it is a good idea about those [A]s in help message (hiding options from usual help and showing them only in --long-help)?
    Alkor San
    @alkorsan
    in fact a hate command lines that hide the info and you have to read all the short description to know that there is more. but some command lines do this
    there is not a lot of flags , why hide them?
    and this flag is needed for the simple mode --linemode-retain-newlines, i see it s hiding!
    Vitaly Shukela
    @vi

    Because of there are (or will be) many tricky flags that may confuse users.

    Obviously, --long-help and the fact that some flags and options (and later address types) are hidden is mentioned in the help message.
    Try websocat --help.

    --linemode-retain-newlines shouldn't be needed much. Just slap -l on server side part and it would also look more nice.
    Line mode on client should correspond to line mode on server.