Hi Scott, Scott <cheesy4poofs@cox.net> wrote:
I took the existing SSL client.cpp code and added a thread to it. I removed the code to prompt the user for a string to send to the server and instead it will randomly pick one of 3 messages to constantly send them.
In the 2nd thread, it basically does the same thing, but sends 1 of 3 different messages. Both threads are using the same socket. The first thread is using async IO to read and write the messages. The 2nd thread only sends synchronous messages at random intervals (the first thread picks up the responses from the 2nd thread's asio::write).
OK, this is almost certainly not going to work :) The thread safety of an ssl::stream is specified such that - distinct ssl::stream objects can be safely used from different threads (although this wasn't the case until 0.3.7) - a single ssl::stream object cannot be used from multiple threads unless protected by some form of synchronisation By synchronisation, I mean something like: - locking a mutex (although this would not be preferred in an asynchronous design) - post()ing a function object into the io_service object associated with the stream, if there is only one thread calling io_service::run(). - post()ing or dispatch()ing a function object into a strand, if you have multiple threads calling io_service::run() Is the change you made to the example representative of how the ssl::stream is used in your application? If so, try adding some form of synchronisation and see what happens. I'd also say that this doesn't sound like the issue that Viktor described, where increasing the size of the buffer made the problem go away. Cheers, Chris