How To keep and recover websocket connections

[Pako]

Dear Walter,
here is a modified version of the Tornado plugin.
Can you please try it?
In this case, similar errors ('WebSocket Protocol Error' and 'Masked frame from server') not occur?

Best regards,
Luboš

[krambriw]

Dear Pako, thank you
I will put in test very soon and both will run over night. So far the Webserver test is working fine.

In this case, similar errors ('WebSocket Protocol Error' and 'Masked frame from server') not occur?

Correct, I have only seen this with the Tornado plugin (in javascript console):

Code: Select all

From javascript console: Invalid frame header
From javascript console: One or more reserved bits are on: reserved1 = 0, reserved2 = 1, reserved3 = 0

I did not add any decoding/printout in the Tornado plugin for this, I did not know how to catch it


Best regards, Walter

[krambriw]

Dear Pako,

The test has worked fine during the night, I just would like to do some more tests during the day

Best regards, Walter

[krambriw]

Dear Pako,

During the day I have now performed what we maybe can call a "small stress test". I did connect several websocket clients to the websocket server (I think something like
- 5 clients i the same PC using Firefox
- 1 client using Chrome
- 2 tablets, android, each using Firefox

Result with Webserver:

1) Whatever I try, I get a lot of disconnects all the time when I start to use a more javascript heavy page. My browsers did reconnect but after not very long, disconnections came again and it started all over again and again

2) I have a feeling that a simpler html page will 'survive' longer, i.e the connection will live longer than if you have rather complex javascript code in the page (like I have)

3) I also had two crashes in the Webserver plugin and I just roughly changed the code in two places to be able to continue

At line 3764
Reason for the change was that I received an exception when deletion was tried on a client that was already deleted

Code: Select all

    def BroadcastMessage(self, message):
        tmp = list(self.wsClients.iteritems())
        for key, client in tmp:
            try:
                client.write_message(message)
            except Exception, exc:
                if exc.args[0] in (10053, 10054, 10060):
                    try:
                        del self.wsClients[client]
                        del self.wsClientsTime[client]
                        eg.PrintNotice(self.text.forcDel % repr(client))
                        self.TriggerEvent(
                            self.text.wsClientDisconn,
                            payload = [client]
                        )
                    except:
                        pass
                else:
                    eg.PrintTraceback() # debugging ...

At line 3764
Reason for the change was that it can happen that the client connection is already gone and if so the write_message will raise an exception

Code: Select all

    def write_message(self, message):
        try:
            self.request.send(chr(129))
            length = len(message)
            if length <= 125:
                self.request.send(chr(length))
            elif length >= 126 and length <= 65535:
                self.request.send(chr(126))
                self.request.send(pack(">H", length))
            else:
                self.request.send(chr(127))
                self.request.send(pack(">Q", length))
            self.request.send(message)
        except:
            pass

4) In my environment, with the web page I need, I could not find any solution to make it work without causing so many disconnects. I have no further ideas what could be improved/modified.


Result with Tornado:

1) The number of disconnects are very rare even if they do also happens

2) No further changes needed as I see it, the Tornado plugin is working fine

3) I have to use Tornado in my environment due to the fewer disconnects it creates


My best regards,
Walter

[Pako]

Dear Walter!
Thank you for the tests and their detailed evaluation.
Described problems are probably not caused by new arrangements,
so nothing prevents use this version to the new EventGhost release.
Of course, I think including your recent changes.
Maybe someday we'll find the cause of this behavior and it will be possible to do better.

Best regards,
Luboš