Websocket still broken

[srjlewis]

I have tested the websocket and still does not work.

I have attached a screen shot below, I am using the recent release of v1.14.0

I have put a little script together that would make the websocket fail, if you change $items to a much lower value like 2, it will work.

$trapData = [];
$items = 100;
foreach (range(0, $items) as $i) {
    $trapData[$i] = [];
    foreach (range(0, 20) as $j) {
        $trapData[$i][$j] = PHP_INT_MAX - random_int(1, 1_000_000);
    }
}

trap($trapData);

[roxblnfk]

I tried to reproduce your case and ran the provided code snippet. It works fine for me.

Even much larger payloads are received correctly.

[petrdobr]

Hello, @srjlewis

I want to take on this issue, so I tried to reproduce this bug too. I tried sending long messages with your script and with other methods, starting a local trap server and starting the server inside the Docker container - nothing helped to reproduce the bug.

Can you please give a bit more information about it?

• Is it still reproducing with newer versions of trap? Or only with 1.14.0?
• Can you specify any details about the environment you are running the trap server on?

Thank you!

[srjlewis]

Hi @petrdobr

Yes I can reproduce the error with v1.15.1 as shown below, I have sent a small payload first which is succesful, but then fails with the large payload.

I have used export TRAP_UI_HOST=0.0.0.0 to be able to use frountend via another machine which is chrome running on a mac M1, the server is running has a VM on the mac, using Parallels Desktop

trap('small data');

$trapData = [];
$items = 100;
foreach (range(0, $items) as $i) {
    $trapData[$i] = [];
    foreach (range(0, 20) as $j) {
        $trapData[$i][$j] = PHP_INT_MAX - random_int(1, 1_000_000);
    }
}

trap($trapData);

Here is the server setup

[petrdobr]

@srjlewis thank you for the information!

I actually managed to reproduce the bug using Parallels on a Mac as well. I tried doing so on Linux virtual machines, but got nothing.
I will try some ideas on how to fix it and report back with results soon.

[srjlewis]

@petrdobr glad you are to reproduce the bug

To clarify, Alma 10 is the server component running within the VM on parallels, the VM host is a M1 Mac, both using aarch64

The frontend is running on the VM host using chrome,

Which I believe is the same setup you are using to reproducing the bug,

[srjlewis]

@petrdobr

I tought I would narrow down at what size does this error happen at, to my supprise I can push the payload size up in increments, there is the following code I am using to do it.

hope it might help in some way

$startLengh = 100_000;
$growth = 1_000;
$iterations = 100;

// should cause a websocket error, expect if run a second on the same frontend socket
trap(['size' => (int) ($startLengh * 1.5), 'data' => str_repeat('a', $startLengh * 2)]);

// wait for socket timeout
// seen both error "Invalid frame header" or "Could not decode a text frame as UTF-8."
sleep(10);

// slower growth to push past previous error threshold, for extra fun refresh the frontend in the middle
foreach (range(0, $iterations) as $i)
{
    $lengh = $startLengh + ($growth * $i);
    trap(['size' => $lengh, 'data' => str_repeat('a', $lengh)]);
    sleep(1);
}

// Sometimes "Invalid frame header" error is seen at any time, looks like an issue with partial processed writeQueue, or
// multiable messages being sent at the same time, but not confirmed, looks to happen at the 10sec sleep, or around when a ping happens.

[srjlewis]

Looking at line 164, socket_write is not guaranteed to write all bytes in $data, which would explain why there is a cut off in max size at first and why I am able to push the TCP buffer bigger.

trap/src/Socket/Client.php

Lines 161 to 172 in bd409cd

	private function writeQueue(): void
	{
	foreach ($this->writeQueue as $data) {
	\socket_write($this->socket, $data);
	// Logger::debug('Respond %d bytes', $x);
	}
	\socket_set_nonblock($this->socket);
	$this->writeQueue = [];
	$this->toDisconnect and throw new ClientDisconnected();
	}

This makes it behaive a lot better and the messages are showing in the frontend, but there is a reset of the websocket happening on the frontend still at the same point that a error would of been shown.

    private function writeQueue(): void
    {
        foreach ($this->writeQueue as $data) {
            $bytes = 0;
            while ($bytes < \strlen($data)) {
                $bytes += \socket_send($this->socket, substr($data, $bytes), \strlen($data) - $bytes, 0);
            }
            // Logger::debug('Respond %d bytes', $x);
        }
        \socket_set_nonblock($this->socket);

        $this->writeQueue = [];

        $this->toDisconnect and throw new ClientDisconnected();
    }

[srjlewis]

Hi @petrdobr

The above fix in writeQueue is working well, I have now been looking at the connection with wireshare to find that the server is sending a TCP FIN flag on the last packet of the websocket frame, needs further looking into,

[roxblnfk]

Let's see if Copilot can save us time.

[srjlewis]

@roxblnfk

I have tested copilots version, I am not getting the socket resets due to the processing of the error state.
it is looking good.

[petrdobr]

Hello, @srjlewis,

you did great research! I am glad it finally led to a solution.

@roxblnfk I also tried Copilot's version on a Mac inside a VM, and it fixed the bug with failing long messages for me too.