Error connecting to CertStream - Connection is already closed
See original GitHub issueI implemented this tool, following the given examples. I found out that sometimes ( usally every 2 minutes, more or less) the connection drops and it takes almost a minute to reconnect to the stream.
I don’t know why this happens and this could probably lead to missing some hits i’m looking for.
Here’s an example of log ( integrated with python logging module )
[ERROR:certstream] 2020-09-02 16:20:31,002 - Error connecting to CertStream - Connection is already closed. - Sleeping for a few seconds and trying again...
[INFO:certstream] 2020-09-02 16:20:36,097 - Connection established to CertStream! Listening for events...
[...]
[ERROR:certstream] 2020-09-02 16:23:10,796 - Error connecting to CertStream - Connection is already closed. - Sleeping for a few seconds and trying again...
[INFO:certstream] 2020-09-02 16:23:15,908 - Connection established to CertStream! Listening for events...
[...]
[ERROR:certstream] 2020-09-02 16:25:11,015 - Error connecting to CertStream - Connection is already closed. - Sleeping for a few seconds and trying again...
[INFO:certstream] 2020-09-02 16:25:16,182 - Connection established to CertStream! Listening for events...
[...]
[ERROR:certstream] 2020-09-02 16:27:17,051 - Error connecting to CertStream - Connection is already closed. - Sleeping for a few seconds and trying again...
[INFO:certstream] 2020-09-02 16:27:22,194 - Connection established to CertStream! Listening for events...
[...]
[ERROR:certstream] 2020-09-02 16:29:01,343 - Error connecting to CertStream - Connection is already closed. - Sleeping for a few seconds and trying again...
[INFO:certstream] 2020-09-02 16:29:06,522 - Connection established to CertStream! Listening for events...
Any suggestion about how to fix this?
Issue Analytics
- State:
- Created 3 years ago
- Reactions:7
- Comments:29 (3 by maintainers)
Top Results From Across the Web
"Connection is already closed." error with python WebSocket ...
Most likely, the remote host closed the connection. You cannot stop it. You can handle it by re-connecting. People running web servers will ......
Read more >Error connecting to CertStream - Bountysource
Error connecting to CertStream - Connection is already closed.
Read more >Release 1.4.2 liris - websocket-client's documentation
How to solve the “connection is already closed” error? ... If you want to connect to a websocket without writing any code yourself, ......
Read more >Certstream
CertStream is hosted on Github and we currently have libraries for Python, Javascript, Go, and Java. These libraries are intended to lower the...
Read more >certstream - PyPI
Certstream is a library to connect to the certstream network (certstream.calidog.io). It supports automatic reconnection when networks issues occur, ...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Argh, well this is disappointing. 😦 I am hitting this problem too and can only reach the same conclusion as @kres20 that the
certstream.calidog.io
service is just basically unusable.I noticed
certstream.calidog.io
is actually Cloudflare. In Wireshark packet capture on my client, I can see the Cloudflare frontend server is just suddenly closing the TCP connection for some reason. No shutting down of the Websocket session or the TLS session, but a (mostly) normal 4-way close handshake of the outer TCP connection. (Abnormally, the Cloudflare server waits for exactly 10 seconds before sending its very lastACK
, despite my client dutifully attempting several retransmissions of its lastFIN
that the server is waiting for.)When I add
sslopt={'suppress_ragged_eofs': False}
to thecertstream.listen_for_events
parameters, the issue causes an exception that matches what I saw in packet capture:ssl.SSLEOFError: EOF occurred in violation of protocol (_ssl.c:2633)
.When I use my preferred public DNS resolver (149.112.121.10),
certstream.calidog.io
resolves to172.64.80.1
for me. This is a Cloudflare IP. Traceroute from my client and from a couple other places suggests that it’s an anycast IP that exists at/near multiple different Internet exchanges.When I use other public DNS resolvers,
certstream.calidog.io
resolves to different Cloudflare IPs for me -172.67.151.243
and104.21.40.132
. When I force my client to connect to these IPs, the problem still happens, but anecdotally seems to occur far less frequently than with172.64.80.1
.I’m skeptical that IP anycast is a suitable CDN strategy for services requiring permanent TCP connections, such as the Calidog Certstream service. IMO this problem is likely a completely normal side-effect of the chosen CDN strategy that the Calidog service is using. 😦
@katesaikishore @Fitblip I set up the certstream server too (https://github.com/CaliDog/certstream-server), and connect there like
certstream.listen_for_events(print_callback, url='ws://localhost:4000/')
, and it works fine without any errors. Therefore this above error is caused by certstream.calidog.io.