Theldus / wsServer

wsServer - a tiny WebSocket server library written in C
https://theldus.github.io/wsServer
GNU General Public License v3.0
422 stars 80 forks source link

Server closes the socket after a time. How do I ensure it stays open? #87

Open ihmpartners opened 7 months ago

ihmpartners commented 7 months ago

Description

The server socket closes after a time ( varies )

I'm not sure if it's the browser/javascript end that is abandoning the connection or the server itself that's closing it .......

My web page tries to send a query to my socket and I get a 'WebSocket is already in CLOSING o CLOSED state' console message on the browser console.

Theldus commented 7 months ago

Hi @ihmpartners, Normally this should not happen, since wsServer only closes the connection if it receives a CLOSE frame or if it receives an invalid frame.

A second option is if your browser is sending PING packets and wsServer is not responding to them, which is a bug and needs to be fixed. A third option is if your browser is silently losing connection with the wsServer, such as a weak WiFi signal, etc.

In any case, the dc75fda commit adds a few more messages reporting the proper close reason, which may help us investigate this further. You can build wsServer in verbose mode with:

# Makefile
$ CFLAGS="-DVERBOSE_MODE" make

# or via CMake:
$ mkdir build && cd build/
$ CFLAGS="-DVERBOSE_MODE" cmake ..
$ make

The verbose build should also report if it receives any type of malformed packet, etc.

The server socket closes after a time ( varies )

I know it varies, but can you give me an estimate? like under 30 minutes, more than 1 hour... I'll leave it running here and see if I can reproduce it too.

Is your client a browser? If so, which one? version, and etc too.

ihmpartners commented 7 months ago

The browser is chrome. The whole setup is running on a single machine. Ubuntu Linux 22.04 LTS. It is a development for an embedded device using web presentation. The sockets deliver realtime info about back end process data.

( On the actual platform the browser will be a QT webview instance. )

Disconnects are < 30 mins, sometimes just a few minutes.

I am not seeing errors from my server program.

Will pull and compile and let you know.

Ian

On Tue, 6 Feb 2024, 17:32 Davidson Francis, @.***> wrote:

Hi @ihmpartners https://github.com/ihmpartners, Normally this should not happen, since wsServer only closes the connection if it receives a CLOSE frame or if it receives an invalid frame.

A second option is if your browser is sending PING packets and wsServer is not responding to them, which is a bug and needs to be fixed. A third option is if your browser is silently losing connection with the wsServer, such as a weak WiFi signal, etc.

In any case, the dc75fda https://github.com/Theldus/wsServer/commit/dc75fda9a064bc0622e1e83c1ba29f974de58a55 commit adds a few more messages reporting the proper close reason, which may help us investigate this further. You can build wsServer in verbose mode with:

Makefile

$ CFLAGS="-DVERBOSE_MODE" make

or via CMake:

$ mkdir build && cd build/ $ CFLAGS="-DVERBOSE_MODE" cmake .. $ make

The verbose build should also report if it receives any type of malformed packet, etc.

The server socket closes after a time ( varies )

I know it varies, but can you give me an estimate? like under 30 minutes, more than 1 hour... I'll leave it running here and see if I can reproduce it too.

Is your client a browser? If so, which one? version, and etc too.

— Reply to this email directly, view it on GitHub https://github.com/Theldus/wsServer/issues/87#issuecomment-1930434462, or unsubscribe https://github.com/notifications/unsubscribe-auth/AARIWSRCRJXUXPMJJP3E33LYSJSJXAVCNFSM6AAAAABC2M7O26VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMZQGQZTINBWGI . You are receiving this because you were mentioned.Message ID: @.***>

ihmpartners commented 7 months ago

I start my server which opens 3 sockets on 6060, 6061 and 6062.

I open a web page which connects to 6060 and 6062 ( 6061 not required on this page )

You can see the initial message on each channel when the connection is made.

Waiting for incoming connections... Waiting for incoming connections... Waiting for incoming connections... Handshaked, response:

HTTP/1.1 101 Switching Protocols Upgrade: websocket Connection: Upgrade Sec-WebSocket-Accept: hu+QnyZAy7en+BGzyuYrfdLqP8c=


Data Connection opened, addr: 127.0.0.1 Handshaked, response:

HTTP/1.1 101 Switching Protocols Upgrade: websocket Connection: Upgrade Sec-WebSocket-Accept: RiboZpwVd2Lr2jK4LcCw5F1Djxk=


Alerts Connection opened, addr: 127.0.0.1 Received a Data message: {"Subscribe": ["currentTxp","LimProfile","overRangeOP"]} (size: 56, type: 1), from: 127.0.0.1 Received an Alert message: {"Type": "Subscribe"} (size: 21, type: 1), from: 127.0.0.1 An error has occurred while trying to read next byte <<<< About 3 minutes Data Connection closed, addr: 127.0.0.1 Closing: normal close An error has occurred while trying to read next byte Alerts Connection closed, addr: 127.0.0.1 Closing: normal close

<<<

If I open my web page, both connections establish. If I then just sit and wait it takes < 5 minutes before closing

Regards Ian

On Tue, 6 Feb 2024 at 17:48, Ian Molesworth @.***> wrote:

The browser is chrome. The whole setup is running on a single machine. Ubuntu Linux 22.04 LTS. It is a development for an embedded device using web presentation. The sockets deliver realtime info about back end process data.

( On the actual platform the browser will be a QT webview instance. )

Disconnects are < 30 mins, sometimes just a few minutes.

I am not seeing errors from my server program.

Will pull and compile and let you know.

Ian

On Tue, 6 Feb 2024, 17:32 Davidson Francis, @.***> wrote:

Hi @ihmpartners https://github.com/ihmpartners, Normally this should not happen, since wsServer only closes the connection if it receives a CLOSE frame or if it receives an invalid frame.

A second option is if your browser is sending PING packets and wsServer is not responding to them, which is a bug and needs to be fixed. A third option is if your browser is silently losing connection with the wsServer, such as a weak WiFi signal, etc.

In any case, the dc75fda https://github.com/Theldus/wsServer/commit/dc75fda9a064bc0622e1e83c1ba29f974de58a55 commit adds a few more messages reporting the proper close reason, which may help us investigate this further. You can build wsServer in verbose mode with:

Makefile

$ CFLAGS="-DVERBOSE_MODE" make

or via CMake:

$ mkdir build && cd build/ $ CFLAGS="-DVERBOSE_MODE" cmake .. $ make

The verbose build should also report if it receives any type of malformed packet, etc.

The server socket closes after a time ( varies )

I know it varies, but can you give me an estimate? like under 30 minutes, more than 1 hour... I'll leave it running here and see if I can reproduce it too.

Is your client a browser? If so, which one? version, and etc too.

— Reply to this email directly, view it on GitHub https://github.com/Theldus/wsServer/issues/87#issuecomment-1930434462, or unsubscribe https://github.com/notifications/unsubscribe-auth/AARIWSRCRJXUXPMJJP3E33LYSJSJXAVCNFSM6AAAAABC2M7O26VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMZQGQZTINBWGI . You are receiving this because you were mentioned.Message ID: @.***>

ihmpartners commented 7 months ago

there is no traffic/ping/pong during the 3 minutes from the browser side

On Tue, 6 Feb 2024 at 20:07, Ian Molesworth @.***> wrote:

I start my server which opens 3 sockets on 6060, 6061 and 6062.

I open a web page which connects to 6060 and 6062 ( 6061 not required on this page )

You can see the initial message on each channel when the connection is made.

Waiting for incoming connections... Waiting for incoming connections... Waiting for incoming connections... Handshaked, response:

HTTP/1.1 101 Switching Protocols Upgrade: websocket Connection: Upgrade Sec-WebSocket-Accept: hu+QnyZAy7en+BGzyuYrfdLqP8c=


Data Connection opened, addr: 127.0.0.1 Handshaked, response:

HTTP/1.1 101 Switching Protocols Upgrade: websocket Connection: Upgrade Sec-WebSocket-Accept: RiboZpwVd2Lr2jK4LcCw5F1Djxk=


Alerts Connection opened, addr: 127.0.0.1 Received a Data message: {"Subscribe": ["currentTxp","LimProfile","overRangeOP"]} (size: 56, type: 1), from: 127.0.0.1 Received an Alert message: {"Type": "Subscribe"} (size: 21, type: 1), from: 127.0.0.1 An error has occurred while trying to read next byte <<<< About 3 minutes Data Connection closed, addr: 127.0.0.1 Closing: normal close An error has occurred while trying to read next byte Alerts Connection closed, addr: 127.0.0.1 Closing: normal close

<<<

If I open my web page, both connections establish. If I then just sit and wait it takes < 5 minutes before closing

Regards Ian

On Tue, 6 Feb 2024 at 17:48, Ian Molesworth @.***> wrote:

The browser is chrome. The whole setup is running on a single machine. Ubuntu Linux 22.04 LTS. It is a development for an embedded device using web presentation. The sockets deliver realtime info about back end process data.

( On the actual platform the browser will be a QT webview instance. )

Disconnects are < 30 mins, sometimes just a few minutes.

I am not seeing errors from my server program.

Will pull and compile and let you know.

Ian

On Tue, 6 Feb 2024, 17:32 Davidson Francis, @.***> wrote:

Hi @ihmpartners https://github.com/ihmpartners, Normally this should not happen, since wsServer only closes the connection if it receives a CLOSE frame or if it receives an invalid frame.

A second option is if your browser is sending PING packets and wsServer is not responding to them, which is a bug and needs to be fixed. A third option is if your browser is silently losing connection with the wsServer, such as a weak WiFi signal, etc.

In any case, the dc75fda https://github.com/Theldus/wsServer/commit/dc75fda9a064bc0622e1e83c1ba29f974de58a55 commit adds a few more messages reporting the proper close reason, which may help us investigate this further. You can build wsServer in verbose mode with:

Makefile

$ CFLAGS="-DVERBOSE_MODE" make

or via CMake:

$ mkdir build && cd build/ $ CFLAGS="-DVERBOSE_MODE" cmake .. $ make

The verbose build should also report if it receives any type of malformed packet, etc.

The server socket closes after a time ( varies )

I know it varies, but can you give me an estimate? like under 30 minutes, more than 1 hour... I'll leave it running here and see if I can reproduce it too.

Is your client a browser? If so, which one? version, and etc too.

— Reply to this email directly, view it on GitHub https://github.com/Theldus/wsServer/issues/87#issuecomment-1930434462, or unsubscribe https://github.com/notifications/unsubscribe-auth/AARIWSRCRJXUXPMJJP3E33LYSJSJXAVCNFSM6AAAAABC2M7O26VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMZQGQZTINBWGI . You are receiving this because you were mentioned.Message ID: @.***>

ihmpartners commented 7 months ago

All connections are reported as address 127.0.0.1 even when connecting from a remote based browser

Theldus commented 7 months ago

Hi @ihmpartners,

Alerts Connection opened, addr: 127.0.0.1
Received a Data message: {"Subscribe":
["currentTxp","LimProfile","overRangeOP"]} (size: 56, type: 1), from:
127.0.0.1
Received an Alert message: {"Type": "Subscribe"} (size: 21, type: 1), from:
127.0.0.1
An error has occurred while trying to read next byte
                      <<<< About 3 minutes
Data Connection closed, addr: 127.0.0.1
Closing: normal close
An error has occurred while trying to read next byte
Alerts Connection closed, addr: 127.0.0.1
Closing: normal close

If I open my web page, both connections establish. If I then just sit and wait it takes < 5 minutes before closing

Interesting... what I feared is happening: a completely random disconnection without an apparent error. I tried to reproduce here, but the server maintained the connection for over two hours... with no apparent errors.

An error has occurred while trying to read next byte

This means that there was an abrupt disconnection, without a close handshake, etc.

I really have no idea what it could be... but maybe sending periodic pings is enough to keep the connection alive, something like this:

while (1) {
    ws_ping(NULL, 2);
    sleep(10);
}

in a separate thread. This way, a ping packet will be sent to the client every 10 seconds (with tolerance of 2 failed PONGs), which (hopefully) will keep the connection alive. There is an example file at: examples/ping/ping.c that you can run and see if the connection still closing after a few minutes.

If for some reason you get "Closing, reason: many unanswered PINGs" (in verbose mode), it means that your client is not responding to all PINGs and that there is a connection issue between both parties.