feat(useWebSocket): enhence heartbeat

[azaleta]

Description

issue: #2096

1. a new option pongTimeout -> after sending ping, could not recieve any response in pongTimeout, then close the socket
2. skip the pong message in ws.onmessage()

Additional context

---

What is the purpose of this pull request?

• Bug fix
• New Feature
• Documentation update
• Other

Before submitting the PR, please make sure you do the following

• Read the Contributing Guidelines.
• Read the Pull Request Guidelines.
• Check that there isn't already a PR that solves the problem the same way to avoid creating a duplicate.
• Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. fixes #123).
• Ideally, include relevant tests that fail without this PR but pass with it.

[volarname]

useWebsocket stopeed working in version v9.2.0, so something is broken now

[azaleta]

@volarname can you describe the situation or offer some repo?
did some easy test and don't see stop working

<script setup lang='ts'>
import { useWebSocket } from '@vueuse/core'

const { status, data, send, open, close } = useWebSocket('wss://ws.postman-echo.com/raw', {
  onMessage: (ws: WebSocket, event: MessageEvent) => {
    console.log('get message')
  },
})
const i = ref(1)
function dodo() {
  console.log(status.value)
  send(`test${i.value}`)
  i.value++
}

function dodo2() {
  console.log(data.value)
}
</script>

<template>
  <div>
    <button m-1 p-1 @click="dodo">
      123
    </button>

    <button m-1 p-1 @click="dodo2">
      223
    </button>
  </div>
</template>

[kellerza]

From this code a "pong" seems to be mandatory... and probably why it broke. My server also don't send pongs and have some quiet times

[azaleta]

@kellerza
heartbeat is an option, if the sever don't support it, I think you should not trigger ping.
if you do send ping to sever of this type, it will close socket because could not get pong response -> this will consider as server down.

My concept is

1. send heartbeat is you enabled it in option (also start a timer pongTimeoutWait to close socket after a period of time)
   https://github.com/vueuse/vueuse/blob/main/packages/core/useWebSocket/index.ts#L260-L277

2.every time you get a server response, pongTimeWait will be clear by resetHeartbeat
Also if the response is PONG, the response will be skipped.
https://github.com/vueuse/vueuse/blob/main/packages/core/useWebSocket/index.ts#L244-L258

[kellerza]

Here we are talking about an app layer heartbeat, so there is no right/wrong on how to implement it.

Up to 9.2.0 you can freely enable the heartbeat without any support from the server.
In 9.2.0 the server now needs to respond immediately (or a pong)

Not necessarily wrong, but the behavior changed enough to bring down my and @volarname's websockets after the upgrade

[kellerza]

fyi, not arguing about the behavior. I already added the pong to my server and will go to 9.2.0 eventually...

[kellerza]

This also affects autoReconnect. Once the pong closes the websocket you need to perform an explicit open

[ssickles]

One thing I ran into is that it doesn't appear that your ping message is being sent with the correct opcode. It is coming across as a TextMessage (0x1) for me so my server wasn't recognizing the ping. According to the websocket spec, you should use an opcode of 0x9. And you might want to also check the pong message for an opcode of 0xA.

https://www.rfc-editor.org/rfc/rfc6455#section-5.5.2

[kellerza]

@ssickles this it seems that the browser/JS API only exposes TextMessages. So this is an application layer heartbeat, rather than the Websocket ping/pong that uses other opcodes from the RFC

[MatiasHiltunen]

I'm having a problem with firefox "Firefox can’t establish a connection to the server at ws://127.0.0.1:8080/ws.". Connection status is open but running send function gives the previous error. If set to autoReconnect status wont reach the open state at all and will continue trying to establish the connection. With chrome based browsers there is no issue.