Message size limit (somewhere between 60kB and 70kB) about simple-websocket-server

[eidheim]

Thank you, but I'm unable to reproduce this problem in OS X and Linux using the following changes:

diff --git a/ws_examples.cpp b/ws_examples.cpp
index a4d1c75..e64fdb9 100644
--- a/ws_examples.cpp
+++ b/ws_examples.cpp
@@ -30,7 +30,9 @@ int main() {
         cout << "Server: Sending message \"" << message_str <<  "\" to " << (size_t)connection.get() << endl;

         auto send_stream=make_shared<WsServer::SendStream>();
-        *send_stream << message_str;
+        for(size_t c=0;c<70000;++c)
+            *send_stream << "h";
+        *send_stream << "\nend";
         //server.send is an asynchronous function
         server.send(connection, send_stream, [](const boost::system::error_code& ec){
             if(ec) {
@@ -126,7 +128,7 @@ int main() {
         auto message_str=message->string();

         cout << "Client: Message received: \"" << message_str << "\"" << endl;
-        
+        cout << "Client: Message received size: " << message_str.size() << endl;
         cout << "Client: Sending close connection" << endl;
         client.send_close(1000);
     };

Using a web browser did also work (Firefox and Chrome).

Have not tested or looked at your gist though, but take care of potential memory leaks as they can affect streams resulting in strange behaviour. Other than that, I suggest you try on Linux and see if the reported problem occurs there as well.

[BaZzz01010101]

Run into same issue. When trying to send message >=65536 bytes, server sent it without any issue but client in the browser closed with 1006 error. With messages <=65535 bytes, all working fine.

I have tried it in Opera 39.0.2256.71 and Chrome 53.0.2785.101 m (64-bit)
Server was built with Visual Studio 2015 (v14.0.25425.01 Update3) in Debug x86 mode
Was used boost_1_61_0 from here https://sourceforge.net/projects/boost/files/boost-binaries/
Was used OpenSSL_1_0_2-stable (SHA-1: 134ab5139a8d41455a81d9fcc31b3edb8a4b2f5c) from here git://git.openssl.org/openssl.git
Connection was made with this URL "wss://localhost:8899/ss_control"
OS is Windows 10 x64 with latest updates

[eidheim]

I think this is related: https://svn.boost.org/trac/boost/ticket/12383

[MatrixManAtYrService]

I made the changes in eidheim's comment, and can confirm that the problem starts at 65536 bytes. The output of ws_examples.cpp is below

65535 bytes	65536 bytes
for (size_t c = 0; c<65531; ++c)	for (size_t c = 0; c<65532; ++c)
Server: Opened connection 16629184 Client: Opened connection Client: Sending message: "Hello" Server: Message received: "Hello" from 16629184 Server: Sending message "Hello" to 16629184 Client: Message received size: 65535 Client: Sending close connection Server: Closed connection 16629184 with status code 1000 Client: Closed connection with status code 1000	Server: Opened connection 19643840 Client: Opened connection Client: Sending message: "Hello" Server: Message received: "Hello" from 19643840 Server: Sending message "Hello" to 19643840

I'll take a look at the boost issue and see if I can get my head around what's going on, but honestly I'm a bit pessimistic because I've never worked with asio directly before (only through eidheim's library--thanks by the way).

I'm at a point in my project where I need to decide whether to implement some kind of framing as a workaround (yuck) or try to contribute to fixing the source bug. If there's anything I can do to help with the latter, please let me know.

[BaZzz01010101]

Going to try other versions of boost library, but I'm a little limited by my VS2015 for now and can check only 1.59.0, 1.60.0 and 1.62.0_b1. I will update about results here.

[MatrixManAtYrService]

I can say that the problem exists in boost 1.60.0

[BaZzz01010101]

Same as in 1.59 and 1.62. I have checked both.

[MatrixManAtYrService]

The boost issue appears to have been created following this stackoverflow post:
http://stackoverflow.com/questions/38833771/boostasio-fails-to-read-more-than-65536-bytes-from-file

Several people in that thread believe the issue comes from the fact that OP is treating the argument to async_read like it's a stream, which it isn't. In the case of Simple-WebSocket-Server it looks like we're giving async_read an ip::tcp::socket, which seems as stream-like as anything to me.

I don't doubt that we're up against the same sort of thing, but if the stakoverflow folks are to be believed, the issue won't be resolved by a code change to boost, it will be resolved by a documentation change. If these are indeed the same issue, then it may be up to us to learn to use boost differently rather than up to boost to isolate and fix the problem.

[BaZzz01010101]

I already found the issue, going to create pull request soon.

[BaZzz01010101]

Ok, this is my first pull request, so I'm sorry if I did something wrong.
fixed bug with closing connection on client, when messages larger than 65535 bytes

[eidheim]

This issue should be fixed in PR #43. Closing this issue as the PR is merged.