I have a websocket server that simply stores the connected client, and appends any text received to a text edit control.
I created a manual test to put some load on my server, in order to see how it would behave, and try to get a send call to return anything aside from the number of bytes I gave it. My mission was to get a better understanding of how send handles errors.
My test would
- load a 1 mb text file
- connect to my server
- when signaled that it was connected, post a function that calls send with the contents of the text file, using QMetaObject::invokeMethod
In the function where the send occurred, I'd post again, if my number of iterations was less than 10,000.
So, in effect, I slammed my server with 10,000 sends of 1MB of text.
It does not surprise me that the server stopped responding. It would not error out or crash, but just hang in the text edit's layoutBlock forever.
Note that is not the bug I am reporting. I am just describing setup.
What I am concerned about, is that if I would attempt to run my test a second time, any call to QWebsocket::open would never resolve. I did not get a connection refused. I did not get signaled that I was connected. If I paused my program in the debugger, it was just sitting in the event loop forever, I assume waiting for some internal event.
The state of the server should have no effect on the entirely separate client process. I'd expect the client to either report an error or connect.
The API does not have a means to specify a timeout.
The end result is that I can potentially have clients in production that give the appearance of a hung process, because they never error out, but never connect either.