Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Alkor San
    @alkorsan
    stateless stateful?
    Vitaly Shukela
    @vi
    Stream-oriented vs message-oriented.
    Shell's pipeline | is like TCP.
    You feed bytes to it on one side, and get bytes from other side. One write(2) operation can result in multiple read(2)s (and vice versa).
    Vitaly Shukela
    @vi
    Imagine people arriving by bus, staying in line (queue) and getting to a stadium. A portion of people leaves the bus and joins the line. Another portion (from other side of the queue) is allowed to proceed by security guards.
    A "chunk" of people from one bus won't necessarily lead to the same "chunk" allowed in.
    Arraiving buses: [abcdef] [ghijklmn] [opqrst]
    Line: abcdefghijklmnop
    Allowed in: [abcd][efgh][ijkl][mnop][qrst]
    Websocat's --one-message (without --line) mode is just to get one chunk and call it a day message.
    Websocat's --one-message --line is to get chunk after chunk until we see the LF character.
    Without --line boundaries between messages are defined by underlying operating system behaviour which is typically not guranteed (like boundaries between content in packets in TCP).
    And sleep 1 ensures that partial data actually gets seen by websocat (not joined together by operating system before getting to websocat).
    Alkor San
    @alkorsan
    fantastic thank you
    Vitaly Shukela
    @vi
    Automatic --line insertion in advanced mode needs to be implemented carefully. It should discriminate stream-oriended addresses like exec: or tcp: or - and packet-oriended like udp: or seqpacket: and insert the overlays only to the former.
    (There may be special UNIX-specific addresses like exec-seqpacket: in future).
    Alkor San
    @alkorsan
    can I say that --line will force websocat to wait until it receives EOF?
    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