link0 link1 link2 link3 link4 link5 link6 link7 link8 link9 link10 link11 link12 link13 link14 link15 link16 link17 link18 link19 link20 link21 link22 link23 link24 link25 link26 link27 link28 link29 link30 link31 link32 link33 link34 link35 link36 link37 link38 link39 link40 link41 link42 link43 link44 link45 link46 link47 link48 link49 link50 link51 link52 link53 link54 link55 link56 link57 link58 link59 link60 link61 link62 link63 link64 link65 link66 link67 link68 link69 link70 link71 link72 link73 link74 link75 link76 link77 link78 link79 link80 link81 link82 link83 link84 link85 link86 link87 link88 link89 link90 link91 link92 link93 link94 link95 link96 link97 link98 link99 link100 link101 link102 link103 link104 link105 link106 link107 link108 link109 link110 link111 link112 link113 link114 link115 link116 link117 link118 link119 link120 link121 link122 link123 link124 link125 link126 link127 link128 link129 link130 link131 link132 link133 link134 link135 link136 link137 link138 link139

PersCom — Компьютерная Энциклопедия Компьютерная Энциклопедия

Шина IEEE 1394 — FireWire

Обработка ошибок передачи

Для обеспечения надежных транзакций достоверность передачи заголовков и полей данных пакетов контролируются CRC-кодами. Пакеты запросов и ответов, принятые с обнаруженной ошибкой в заголовке, игнорируются (достоверной информации об их источнике и адресате назначения нет). Об остальных ошибках узел, которому адресован пакет запроса или ответа, сообщает его источнику указанием соответствующего кода в пакете квитирования. Пакеты-квитанции контролируются проще (по двоичному дополнению кода ответа), неверные квитанции игнорируются. Обработкой ошибок занимается прикладной драйвер, которому уровень транзакций сообщает результат выполнения. Канальный уровень принятые пакеты только проверяет на корректность формата и CRC; он передает уровню транзакций все пакеты, адресованные данному узлу, но с соответствующими признаками корректности или ошибки.

Типовая асинхронная транзакция состоит из двух субакций (запроса и ответа), каждая из которых выполняется с квитированием. Таким образом, транзакция состоит из четырех пакетов, каждый из которых при передаче может оказаться поврежденным. Рассмотрим поэтапно возможные ошибки передачи в типовой транзакции.

Пакет запроса пришел к адресованному узлу с ошибкой CRC данных:

  • действия узла-ответчика: канальный уровень передает его уровню транзакций поврежденный пакет с признаком ошибки. Уровень транзакций отбрасывает пакет и через канальный уровень посылает квитанцию с кодом ошибки. Прикладной драйвер никаких уведомлений не получает;
  • действия узла-запросчика: канальный уровень принимает эту квитанцию и передает ее код уровню транзакций, который информирует прикладной драйвер о неудаче. Какая на это последует реакция — зависит от приложения, которое знает, что до ответчика запрос не дошел.

Пакет запроса пришел нормально, но пакет квитирования «потерялся» (канальный уровень запросчика не дождался корректной квитанции):

  • действия узла-запросчика: канальный уровень посылает об этом уведомление своему уровню транзакций, который сообщит прикладному драйверу об отсутствии квитанции. Реакция опять же зависит от приложения, но состояние ответчика (пришел к нему запрос или нет) ему неизвестно.

Пакет ответа пришел к запросчику с ошибкой CRC данных:

  • действия узла-запросчика: канальный уровень передает пакет уровню транзакций поврежденный пакет с признаком ошибки. Уровень транзакций отбрасывает пакет и через канальный уровень посылает квитанцию с кодом ошибки. Прикладному драйверу об этом не сообщается, для него данный запрос остается в состоянии ожидания ответа (пока позволяет тайм-аут ожидания ответа);
  • действия узла-ответчика: канальный уровень принимает эту квитанцию и передает ее код уровню транзакций, который информирует прикладной драйвер об ошибке передачи ответа. Прикладной драйвер может повторить ответ — запросчик, возможно, его еще ждет.

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

Пакет ответа пришел нормально, но пакет квитированиия «потерялся». Об этом уведомляется драйвер ответчика, который обрабатывает эту ситуацию в зависимости от приложения. Дошел ли при этом ответ до запросчика — неизвестно.