Skip to content

Sockets joining two messages. #53059

Description

@arreehm

Version

18.20.2

Platform

Linux # 6.8.0-31-generic #31-Ubuntu SMP PREEMPT_DYNAMIC Sat Apr 20 00:40:06 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

Subsystem

No response

What steps will reproduce the bug?

You need to use socket, in a way, that you create middle man server, handling more socket connections. Then when you send message trough middleman, and message from middleman, it ends up with joining two different net.server.write's to one statement that is received by target application.

Middle man is passing message "connectionEstablished" to both ends of socket pipe, then I recieve

{"context":"connectionEstablished"}{"context":"test","data":"whatever"}

In the application, because it joined data with what application sends, it's two totally different writes called.

How often does it reproduce? Is there a required condition?

Every time a send a socket message trough middle man.

What is the expected behavior? Why is that the expected behavior?

I expect it to be two different messages per two different socket.write calls.

What do you see instead?

{"context":"connectionEstablished"}{"context":"test","data":"whatever"}

I expect it to be two different messages.

Additional information

Am I missing something? If described behaviour is expected, how to differentiate between specific message at end point? Like I need to rewrite JSON.parse because of that, which seems to be utterly wrong.

Activity

  1. arreehm commented on May 19, 2024

    @arreehm
    Author

    Do you want repo of whole this process?

  2. arreehm commented on May 19, 2024

    @arreehm
    Author

    +"\u0004" at write, and parsing on recieving socket solves the problem, but IMO it should be automatic, so reclassify this as feature request if you wish.

  3. avivkeller commented on May 20, 2024

    @avivkeller
    Member

    Do you want repo of whole this process?

    Yes, providing reproduction steps (and code) is the best way for people to see and understand what went wrong

  4. arreehm commented on May 20, 2024

    @arreehm
    Author

    https://github.com/arreehm/socketConnector

    I don't know if it's expected, but it mostly doesn't happen.

  5. arreehm commented on May 20, 2024

    @arreehm
    Author

    Like I understand, if it's sends in a buffer at one time it's two different thing, but I never managed to break the JSON.parse being in on('data', like that, I fixed it with unicode symbol, but anyhow, it feels broken.

  6. arreehm commented on May 20, 2024

    @arreehm
    Author

    Now I see, that I should write my own encoding, where there is size of JSON specified and read up buffer up to that length, but it takes away ease of javascript, I expected it to be done by default.

  7. arreehm commented on May 20, 2024

    @arreehm
    Author

    Solution I have is to encode/decode JSON String by following thing:

    const { Buffer } = require('node:buffer')
    
    const encode = (string, encoding)=>{
        string = Buffer.from(string, encoding)
        let length = string.byteLength
        length = Buffer.from(`<${length}>`)
        let buffer = Buffer.concat([length, string])
        return buffer
    }
    
    const decode = (buffer, encoding, perChunk)=>{
        let stop = false
        while(!stop) {
            let index = buffer.indexOf('>')
            let sub = buffer.subarray(1, index)
            let length = Number(sub.toString())
            let ourChunk = buffer.subarray(index+1, length+index+1)
            perChunk(ourChunk.toString())
            buffer = buffer.subarray(length+index+1)
            if(buffer.byteLength===0) stop = true
        }
    }
    
    module.exports = (encoding)=>{
        return {
            encode: (string)=>{
                return encode(string, encoding)
            },
            decode: (buffer, perChunk)=>{
                return decode(buffer, encoding, perChunk)
            }
        }
    }
  8. github-actions commented on May 21, 2026

    @github-actions
    Contributor

    This issue has been marked as stale due to 210 days of inactivity.
    It will be automatically closed in 30 days if no further activity occurs. If this is still relevant, please leave a comment or update it to keep it open.

  9. added
    staleIssues and PRs marked stale due to inactivity and scheduled for automatic closure.
    on May 21, 2026
  10. github-actions commented on Jun 20, 2026

    @github-actions
    Contributor

    This issue has been automatically closed after 30 days of inactivity following its stale status (no activity for a total of 240 days).
    If this is still relevant, feel free to reopen it or leave a comment with additional details so we can continue the discussion.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    staleIssues and PRs marked stale due to inactivity and scheduled for automatic closure.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions