История изменений
Исправление firkax, (текущая версия) :
Когда удалённая сторона закроет сокет со свой стороны, SSL_read() / SSL_get_error() вернёт тебе другую ошибку (SSL_ERROR_SYSCALL).
Это так, только если удалённая сторона SSL_shutdown перед этим не сделала.
В зависимости от её действий (слева) получаются такие результаты SSL_read на другой стороне (справа):
1) ничего не делать - WANT_READ
2) close - SSL_shutdown - SYSCALL, errno=ECONNRESET
4) shutdown(SHUT_WR)+close - SYSCALL, errno=0
5) SSL_shutdown - ZERO_RETURN
6) SSL_shutdown+close - ZERO_RETURN
7) SSL_shutdown+shutdown(SHUT_WR)+close - ZERO_RETURN
То есть, как я и ожидал, если SSL_read принял с той стороны шатдаун то дальше он работать полностью перестаёт и на изменение состояния сокета не реагирует. Единственное, чего я не проверил - что будет если ему в этот сокет прислать служебные пакеты, но я не знаю как это организовать.
Если после этого SSL_read ZERO_RETURN сделать SSL_write - то уже разное поведение: с незакрытым сокетом (вариант 5) он выполняется успешно, с закрытым (варианты 6 и 7) - тоже возвращает ZERO_RETURN. Но, повторюсь, чтобы вызывать SSL_write, надо иметь данные для отправки, а они есть не всегда.
Исправление firkax, :
Когда удалённая сторона закроет сокет со свой стороны, SSL_read() / SSL_get_error() вернёт тебе другую ошибку (SSL_ERROR_SYSCALL).
Это так, только если удалённая сторона SSL_shutdown перед этим не сделала.
В зависимости от её действий (слева) получаются такие результаты SSL_read на другой стороне (справа):
1) ничего не делать - WANT_READ
2) close - SSL_shutdown - SYSCALL, errno=ECONNRESET
4) shutdown(SHUT_WR)+close - SYSCALL, errno=0
5) SSL_shutdown - ZERO_RETURN
6) SSL_shutdown+close - ZERO_RETURN
7) SSL_shutdown+shutdown(SHUT_WR)+close - ZERO_RETURN
То есть, как я и ожидал, если SSL_read принял с той стороны шатдаун то дальше он работать полностью перестаёт и на изменение состояния сокета не реагирует. Единственное, чего я не проверил - что будет если ему в этот сокет прислать служебные пакеты, но я не знаю как это организовать.
Если после этого SSL_read ZERO_RETURN сделать SSL_write - то уже разное поведение: с незакрытым сокетом он выполняется успешно, с закрытым - тоже возвращает ZERO_RETURN. Но, повторюсь, чтобы вызывать SSL_write, надо иметь данные для отправки, а они есть не всегда.
Исходная версия firkax, :
Когда удалённая сторона закроет сокет со свой стороны, SSL_read() / SSL_get_error() вернёт тебе другую ошибку (SSL_ERROR_SYSCALL).
Это так, только если удалённая сторона SSL_shutdown перед этим не сделала.
В зависимости от её действий (слева) получаются такие результаты SSL_read на другой стороне (справа):
1) ничего не делать - WANT_READ
2) close - SSL_shutdown - SYSCALL, errno=ECONNRESET
4) shutdown(SHUT_WR)+close - SYSCALL, errno=0
5) SSL_shutdown - ZERO_RETURN
6) SSL_shutdown+close - ZERO_RETURN
7) SSL_shutdown+shutdown(SHUT_WR)+close - ZERO_RETURN
То есть, как я и ожидал, если SSL_read принял с той стороны шатдаун то дальше он работать полностью перестаёт и на изменение состояния сокета не реагирует. Единственное, чего я не проверил - что будет если ему в этот сокет прислать служебные пакеты, но я не знаю как это организовать.