skaarj1989 / mWebSockets

WebSockets for microcontrollers
https://skaarj1989.github.io/mWebSockets/autobahn-testsuite/servers/
MIT License
106 stars 22 forks source link

Unreliable connection setup #47

Closed fkromer closed 3 years ago

fkromer commented 3 years ago

Describe the bug

If I try to connect from a client to a websocket server implemented with mWebSockets the connection is not always setup.

Environment info

Expected behavior

The connection setup is executed properly every time I try to connect.

Failure log

No failure log output in case of connection is not setup (#define _DEBUG, #define _DUMP_HANDSHAKE, #define _DUMP_HEADER and #define _DUMP_FRAME_DATA are all set).

Log in case connection is setup:

[Line #0] GET / HTTP/1.1
[Line #1] Host: 192.168.1.2
[Line #2] User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:90.0) Gecko/20100101 Firefox/90.0
[Line #3] Accept: */*
[Line #4] Accept-Language: de,en-US;q=0.7,en;q=0.3
[Line #5] Accept-Encoding: gzip, deflate
[Line #6] Sec-WebSocket-Version: 13
[Line #7] Origin: moz-extension://d4825527-04cb-4cc5-9a5a-cca3f570223a
[Line #8] Sec-WebSocket-Extensions: permessage-deflate
[Line #9] Sec-WebSocket-Key: On6QMBBNL3JfSru3nICLsg==
[Line #10] Connection: keep-alive, Upgrade
[Line #11] Pragma: no-cache
[Line #12] Cache-Control: no-cache
[Line #13] Upgrade: websocket
[Line #14]

Additional context

Firecamp log output in case connection is not setup:

grafik

Firecamp log output in case connection is setup:

grafik

skaarj1989 commented 3 years ago

Hi @fkromer Thanks for using the issue template ;) How often does this problem occur? And how many seconds passes between connecting and error?

Anyways, this means that your client didn't even make it to _handleRequest which suggests that Arduino did'nt notice a client at all.

fkromer commented 3 years ago

Hey @skaarj1989, you are welcome 😉 The error is displayed "immediatelly" (within a fraction of a second). Right, that's the strange thing...

stale[bot] commented 3 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

fkromer commented 3 years ago

@skaarj1989 The behavior is reproducible with Postman beta websocket support.

skaarj1989 commented 3 years ago

@fkromer Have you tried to add some delay before open()? like 1-2 sec? Last month I replaced my router which introduced some issues with the connection and that 1sec delay resolved it.

About your Ethernet shield, is it "official" or a clone?

fkromer commented 3 years ago

I'm waiting more than 5 seconds after power on before I try to connect to my server with a client. ATM I'm not using a router/switch but connect directly via crossover cable. The behaviour when connecting via a router is not different. It's an official Ethernet shiled v2.

fkromer commented 3 years ago

@skaarj1989 It seems like one cannot use port 80 with websockets and a restful api server at the same time 😄 Can I workaround this somehow? I'd like to avoid not using port 80 cause it's the default port for HTTP. (I'm using Ethernet + aWot for the RESTful API server implementation.)

skaarj1989 commented 3 years ago

Is it really a big deal for you to share a REST server with websocket one? If I were you, I would use two different ports like: 80 and 8080

fkromer commented 3 years ago

@skaarj1989 I've forgotten about the limitations on these tiny embedded devices where there is of course no proxy which could port forward port 80 to port 8080 (or wathever other port the websocket server is running on) to make it seem like both, RESTful API and WebSockets are accessible via port 80.

In usual server scenarios it's possible for HTTP and WebSockets to share port 80 as soon as the handshake has been executed. However it seems like the handshaking on tiny devices is a bottleneck...