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





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Кто б спорил-то? ну, разве что метод расчета чаще всего - "четность по модулю два". но, именно *избыточность*: берем пять дисков, получаем объем четырех, при этом **любой** из них можно выбросить в мусорку и не произойдет потери данных. а в протоколе tcp? 19.01.07 00:33  Число просмотров: 3617
Автор: kstati <Евгений Борисов> Статус: Elderman
Отредактировано 19.01.07 00:34  Количество правок: 1
<"чистая" ссылка>
<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