Что делать после отказа обработчика?

Question

Когда обработчик операции чтения возвращает ошибку, означает, что соединение сломано/сбой/вниз? Есть ли смысл начинать новую асинхронную операцию?

Я имею в виду, что казуистика может быть очень сложной в зависимости от различных возможных ошибок.

void ReadHandler(const boost::system::error_code& error, size_t bytes_transferred) 
{ 
    if(!error) 
    { 
     // OK 
    } 
    else 
    { 
     // does it make any sense to continue and start another async operation ? 
     // or I have to check the error with error.value() and possibly close 
     // the session or stop reading...etc ? 
    } 

Как узнать, может ли соединение использоваться? Когда ошибка чтения возникает с уровнем TCP ниже, потому что что-то пошло не так в связи?

Answer 1

Возможно, есть некоторая ценность в понимании того, что такое сама ошибка. Но, с другой стороны, если у вас нет исчерпывающего списка «какие ошибки в порядке, чтобы продолжить, а какие не все в порядке», вы в конечном итоге все равно получите подход «наилучшего предположения».

Почти наверняка некоторые ошибки будут восстановлены - временно не имея достаточного количества буферов для приема пакета или некоторых таких. Другие ошибки постоянны (кто-то отключил питание от сетевого коммутатора ...).

Один из способов решения проблемы состоит в том, чтобы иметь счетчик количества ошибок в строке, которую вы получаете, - если вы продолжаете и не получаете другую ошибку, тогда штраф ... Если вы получите три (или пять или десять или 100) ошибки в строке, вы выходите, так как вещи, вероятно, не улучшаются.

Другой подход - разрешить так много ошибок за определенное время (например, более 5 ошибок за 10 секунд или более 50 ошибок через минуту или что-то еще имеет смысл для вашей заявки).

Третий подход заключается в том, чтобы спросить пользователя - это действительно зависит от уровня пользователя, что он/она будет делать с сообщением типа «Получил ошибку X, вы хотите продолжить? (Да) | (Нет) "тип вопрос.

Большая часть вопроса, конечно же, «что делает ваше приложение, и что является следствием« получения неправильного »в отношении обработки ошибок?» - мы не можем ответить на этот вопрос, не понимая больше вашего проекта - и действительно, это, вероятно, немного выходит за рамки этих рекомендаций для веб-сайтов.

Answer 2

Это действительно зависит от приложения и даже операции async, что вы делаете, когда обработчик вызывается с ненулевой ошибкой. В большинстве приложений я обычно обрабатываю boost::asio::error::operation_aborted иначе, чем другие ошибки, потому что это означает, что программа выключается. В зависимости от протокола вы также можете интерпретировать boost::asio::error::eof по-разному. Это может быть полностью уместно, чтобы розетка была закрыта без предварительного уведомления.