информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Все любят медГде водятся OGRыАтака на Internet
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Microsoft обещает радикально усилить... 
 Ядро Linux избавляется от российских... 
 20 лет Ubuntu 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / theory
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Есть такое понятие в раидах, как перестроение. причем "на... 30.01.07 14:51  Число просмотров: 4362
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
Отредактировано 30.01.07 14:53  Количество правок: 1
<"чистая" ссылка>
> Каким-то образом, в рассогласованном режиме (при выходе из
> строя 1 ЖД), массив может частично перестраиваться и
> продолжать писать КС, типа это сделано для случайного
> выхода из строя 2-го ЖД вскоре после отказа 1-го. Неуверен
> на 100%, но так мне рассказывали знающие люди. Сам я этот
> вопрос настолько глубоко еще не изучал.

Есть такое понятие в РАИДах, как ПЕРЕСТРОЕНИЕ. Причем "на лету".
В параметрах многих контроллерах есть такая опция, как перестроение "автоматическое" или "ручное".
Чаще всего под этим понимается следующее: в слечае вылета диска в хотсваповой корзине, при замены диска (выдергивания и втыкания) будет ли сразу автоматически запущен процесс записи на диск необходимой информации (перерасчет и запись КС или данных) в зависимости от того, что на нем должно быть, или это процесс пойдет только после того, как человек его инициирует посредством соответствующей программы. "Автомат" придуман для тех ламеров, которые для настройки вызывают админа, а передернуть диски и сами смогут если что. "Ручной" режим придуман для того, чтоб контроллер не сразу начал грохать все на свежеустановленном винте.
Многие любят устанавливать еще один диск (HOT SPARE). Этот винт будет бездействовать и дожидаться момента, пока не грохнется один из работающих винтов. В случае вылета оного и перехода массива в состояние "критикал" контроллер представит, что неисправный диск выдернули, а новый засунули в другой бэй, что в принципе тоже можно назвать перестроением, поскольку к винтам привязаны их лонические номера в массиве и порядок их включения в контроллере.
Ну и из 0 рэйда легко сделать 5, 4 и иногда другие, как, впрочем и наоборот, посредством добавления/изъятия винта и проведения процедуры синхронизации данных и КС. Так что перестроением можно назвать и процедуру перехода из состояния "критикал" в "0", но не критикал.
<theory>
Контрольная сумма TCP 18.01.07 20:27   [Den]
Автор: makeworld Статус: Member
<"чистая" ссылка>
Сколько ошибок может обнаружить и сколько исправить контрольная сумма TCP заголовка? В RFC 793 этого нет.
Прочитал такую вещь: 18.01.07 23:37  
Автор: makeworld Статус: Member
<"чистая" ссылка>
Прочитал такую вещь:

Поле контрольной суммы — это 16-битное дополнение суммы всех 16- битных слов заголовка и текста. Если сегмент содержит в заголовке и тексте нечетное количество октетов, подлежащих учету в контрольной сумме, последний октет будет дополнен нулями справа с тем, чтобы образовать для предоставления контрольной сумме 16-битное слово. Возникший при таком выравнивании октет не передается вместе с сегментом по сети. Перед вычислением контрольной суммы поле этой суммы заполняется нулями.

Особенно заинтересовало, что "последний октет будет дополнен нулями справа с тем, чтобы образовать для предоставления контрольной сумме 16-битное слово" при таком коде в качестве примера:
unsigned short CalculateChecksum(unsigned short *usBuf, int iSize)
{
    unsigned long usChksum=0;
    while (iSize>1)
    {
        usChksum+=*usBuf++;
        iSize-=sizeof(unsigned short);
    }

    if (iSize)
        usChksum+=*(unsigned char*)usBuf;

    usChksum=(usChksum >> 16) + (usChksum & 0xffff);
    usChksum+=(usChksum >> 16);

    return (unsigned short)(~usChksum);
}

---

т.е. если число октетов нечетное, берется сумма WORD'ов + последний байт. дополнения нулями справа до WORDa не происходит.

http://www.rsdn.ru/Forum/Info.aspx?name=FAQ.network.tcp.checksum
Нули справа - старшая часть "16 bit words", как и было... 24.01.07 22:52  
Автор: Serge3leo Статус: Незарегистрированный пользователь
<"чистая" ссылка>
> т.е. если число октетов нечетное, берется сумма WORD'ов +
> последний байт. дополнения нулями справа до WORDa не
> происходит.

Нули справа - старшая часть "16 bit words", как и было указано в документе.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
старший байт ведь находится "слева". а дополнять предлагает... 24.01.07 23:03  
Автор: makeworld Статус: Member
<"чистая" ссылка>
>
> Нули справа - старшая часть "16 bit words", как и было
> указано в документе.
>

старший байт ведь находится "слева". а дополнять предлагает справа. или тут еще учитывается сетевой порядок байт, где все наоборот?
Хм. Вспомни, пожалуйста, откуда ты узнал, что "старший байт... 25.01.07 09:36  
Автор: Serge3leo Статус: Незарегистрированный пользователь
Отредактировано 25.01.07 09:46  Количество правок: 1
<"чистая" ссылка>
> > Нули справа - старшая часть "16 bit words", как и было
> > указано в документе.
> старший байт ведь находится "слева".

Хм. Вспомни, пожалуйста, откуда ты узнал, что "старший байт ведь находится "слева"? Из какого документа? А теперь, внимание, вопрос: ссылается ли данное RFC на этот документ?

> а дополнять предлагает
> справа. или тут еще учитывается сетевой порядок байт, где
> все наоборот?
http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/inet/ip/ip_cksum.c#300

P.S.
Прошу прощения, тебе же, как 'make world'-у должна быть ближе следующая ссылка:
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/in_cksum.c
:)
ну я вообще исходил из того, что старший байт это байт... 25.01.07 18:21  
Автор: makeworld Статус: Member
Отредактировано 25.01.07 18:22  Количество правок: 2
<"чистая" ссылка>
> Хм. Вспомни, пожалуйста, откуда ты узнал, что "старший байт
> ведь находится "слева"? Из какого документа? А теперь,
> внимание, вопрос: ссылается ли данное RFC на этот документ?

ну я вообще исходил из того, что старший байт это байт содержащий старшие разряды. а старшие разряды (если читать число слева направо) находятся слева :)
Это вообще не имеет значения. КС вычисляется *побайтным* сложением. См. исходник. 25.01.07 17:29  
Автор: kstati <Евгений Борисов> Статус: Elderman
<"чистая" ссылка>
хмм, и в исходнике и в тексте сложение слов (2 байта). кроме... 25.01.07 18:12  
Автор: makeworld Статус: Member
Отредактировано 25.01.07 18:18  Количество правок: 1
<"чистая" ссылка>
хмм, и в исходнике и в тексте сложение слов (2 байта). кроме последнего возможного байта (если размер данных, для которых считается КС, равен нечетному числу байт). имею в виду тот исходник, что я выше приводил.. над тем, что привел Serge3leo нужно еще голову поломать, чтобы понять что там и как происходит.
А как на счет того, x+0=x? И в результате можно считать, что в принципе дополнение происходит? ;) 19.01.07 00:44  
Автор: kstati <Евгений Борисов> Статус: Elderman
Отредактировано 19.01.07 01:05  Количество правок: 1
<"чистая" ссылка>
Но, по сути, даже если упустить эту мелочь, то каким образом ты все-таки предполагаешь восстановливать данные?
это че дополнение байта до слова нулями справа? 19.01.07 12:29  
Автор: makeworld Статус: Member
<"чистая" ссылка>
> А как на счет того, x+0=x? И в результате можно считать,
> что в принципе дополнение происходит? ;)

это че дополнение байта до слова нулями справа?

есть у нас байт 0xaa; дополнив его до слова нулями справа мы получим слово 0xaa00, т.е. совсем другое число - намного большее. в коде же такого дополнения не происходит, последнее прибавляемое "слово" имеет вид 0x00aa.

> Но, по сути, даже если упустить эту мелочь, то каким
> образом ты все-таки предполагаешь восстановливать данные?

давно уже не предлагаю
да, это верх оптимизации ): usChksum+=*(unsigned char*)usBuf; данные к слову в цикле прибавляются побайтно. 19.01.07 16:17  
Автор: kstati <Евгений Борисов> Статус: Elderman
<"чистая" ссылка>
Lol. обнаружение ошибки (теоретически) = 2^длинна_кс_в_битах (2^16) к 1; исправление - 0. на то она и контрольная сумма, чтобы контролировать. это ж не raid, где с помощью избыточных данных можно производить восстановление... 18.01.07 21:12  
Автор: kstati <Евгений Борисов> Статус: Elderman
Отредактировано 19.01.07 00:36  Количество правок: 1
<"чистая" ссылка>
Можно расшифровать что это значит? Если длинна КС = 16,... 18.01.07 22:32  
Автор: makeworld Статус: Member
Отредактировано 18.01.07 23:42  Количество правок: 2
<"чистая" ссылка>
> Обнаружение ошибки (теоретически) = 2^Длинна_КС_В_БИТАХ (2^32) к 1;
Можно расшифровать что это значит? Если длинна КС = 16, сколько ошибок можно обнаружить?

Кстати, для вычисления КС IP и TCP заголовка используется CRC16? - update: уже понял, что нет.
Это означает, что существует 65536 вариантов кс (кстати, используется на 1 меньше - нуль для отладки). В результате шанс *НЕ*обнаружения ошибки = 1/65535 ~ 0,0015%. А восстановление мягко говоря проблематично ) В каком окете "ошибка"? Или вообще во всех? 19.01.07 00:54  
Автор: kstati <Евгений Борисов> Статус: Elderman
<"чистая" ссылка>
как ты получил вероятность необнаружения ошибки? 19.01.07 12:48  
Автор: makeworld Статус: Member
<"чистая" ссылка>
как ты получил вероятность необнаружения ошибки?

существует 2^16 - 1 вариантов КС. существует на порядки больше вариантов массивов даннных, для которых будет считаться КС. Т.е. будет множество вариантов для РАЗНЫХ массивов даннных, для которых КС одинаковая. При этом например если произойдет 2 ошибки - один октет будет искажен и увеличен на 1, а другой уменьшен на 1, ошибка обнаружена не будет, т.к. сумма, а следовательно и дополнение не измениться. И таких ситуаций можно привести очень много. Как ты так лихо вывел вероятность необнаружения ошибки?

А вообще в самом первом посте я искал информацию о характеристиках обнаружения ошибок КС применяемой в TCP. Т.е. сколько, каких и в каких ситуациях ошибок обнаруживается. А про исправление ошибок я ступил.
Вероятность - предел отношения благоприятных событий к... 24.01.07 11:10  
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
Отредактировано 24.01.07 11:12  Количество правок: 1
<"чистая" ссылка>
> как ты получил вероятность необнаружения ошибки?

Вероятность - предел отношения благоприятных событий к общему их числу.
В данном случае при равновероятных событиях ограниченного их количества предел считается как просто отношение благоприятных событий к общему их числу.
Количество "благоприятных" (если их можно назвать таковыми) событий будет общее количество всех комбинаций пакетов данных, деленных на 65535. То есть сколько из них будет давать одну и ту же КС из общего их количества.
Вероятность получаем, разделив на общее количество всех комбинаций пакетов данных, то есть на числитель. Получаем "1/65535".
Если предположить, что КС всегда передается без искажений, а... 24.01.07 15:56  
Автор: makeworld Статус: Member
<"чистая" ссылка>
> > как ты получил вероятность необнаружения ошибки?
>
> Вероятность - предел отношения благоприятных событий к
> общему их числу.
> В данном случае при равновероятных событиях ограниченного
> их количества предел считается как просто отношение
> благоприятных событий к общему их числу.
> Количество "благоприятных" (если их можно назвать таковыми)
> событий будет общее количество всех комбинаций пакетов
> данных, деленных на 65535. То есть сколько из них будет
> давать одну и ту же КС из общего их количества.
> Вероятность получаем, разделив на общее количество всех
> комбинаций пакетов данных, то есть на числитель. Получаем
> "1/65535".

Если предположить, что КС всегда передается без искажений, а общее количество всех комбинаций пакетов данных = X ,тогда:

X можно разделить на 65535 равных подмножеств сообщений. у каждого сообщения одного подмножества КС одинаковая. необнаружение ошибки происходит когда во время передачи произошли ошибки, и при этом новое сообщение с ошибками принадлежит тому же подмножеству, что и исходное.

вероятность этого события равна ( (X/65535) - 1 ) / X

так или я где-то ошибся?
Можно даже искажения КС учесть. Почему бы и нет... 25.01.07 11:43  
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
<"чистая" ссылка>
> Если предположить, что КС всегда передается без искажений,
> а общее количество всех комбинаций пакетов данных = X
> ,тогда:

Можно даже искажения КС учесть. Почему бы и нет...

> X можно разделить на 65535 равных подмножеств сообщений. у
> каждого сообщения одного подмножества КС одинаковая.
> необнаружение ошибки происходит когда во время передачи
> произошли ошибки, и при этом новое сообщение с ошибками
> принадлежит тому же подмножеству, что и исходное.
>
> вероятность этого события равна ( (X/65535) - 1 ) / X
>
> так или я где-то ошибся?

В предположении того, что Х велико по сравнению с 65535, то (Х/65535)-1 будет мало отличаться от (Х/65535). На Х можно сократить. В числителе останется 1.
Конечно ошибся, откуда ты взял, что можно разделить на 65535... 24.01.07 23:10  
Автор: Serge3leo Статус: Незарегистрированный пользователь
<"чистая" ссылка>
> X можно разделить на 65535 равных подмножеств сообщений. у
> ...
> так или я где-то ошибся?

Конечно ошибся, откуда ты взял, что можно разделить на 65535 равных подмножеств?
Не ошибся. Эти множества будут очень даже равные... 25.01.07 11:38  
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
<"чистая" ссылка>
> > X можно разделить на 65535 равных подмножеств
> сообщений. у
> > ...
> > так или я где-то ошибся?
>
> Конечно ошибся, откуда ты взял, что можно разделить на
> 65535 равных подмножеств?

Не ошибся. Эти множества будут очень даже равные. Дказательство просто: Будем перебирать все данные, начиная увеличивать с младшего байта. Как только произойдет переполнение, увеличим второй байт и так далее. При этом КС будет аналогично увеличиваться на единичку каждый раз. После переполнения разрядности КС все начнется с начала.
1  |  2  |  3 >>  »  




Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2024 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach