Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
| |
Нули справа - старшая часть "16 bit words", как и было... 24.01.07 22:52 Число просмотров: 4510
Автор: 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
<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 равных подмножеств?
Не ошибся. Эти множества будут очень даже равные. Дказательство просто: Будем перебирать все данные, начиная увеличивать с младшего байта. Как только произойдет переполнение, увеличим второй байт и так далее. При этом КС будет аналогично увеличиваться на единичку каждый раз. После переполнения разрядности КС все начнется с начала.
|
|
|
подробно о проекте
Анализ криптографических сетевых...
