Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Alkor San
    @alkorsan
    -0 :+1:
    Vitaly Shukela
    @vi
    For completely arbitrary messages you need packet-oriented protocol like UDP or unix-seqpacket (obviously without the line mode)
    Note that there is maximum size of the message. Overriding it is also a planned option.
    Alkor San
    @alkorsan
    what is the max size now?
    Vitaly Shukela
    @vi
    65536 bytes.
    Alkor San
    @alkorsan
    thanks
    i m still chocked with the sleep 1 that broke the exemple, why -l was the solution to this? sleep doesn t do anything there i beleive
    Vitaly Shukela
    @vi
    Do you know the difference between TCP and UDP?
    Alkor San
    @alkorsan
    yes
    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