vinniefalco
commented
7 years ago https://github.com/vinniefalco/Beast/compare/sgc...larsonmpdx:sgc?expand=1
This link doesn't work for me (its local to your GitHub login session), you need to use something like this https://github.com/larsonmpdx/Beast/commits/sgc
the template complains:
When I say 'remove the multi buffer' I mean remove it from the call site but also remove the DynamicBuffer template parameter from the class template and everywhere its used in the implementation!
do I need to change the read_some_op() stuff or delete it?
You will need a write_some_op so you can take the read_some_op and rename it and empty out the implementation of operator(), remove whatever you need to in order to make it compile.
Probably put your name at the top, Copyright 2017 and your email if you want, or your GitHub profile link (or nothing)
The include guard is named BEAST_EXAMPLE_COMMON/FLAT_WRITE_STREAM_HPP
Don't include multi_buffer.hpp
Most everything in there is indented one unnecessary level to the right
You don't need the buffer or capacity member functions
The read functions look okay.
The write functions you will need to define outside the class since they will be many lines (and we don't want them to be implicitly marked inline).
Add the signature for the function I gave you find_single and implement it. Now we will edit the synchronous write function to have this logic:
-
If
buffer_size(buffers)>0callfind_singleon theConstBufferSequence -
If
buffer_size(buffers) == 0orfind_singlereturned an iterator just callnext_layer_.writewith a value ofbuffersorboost::asio::const_buffers_1{*iter}(the iterator you found) and return the result. This is the efficient/transparent path. -
Otherwise, if
buffer_size(buffers) <= max_stack_sizewheremax_stack_sizeis a private class constant set to something like, idk. 4KB, call a private function which declares a stack variablechar buf[max_stack_size]and usesboost::asio::buffer_copyto flatten the input into the variable. Then callnext_layer_.write()on that variable and return the result. -
If none of the above then use
std::unique_ptr<char[]> buf{new char[buffer_size(buffers)]}to get a temporary piece of memory andboost::asio::buffer_copyon the input into this temporary memory. Then callnext_layer_.write()on that temp memory and return the result. You will want to wrap the call tonewin atry/catchand convert the exception into anerror_code.
Once you have this compiling and working, you should be able to connect to the sgc server with no trouble. Publish the work, and I will help you write the asynchronous version which lives in the write_some_op. It uses the same logic as the synchronous but we have to allocate the memory using the allocation hook and also manage the final completion handler. And of course there is the "inversion of control" that comes with callback style programming.
We can add a test for the both the synchronous and asynchronous versions which uses the test::pipe class which simulates a socket. And then this will be part of Beast! How exciting!
larsonmpdx
beast version 67
note I have replaced the host with [host] throughout, I can privately share the real host to help testing
I'm using this curl command to handshake with a server based on a pascal websocket server (http://www.esegece.com/websockets/)
I am trying to do the same handshake with beast, even copying the curl headers:
the server accepts the curl connection but rejects the beast connection. the server's logs show that the headers are received with extra newlines or something like newlines in the case of beast:
server logs for curl connection:
server logs for beast:
I also tested beast using mitmproxy (https://mitmproxy.org/) instead of connecting to the server directly, and it works correctly in this case, as I assume mitmproxy is putting the headers together. I assume my problem has to do with the extra newlines in the beast output. This may be standards-compliant (I don't know), but it's making my server unhappy. Is there a way to change this?