Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Vitaly Shukela
    @vi
    Currently it always waits for the \n byte.
    After receiving it all preceeding bytes (maybe including the \n itself if --linemode-retain-newlines) are called a message and proceed to the other "address".
    Also the reverse: each message is converted to a line (\n is forced at the end, internal \ns are replaced by spaces).
    Alkor San
    @alkorsan
    how can the message contain \n and in the same time websocat wait for \n to close?!!
    Vitaly Shukela
    @vi
    I mean the reverse direction (e.g. from websocket to console).
    "wait for \n and closing" happens in to-websocket direction, "replace with spaces and append \n" happens in from-websocket direction.
    You can see it with --dump-spec debugging option. It shows the overlay structure. With --line (or simple mode) you'll see Msg2line and Line2Msg overlays.
    WebSocket is a packet-oriended protocol. It preserves message boundaries.
    Alkor San
    @alkorsan
    yes
    Vitaly Shukela
    @vi
    Do you understand now why sleep 1 and --line interact?
    Alkor San
    @alkorsan
    yes I understand it very well thank you, but line is not clear yet, here is a question that maybe it clear it

    from the short description:

    -l, --line Make each WebSocket message correspond to one line

    does this mean that websocat consider every line (\n) a message? right?

    Vitaly Shukela
    @vi
    Yes. For example, printf '\n\n\n' | websocat ws://echo.websocket.org should send three empty messages.
    Alkor San
    @alkorsan
    oh I see , i thought it means that every message composed by multiple lines will be considered one line
    i was totally wrong
    so sleep 1 made websocat think that the message has arrived complete and he sent a half message to chrome , that s why gaved error, and --line corrected this by forcing websocat to wait for \n
    beautifull sir
    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?