Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
| | | | | | |
Касаемо ЖД - это до сих пор для меня остается загадкой. 30.01.07 12:07 Число просмотров: 4316
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
Отредактировано 30.01.07 12:10 Количество правок: 1
|
Касаемо ЖД - это до сих пор для меня остается загадкой.
> :) Неа! ЖД не являются отказоустойчивыми по
> следующим причинам:
Смотря что вкладывать в понятие отказоустойчивости.
> 1. КС сектора ЖД расчитывается для всех данных сектора, что
> не позволяет исправить ошибку в случае искажения при чтении
> и служит лишь проверкой на корректность прочитанных с
> носителя (блина ЖД) данных.
>
> 2. КС сектора ЖД, как и сами данные сектора, располагается
> на том же носителе (блине ЖД).
>
Так в чем же загадка КС винта? Я слышал про размерность в 4 и 6 байт для 512 байтного сектора. Пока не знаю точно, возможно ли обеспечить обнаружение и восстановление искаженный данных сектора такой маленькой КС.
Знаю, что возможно восстановить (предварительно обнаружив) целый байт в полкило, дополнительно приписав КС, размерностью в 24 байта, при условии, что испорчен только один байт. Далее могу посчитать вероятность того, что искажение данных вообще не будет обнаружена, сколько байт может быть испорчено, чтоб их можно было обнаружить, но не восстановить и пр.
Могу догадываться только об одном, что КС винта мала для того, чтоб восстановить хотя бы пару бит, но достаточна, чтоб гарантировано определить искажение нескольких бит.
> В чем, конкретно, мое заблуждение???
> Подозреваю, что заблуждаюсь не я...
Ну и по поводу "отказоустойчивости" РАИДа: Ну избыточный он, ну храниться все, что нужно для восстановления на отдельном винте, все равно это замкнутая система, как и отдельно взятый винт. Если расплющить под пресом это устройство, то оно так же откажет, как и отдельно взятый винт.
Если десяток-полтора винтов сидят на одной скайзи шинке, то если хотя бы у одного винта прогорит контроллер интерфейса так, что закоротит всю скайзи шину, то какого бы не был уровня РАИД, он откажет как один диск.
Чаще отказывет механика и поверхность винта - правильно! Ни что не мешает внутри одного диска организовать РАИД, главное чтоб блинов/поверхностей у него было больше одного. Просто представим, что это не просто винт, а несколько одноблиновых винтов. На одну поверхность пишем избыточность, а на остальные - данные. Оторвет ли голову, погорит ли она, поцарапается ли поверхность, винт будет жив. А уж если погорит контроллер - извиняйте батько, но можно махнуть и винт опять жив, и данные не потеряны, разве что система немного постояла/отдохнула.
Послесловие: не советую ни кому писать драйвер, реализующий функцию РАИДа на одном винте.
Ну и если вернуться к сетке, то для обнаружения искажения достаточно и пары байт. Если пакеты пойдут битые, то сетка сразу просядет так, что никто не будет дожитаться 65536 пакета. А восстанавливать данные никому не надо, это не РАИД, который данные хранит, в сетке можно и повторить посылку.
|
|
<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 равных подмножеств?
Не ошибся. Эти множества будут очень даже равные. Дказательство просто: Будем перебирать все данные, начиная увеличивать с младшего байта. Как только произойдет переполнение, увеличим второй байт и так далее. При этом КС будет аналогично увеличиваться на единичку каждый раз. После переполнения разрядности КС все начнется с начала.
|
|
|
подробно о проекте
Анализ криптографических сетевых...
