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

[ihmpartners]

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]

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]

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 <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. — Reply to this email directly, view it on GitHub <#87 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AARIWSRCRJXUXPMJJP3E33LYSJSJXAVCNFSM6AAAAABC2M7O26VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMZQGQZTINBWGI> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[ihmpartners]

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 > <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. > > — > Reply to this email directly, view it on GitHub > <#87 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AARIWSRCRJXUXPMJJP3E33LYSJSJXAVCNFSM6AAAAABC2M7O26VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMZQGQZTINBWGI> > . > You are receiving this because you were mentioned.Message ID: > ***@***.***> >

[ihmpartners]

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 >> <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. >> >> — >> Reply to this email directly, view it on GitHub >> <#87 (comment)>, >> or unsubscribe >> <https://github.com/notifications/unsubscribe-auth/AARIWSRCRJXUXPMJJP3E33LYSJSJXAVCNFSM6AAAAABC2M7O26VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMZQGQZTINBWGI> >> . >> You are receiving this because you were mentioned.Message ID: >> ***@***.***> >> >

[ihmpartners]

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

[Theldus]

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.