История изменений
Исправление firkax, (текущая версия) :
Ну что такое, ты опять надёргал каких-то отрывков и отвечаешь на них полностью забыв о контексте и местами переврав вопросы. Неужели так сложно принять простой вопрос?
Без шатдауна этот сценарий не обычный,
Никто не говорит про «без шатдауна».
но если одна из сторон сделала close() на свой конец, то другая будет получать ошибку на любую операцию с ssl-хэндлом, включая SSL_shutdown().
Какую операцию то? SSL_shutdown мы вызывать не хотим т.к. возможно ещё что-то отправим (иначе бы и проблемы не возникло), SSL_write - пока слать нечего, а SSL_read и так выдаёт ошибку без close.
Ещё раз повторю суть беседы, постарайся её принять целиком не вытаскивая из неё отдельные утверждения:
1) есть два пира A и B, они успешно настроили SSL сессию (SSL_connect/SSL_accept) и как-то её пользуются
2) в какой-то момент пир A вызывает SSL_shutdown, после чего пир B получает SSL_ERROR_ZERO_RETURN, но на данный момент у пира B нет уверенности в том, что он больше ничего не хочет слать пиру A, впрочем данных для отправки прямо сейчас у него тоже нет
Дальнейшее развитие событий может произойти тремя способами:
3а) пир A после этого вызывает ещё close()
3б) пир A после этого начинает цикл SSL_read()
3в) пир A после этого начинает цикл SSL_read(), но в какой-то момент всё-таки делает close()
Вопрос такой: как пиру B узнать про close(), сделанный пиром A до того, как у пира B появятся данные для отправки? Портить состояние SSL-сессии (читать данные из сокета в обход openssl) при этом нельзя.
Исправление firkax, :
Ну что такое, ты опять надёргал каких-то отрывков и отвечаешь на них полностью забыв о контексте и местами переврав вопросы. Неужели так сложно принять простой вопрос?
Без шатдауна этот сценарий не обычный,
Никто не говорит про «без шатдауна».
но если одна из сторон сделала close() на свой конец, то другая будет получать ошибку на любую операцию с ssl-хэндлом, включая SSL_shutdown().
Какую операцию то? SSL_shutdown мы вызывать не хотим т.к. возможно ещё что-то отправим, SSL_write - пока слать нечего, а SSL_read и так выдаёт ошибку без close.
Ещё раз повторю суть беседы, постарайся её принять целиком не вытаскивая из неё отдельные утверждения:
1) есть два пира A и B, они успешно настроили SSL сессию (SSL_connect/SSL_accept) и как-то её пользуются
2) в какой-то момент пир A вызывает SSL_shutdown, после чего пир B получает SSL_ERROR_ZERO_RETURN, но на данный момент у пира B нет уверенности в том, что он больше ничего не хочет слать пиру A, впрочем данных для отправки прямо сейчас у него тоже нет
Дальнейшее развитие событий может произойти тремя способами:
3а) пир A после этого вызывает ещё close()
3б) пир A после этого начинает цикл SSL_read()
3в) пир A после этого начинает цикл SSL_read(), но в какой-то момент всё-таки делает close()
Вопрос такой: как пиру B узнать про close(), сделанный пиром A до того, как у пира B появятся данные для отправки? Портить состояние SSL-сессии (читать данные из сокета в обход openssl) при этом нельзя.
Исправление firkax, :
Ну что такое, ты опять надёргал каких-то отрывков и отвечаешь на них полностью забыв о контексте и местами переврав вопросы. Неужели так сложно принять простой вопрос?
Без шатдауна этот сценарий не обычный,
Никто не говорит про «без шатдауна».
но если одна из сторон сделала close() на свой конец, то другая будет получать ошибку на любую операцию с ssl-хэндлом, включая SSL_shutdown().
Какую операцию то? SSL_shutdown мы вызывать не хотим, SSL_write - пока слать нечего, а SSL_read и так выдаёт ошибку без close.
Ещё раз повторю суть беседы, постарайся её принять целиком не вытаскивая из неё отдельные утверждения:
1) есть два пира A и B, они успешно настроили SSL сессию (SSL_connect/SSL_accept) и как-то её пользуются
2) в какой-то момент пир A вызывает SSL_shutdown, после чего пир B получает SSL_ERROR_ZERO_RETURN, но на данный момент у пира B нет уверенности в том, что он больше ничего не хочет слать пиру A, впрочем данных для отправки прямо сейчас у него тоже нет
Дальнейшее развитие событий может произойти тремя способами:
3а) пир A после этого вызывает ещё close()
3б) пир A после этого начинает цикл SSL_read()
3в) пир A после этого начинает цикл SSL_read(), но в какой-то момент всё-таки делает close()
Вопрос такой: как пиру B узнать про close(), сделанный пиром A до того, как у пира B появятся данные для отправки? Портить состояние SSL-сессии (читать данные из сокета в обход openssl) при этом нельзя.
Исходная версия firkax, :
Ну что такое, ты опять надёргал каких-то отрывков и отвечаешь на них полностью забыв о контексте и местами переврав вопросы. Неужели так сложно принять простой вопрос?
Без шатдауна этот сценарий не обычный, но если одна из сторон сделала close() на свой конец, то другая будет получать ошибку на любую операцию с ssl-хэндлом, включая SSL_shutdown().
Ещё раз повторю суть беседы, постарайся её принять целиком не вытаскивая из неё отдельные утверждения:
1) есть два пира A и B, они успешно настроили SSL сессию (SSL_connect/SSL_accept) и как-то её пользуются
2) в какой-то момент пир A вызывает SSL_shutdown, после чего пир B получает SSL_ERROR_ZERO_RETURN, но на данный момент у пира B нет уверенности в том, что он больше ничего не хочет слать пиру A, впрочем данных для отправки прямо сейчас у него тоже нет
Дальнейшее развитие событий может произойти тремя способами:
3а) пир A после этого вызывает ещё close()
3б) пир A после этого начинает цикл SSL_read()
3в) пир A после этого начинает цикл SSL_read(), но в какой-то момент всё-таки делает close()
Вопрос такой: как пиру B узнать про close(), сделанный пиром A до того, как у пира B появятся данные для отправки? Портить состояние SSL-сессии (читать данные из сокета в обход openssl) при этом нельзя.