Существует пример сервер и клиент SSL на boost.org. Я изменил клиент так, чтобы он сначала вызывал async_read, а затем отправлял запрос с async_write. Сначала сервер находится в режиме прослушивания (async_read), поэтому он получит запрос и отправит его клиенту, но я не получаю результат в клиенте.
Я действительно сбит с толку как async_read и async_write вызываются за сценой. Например, если сначала вызывается async_read, ожидает ли он получения данных или он будет отменен после вызова async_write (поскольку данные не получены)? Если это не так, зачем мне второй или третий async_read, чтобы получить ответ от первого async_write с сервера (как вы видели в результатах ниже)?
Пожалуйста, см. изменения в исходном файл , который делает клиент доступным для чтения.
Это результат, когда клиент подключен и отправляет данные на сервер:
Verifying /C=AU/ST=Some-State/O=Internet Widgits Pty Ltd
Enter message: 1234567890
Enter message: aaaaaaaaaa
Enter message: bbbbbbbbbb
Reply: 1234567890
Enter message: cccccccccc
Reply: aaaaaaaaaa
Enter message: dddddddddd
Reply: bbbbbbbbbb
Enter message:
Редактировать: Я проверил больше ситуаций и получил новые результаты. Я изменил код, чтобы в функции завершения async_write метод send_request() больше не запускался (поэтому мы не будем получать новые данные от пользователя для отправки). Пожалуйста, смотрите изменения в этом патче . Результаты выглядят следующим образом:
1 Verifying /C=AU/ST=Some-State/O=Internet Widgits Pty Ltd
2 Enter message: 1234567890
3 Reply: 1234567890
4 Read failed: stream truncated <--- Server closed at this point
В строке 4 происходит ожидание чтения, и, как вы можете видеть, async_read лямбда вызвала и отобразила результат ошибки (поскольку сервер был закрыт вручную). До сих пор я понял, что второй async_write (тот, который вызывается в результате вызванной лямбды) делает первый async_read снятым (или что-то подобное).