CRC

← →
defen © (2012-01-03 11:58) [0]

Всем доброго времени суток. Подскажите пожалуйста, как быстро реализовать подсчет CRC для передаваемого пакета? Длинна пакета 136 байт Заголовок 2 байта, Счетчик 2байта, Длинна пакета 2байта, Данные 128байт. В конце CRC тоже 2 байта. по гуглу нашел только проверку CRC для готового файла, но применить к своей проге не смог, увы... :(

← →
Андреевич (2012-01-03 12:14) [1]

снимает crc32 с потока
function MemoryStream_CRC32(mou:Tstream): Cardinal; const BufLen = 32768; const CRC32_Table: array[0..255] of LongWord = ($00000000,$77073096,$EE0E612C,$990951BA,$076DC419,$706AF48F,$E963A535,$9E6495A3 , $0EDB8832,$79DCB8A4,$E0D5E91E,$97D2D988,$09B64C2B,$7EB17CBD,$E7B82D07,$90BF1D91, $1DB71064,$6AB020F2,$F3B97148,$84BE41DE,$1ADAD47D,$6DDDE4EB,$F4D4B551,$83D385C7, $136C9856,$646BA8C0,$FD62F97A,$8A65C9EC,$14015C4F,$63066CD9,$FA0F3D63,$8D080DF5, $3B6E20C8,$4C69105E,$D56041E4,$A2677172,$3C03E4D1,$4B04D447,$D20D85FD,$A50AB56B, $35B5A8FA,$42B2986C,$DBBBC9D6,$ACBCF940,$32D86CE3,$45DF5C75,$DCD60DCF,$ABD13D59, $26D930AC,$51DE003A,$C8D75180,$BFD06116,$21B4F4B5,$56B3C423,$CFBA9599,$B8BDA50F, $2802B89E,$5F058808,$C60CD9B2,$B10BE924,$2F6F7C87,$58684C11,$C1611DAB,$B6662D3D, $76DC4190,$01DB7106,$98D220BC,$EFD5102A,$71B18589,$06B6B51F,$9FBFE4A5,$E8B8D433, $7807C9A2,$0F00F934,$9609A88E,$E10E9818,$7F6A0DBB,$086D3D2D,$91646C97,$E6635C01, $6B6B51F4,$1C6C6162,$856530D8,$F262004E,$6C0695ED,$1B01A57B,$8208F4C1,$F50FC457, $65B0D9C6,$12B7E950,$8BBEB8EA,$FCB9887C,$62DD1DDF,$15DA2D49,$8CD37CF3,$FBD44C65, $4DB26158,$3AB551CE,$A3BC0074,$D4BB30E2,$4ADFA541,$3DD895D7,$A4D1C46D,$D3D6F4FB, $4369E96A,$346ED9FC,$AD678846,$DA60B8D0,$44042D73,$33031DE5,$AA0A4C5F,$DD0D7CC9, $5005713C,$270241AA,$BE0B1010,$C90C2086,$5768B525,$206F85B3,$B966D409,$CE61E49F, $5EDEF90E,$29D9C998,$B0D09822,$C7D7A8B4,$59B33D17,$2EB40D81,$B7BD5C3B,$C0BA6CAD, $EDB88320,$9ABFB3B6,$03B6E20C,$74B1D29A,$EAD54739,$9DD277AF,$04DB2615,$73DC1683, $E3630B12,$94643B84,$0D6D6A3E,$7A6A5AA8,$E40ECF0B,$9309FF9D,$0A00AE27,$7D079EB1, $F00F9344,$8708A3D2,$1E01F268,$6906C2FE,$F762575D,$806567CB,$196C3671,$6E6B06E7, $FED41B76,$89D32BE0,$10DA7A5A,$67DD4ACC,$F9B9DF6F,$8EBEEFF9,$17B7BE43,$60B08ED5, $D6D6A3E8,$A1D1937E,$38D8C2C4,$4FDFF252,$D1BB67F1,$A6BC5767,$3FB506DD,$48B2364B, $D80D2BDA,$AF0A1B4C,$36034AF6,$41047A60,$DF60EFC3,$A867DF55,$316E8EEF,$4669BE79, $CB61B38C,$BC66831A,$256FD2A0,$5268E236,$CC0C7795,$BB0B4703,$220216B9,$5505262F, $C5BA3BBE,$B2BD0B28,$2BB45A92,$5CB36A04,$C2D7FFA7,$B5D0CF31,$2CD99E8B,$5BDEAE1D, $9B64C2B0,$EC63F226,$756AA39C,$026D930A,$9C0906A9,$EB0E363F,$72076785,$05005713, $95BF4A82,$E2B87A14,$7BB12BAE,$0CB61B38,$92D28E9B,$E5D5BE0D,$7CDCEFB7,$0BDBDF21, $86D3D2D4,$F1D4E242,$68DDB3F8,$1FDA836E,$81BE16CD,$F6B9265B,$6FB077E1,$18B74777, $88085AE6,$FF0F6A70,$66063BCA,$11010B5C,$8F659EFF,$F862AE69,$616BFFD3,$166CCF45, $A00AE278,$D70DD2EE,$4E048354,$3903B3C2,$A7672661,$D06016F7,$4969474D,$3E6E77DB, $AED16A4A,$D9D65ADC,$40DF0B66,$37D83BF0,$A9BCAE53,$DEBB9EC5,$47B2CF7F,$30B5FFE9, $BDBDF21C,$CABAC28A,$53B39330,$24B4A3A6,$BAD03605,$CDD70693,$54DE5729,$23D967BF, $B3667A2E,$C4614AB8,$5D681B02,$2A6F2B94,$B40BBE37,$C30C8EA1,$5A05DF1B,$2D02EF8D) ; var Res:Integer; BufPtr:Pointer; crcnew:longword; Buf: array[0..BufLen-1] of Byte; function G_NextCRC32(var CRC32: LongWord; P: Pointer; L: Cardinal): LongWord; asm TEST ECX,ECX JE @@qt PUSH EBX PUSH EAX MOV EAX,[EAX] NOT EAX PUSH ESI @@lp: MOVZX ESI,BYTE PTR [EDX] MOVZX EBX,AL SHR EAX,8 XOR EBX,ESI XOR EAX,DWORD PTR [EBX*4+CRC32_Table] INC EDX DEC ECX JNE @@lp POP ESI POP EDX NOT EAX MOV [EDX],EAX POP EBX RET @@qt: MOV EAX,[EAX] end; begin BufPtr := @Buf; crcnew:=0; mou.Position:=0; Res:=mou.Read(Buf,sizeof(Buf)); while (Res<>0) do begin G_NextCRC32(crcnew,BufPtr,res); Res:=mou.Read(Buf,sizeof(Buf)); end; Result:=crcnew; end;

← →
defen © (2012-01-03 12:25) [2]

дело в том, что я не стал использовать потоки... Файл считывается побайтно и передается в массив типа byte, затем из этого массива считываются данные и отправляются в массив для передаваемого пакета. когда пакет готов к отправке он записывается в переменную типа AnsiString и пуляется в канал. Поэтому очень хотелось бы работать уже с готовыми данными, а не переделывать все заново. извиняюсь, что не уточнил сразу...

← →
sniknik © (2012-01-03 12:48) [3]

за целостность пакета вообще то отвечает протокол... т.е. если взять UDP то он без гарантированной доставки, но раз пришел то с верными/проверенными данными.
т.е. ты изобретаешь велосипед там где он не нужен, поверх существующего, а вот собственную сборку целого из пакетов не проверяешь... хотя при "выпадении", или изменении очередности пакетов (и то и то вполне вероятно), получишь "криво" собранное целое.

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

← →
defen © (2012-01-03 13:12) [4]

канал узкий, я не могу использовать стандартные протоколы передачи данных. Единственное, что подошло - это Hiper Terminal с проверкой ошибочных пакетов или что-то в этом духе. Но он работает весьма глючно...

← →
defen © (2012-01-03 13:13) [5]

просто с потоками не работал, а времени в обрез...

← →
defen © (2012-01-03 13:22) [6]

> а вот собственную сборку целого из пакетов не проверяешь.
> ..

я так понял имеется ввиду уже конечный продукт.
Естественно, что буду его проверять и очередность пакетов тоже, но сейчас важно именно принятие правильного пакета...

← →
sniknik © (2012-01-03 13:36) [7]

> но сейчас важно именно принятие правильного пакета...
функция проверки
function isProperPackage(const ValuePackage: string): boolean; begin result:= true; end;
пользуйся.

← →
defen © (2012-01-03 13:50) [8]

а что это за функция?

← →
Sha © (2012-01-03 15:03) [9]

crc32 http://guildalfa.ru/alsha/node/2
crc64 http://guildalfa.ru/alsha/node/4

скорость на разных компах см. в комментариях

← →
defen © (2012-01-03 15:11) [10]

спасибо, буду пробовать....

← →
Андреевич (2012-01-03 18:00) [11]

> за целостность пакета вообще то отвечает протокол... т.е.
> если взять UDP то он без гарантированной доставки, но раз
> пришел то с верными/проверенными данными.
> т.е. ты изобретаешь велосипед там где он не нужен, поверх
> существующего,

не редко делают в играх, наворачивая сверху свою проверку на доставку и очередность, быстрее чем tcp

← →
sniknik © (2012-01-03 20:13) [12]

> наворачивая сверху свою проверку на доставку и очередность, быстрее чем tcp
???
"навернутое" сверху не может быть быстрее стандартного, т.к. его включает. может быть "вместо", но тут уровень программиста должен быть другой, кто-то досконально знающий стандартный и поэтому знающий за счет чего можно ускорить (скорость за счет надежности, если она где то не нужна. и т.д.).

← →
antonn © (2012-01-03 23:03) [13]

игроделы таким занимаются

> "навернутое" сверху не может быть быстрее стандартного,

навернутое над upd бывает оптимальнее tcp, я про это

← →
DVM © (2012-01-03 23:31) [14]

> antonn © (03.01.12 23:03) [13]

> навернутое над upd бывает оптимальнее tcp, я про это

Только там, где можно смириться с потерей части данных (игры, видео, звук) и где порция данных целиком помещается в пакет. Иначе будет тот же TCP только в профиль.

← →
DVM © (2012-01-03 23:47) [15]

> defen ©

в IP пакете есть уже CRC:

{ Internet Datagram Header (RFC 791) 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| IHL |Type of Service| Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time to Live | Protocol | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ }

← →
DVM © (2012-01-03 23:49) [16]

и в UDP есть, еще одна.

про TCP я уж молчу.

← →
sniknik © (2012-01-03 23:53) [17]

> навернутое над upd бывает оптимальнее tcp, я про это
а зачем ты "про это"? "клиент" про пакеты, ответ про пакеты, сказано почему для пакетов это лишнее. зачем приплетать отвлекающее "а вот если бы, то ...".
решил запутать "клиента"?

← →
Sha © (2012-01-04 00:34) [18]

Checksum <> CRC
16 <> 32

← →
Sha © (2012-01-04 00:34) [19]

Удалено модератором

← →
DVM © (2012-01-04 00:39) [20]

> Sha ©

Да, все верно CRC это конечно же не Checksum, но корректность передаваемых данных с некоторой долей вероятности позволяет проверить и то и другое.

← →
sniknik © (2012-01-04 00:56) [21]

легковушка <> белаз
ее размер <> его размеру
вывод - чтобы ездить нужно помешать легковушку в кузов белаза... да, так, и только так! пойти что ли поучить водителей, как надо?

← →
Sha © (2012-01-04 01:14) [22]

> sniknik © (04.01.12 00:56) [21]
> вывод - чтобы ездить нужно помешать легковушку в кузов белаза...
> да, так, и только так! пойти что ли поучить водителей, как надо?

Мешать не буду.

А что не так в [18] ?

← →
sniknik © (2012-01-04 01:23) [23]

да все так, все правильно, но какой в этом смысл? для заявленной задачи. или мы опять до коня в вакууме скатились?

← →
Sha © (2012-01-04 01:29) [24]

если я скажу, что у меня была похожая задача - такой ответ устроит?

← →
Германн © (2012-01-04 02:01) [25]

Добавлю ещё одну ложку дёгтя в вашу бочку. Даже CRCnn существует несколько вариантов. Имхо по крайней мере где nn=8 или nn=16.

Но задача ТС действительно не вполне ясна.
Кто, как, какие пакеты передаёт - только аллаху известно.
ТС не привёл ни единой строчки своего кода. И где и как он считает некую контрольную сумму для отправки данных и где и как он при приёме данных её проверяет?

← →
Германн © (2012-01-04 02:17) [26]

Если вдуматься, я тоже своим железякам передаю "пакеты". И контрольную сумму ака CRC8 в конце добавляю. (Чтоб железяка не исполнила чёрт знает что в случае ошибки передачи/приёма.)
Я правда привык называть это передачей команд.

← →
defen © (2012-01-04 03:31) [27]

вот код отправки пакета. Проверку при приеме еще не написал, так как не знаю как посчитать CRC

Procedure Send_File; Var CheckPAck:Integer; Send_File:File; Fpointer, BytesRead, File_Size:Integer; Length_Name_And_FileSize, Temp_Length_Name_And_FileSize, I,i2: Integer; Counter:Word; Name_And_File_Size, Data_Paket_For_Send, File_Name :AnsiString; Begin CheckPAck:=0; General.GenForm.ComPort.BaudRate := TBaudRate(General.GenForm.CbPort.ItemIndex); If not General.GenForm.ComPort.Open Then Exit; // Открываем порт General.GenForm.BtnBreak.Enabled := True; //////////////// Определяем размер и имя файла /////////////////////// File_Name:=General.GenForm.OD.FileName; AssignFile(Send_File, File_Name); Reset(Send_File, 1); File_Size:=FileSize(Send_File); General.GenForm.Progress.Position :=0; General.GenForm.Progress.Max:=File_Size; //////_Отправляем_имя_файла_и_размер_///// Begin // Заголовок пакета 2 байта (255 означает, что это данные) File_Paket [1]:=255; File_Paket [2]:=255; Counter:=0; // Счетчик 2 байта ("00" означает начало передачи имени и размера файла) PWord(@File_paket[3])^ :=counter; // Полезная длинна пакета (старший 2 байт) // Считываем количество символов в имени файла и размер Length_Name_And_FileSize:=Length(General.GenForm.OD.FileName+"_"+IntTostr(File_Size)); // Считываем количество символов File_paket[5]:=Length_Name_And_FileSize; Name_And_File_Size:= General.GenForm.OD.FileName+"_"+IntTostr(File_Size); Temp_Length_Name_And_FileSize:=7+Length_Name_And_fileSize; For i:=7 To Temp_Length_Name_And_fileSize Do File_Paket[i]:=ord(Name_And_File_Size[i-6]); For i:=0 to 136 do Data_Paket_For_Send:=Data_Paket_For_Send+chr(File_Paket[i+1]); General.GenForm.ComPort.WriteStr(Data_Paket_For_Send); End; /////////////////////////////////////////////// //////////////_Отправляем_Файл_/////////////////////////////////////// While Not Eof(Send_File) Do Begin counter:=counter+1; Fpointer:=FilePos(Send_File); BlockRead(Send_File, Block_File, 128, BytesRead); // Counter > 0 начинаем передачу файла // Заголовок пакета 2 байта (255 означает, что отправляюся данные) File_Paket [1]:=255; File_Paket [2]:=255; // Счетчик 2 байта PWord(@File_paket[3])^ :=counter; // Полезная длинна пакета (старший 2 байт) // Переменная BytesRead хранит в себе данные о реально считанных байтах // файла. Берем её как значение для 6 байта пакета File_paket[5]:=BytesRead; //////////////////////////////////////////////////////////////////////// i2:=0; For i:=7 To BytesRead+6 Do Begin i2:=i2+1; File_Paket[i]:=Block_File[i2]; end; Data_Paket_For_Send:=""; For i:=1 to 136 do Data_Paket_For_Send:=Data_Paket_For_Send+chr(File_Paket[i]); General.GenForm.ComPort.WriteStr(Data_Paket_For_Send); //BlockWrite(DpoQOutFile, mplexkadri, 267); Application.ProcessMessages; CheckPAck:=CheckPAck+1; General.GenForm.Progress.Position:=General.GenForm.Progress.Position+128; General.GenForm.Label7.Caption:=inttostr(CheckPAck); seek (Send_File, Fpointer+128); End; CloseFile (Send_File); end;

← →
DVM © (2012-01-04 11:03) [28]

> Германн © (04.01.12 02:01) [25]
>
> Добавлю ещё одну ложку дёгтя в вашу бочку. Даже CRCnn существует
> несколько вариантов. Имхо по крайней мере где nn=8 или nn=16.
>

Да. Их не менее десятка вариантов только распространенных, а вообще может быть сколько угодно много. Как то от нечего делать писал модуль, где реализовал большинство известных методов вычисления.
CRC8-SMBUS, CRC8-DALLAS-MAXIM, CRC-16(Standard), CRC16-IBM, CRC-16-BISYNCH, CRC-16-CCITT, CRC16-XMODEM, CRC-32(Standard), CRC-32C, и т.д. Отличаются полиномами, инвертацией входных и-или выходных данных, и т.д.

← →
DVM © (2012-01-04 11:06) [29]

> defen © (04.01.12 03:31) [27]
>
> вот код отправки пакета. Проверку при приеме еще не написал,
> так как не знаю как посчитать CRC
>

Тебе конкретно какой алгоритм нужен, дай название или хотя бы где он используется скажи, или полином назови. Будет тебе алгоритм. Или все равно?

← →
sniknik © (2012-01-04 11:53) [30]

> ComPort
COM порт значит..., модем наверное? старый. ну так у портов насколько помню каждый переданный байт проверяется, там типа бит четности, и вообще система с коррекцией ошибок передачи... в модеме тоже самое, протокол либо с коррекцией/или просто с прерыванием по ошибке.

фигней короче занимаешься.

> Или все равно?
судя по всему да, он просто добавляет "солидности" программе, на деле это просто такой странный "паскалевский delay".

← →
antonn © (2012-01-04 12:51) [31]

> Sha © (04.01.12 01:29) [24]
>
> если я скажу, что у меня была похожая задача - такой ответ
> устроит?

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

← →
DVM © (2012-01-04 13:28) [32]

> antonn © (04.01.12 12:51) [31]

> они сейчас попросят расписать в чем была суть задачи

Они это кто?

Ты хочешь дать ответ на вопрос автора? Тебе не кажется, что вместо нытья какие плохие отвечающие на делфимастере пора бы уже начать самому отвечать так как считаешь это должно быть в идеале. А пока одно нытье какое то.

← →
Андреевич (2012-01-04 15:34) [33]

> пора бы уже начать самому отвечать так как считаешь это
> должно быть в идеале

как только мне опишут в идеале суть задачи.
а разговор не про автора, а за [12][13]

ах да, за [14]

> > навернутое над upd бывает оптимальнее tcp, я про это
>
> Только там, где можно смириться с потерей части данных (игры,
> видео, звук) и где порция данных целиком помещается в пакет.
> Иначе будет тот же TCP только в профиль.

оно бывает быстрее, даже со своими очередями и проверками на гарантию доставки, на основе udp

← →
Андреевич (2012-01-04 15:37) [34]

ну и еще вырву из контекста:

> Тебе не кажется, что вместо нытья какие плохие отвечающие
> на делфимастере пора бы уже начать самому отвечать

я в [1] дал пример crc32, его не сложно переделать под чтение из файла, т.к. переменные в том примере позволяют сделать это без особых изменений, нужно лишь другую функцию подсчета crc (которая, вроде бы, автором где-то виделась). Это был ответ или оффтоп?

← →
_ (2012-01-04 16:12) [35]

function Crc16(Buff:PByte;Len:Integer):Word; const cCrcTab:array [0..255] of Word= // ($A001) ($0000,$C0C1,$C181,$0140,$C301,$03C0,$0280,$C241,$C601,$06C0,$0780,$C741,$0500,$ C5C1,$C481,$0440 ,$CC01,$0CC0,$0D80,$CD41,$0F00,$CFC1,$CE81,$0E40,$0A00,$CAC1,$CB81,$0B40,$C901,$ 09C0,$0880,$C841 ,$D801,$18C0,$1980,$D941,$1B00,$DBC1,$DA81,$1A40,$1E00,$DEC1,$DF81,$1F40,$DD01,$ 1DC0,$1C80,$DC41 ,$1400,$D4C1,$D581,$1540,$D701,$17C0,$1680,$D641,$D201,$12C0,$1380,$D341,$1100,$ D1C1,$D081,$1040 ,$F001,$30C0,$3180,$F141,$3300,$F3C1,$F281,$3240,$3600,$F6C1,$F781,$3740,$F501,$ 35C0,$3480,$F441 ,$3C00,$FCC1,$FD81,$3D40,$FF01,$3FC0,$3E80,$FE41,$FA01,$3AC0,$3B80,$FB41,$3900,$ F9C1,$F881,$3840 ,$2800,$E8C1,$E981,$2940,$EB01,$2BC0,$2A80,$EA41,$EE01,$2EC0,$2F80,$EF41,$2D00,$ EDC1,$EC81,$2C40 ,$E401,$24C0,$2580,$E541,$2700,$E7C1,$E681,$2640,$2200,$E2C1,$E381,$2340,$E101,$ 21C0,$2080,$E041 ,$A001,$60C0,$6180,$A141,$6300,$A3C1,$A281,$6240,$6600,$A6C1,$A781,$6740,$A501,$ 65C0,$6480,$A441 ,$6C00,$ACC1,$AD81,$6D40,$AF01,$6FC0,$6E80,$AE41,$AA01,$6AC0,$6B80,$AB41,$6900,$ A9C1,$A881,$6840 ,$7800,$B8C1,$B981,$7940,$BB01,$7BC0,$7A80,$BA41,$BE01,$7EC0,$7F80,$BF41,$7D00,$ BDC1,$BC81,$7C40 ,$B401,$74C0,$7580,$B541,$7700,$B7C1,$B681,$7640,$7200,$B2C1,$B381,$7340,$B101,$ 71C0,$7080,$B041 ,$5000,$90C1,$9181,$5140,$9301,$53C0,$5280,$9241,$9601,$56C0,$5780,$9741,$5500,$ 95C1,$9481,$5440 ,$9C01,$5CC0,$5D80,$9D41,$5F00,$9FC1,$9E81,$5E40,$5A00,$9AC1,$9B81,$5B40,$9901,$ 59C0,$5880,$9841 ,$8801,$48C0,$4980,$8941,$4B00,$8BC1,$8A81,$4A40,$4E00,$8EC1,$8F81,$4F40,$8D01,$ 4DC0,$4C80,$8C41 ,$4400,$84C1,$8581,$4540,$8701,$47C0,$4680,$8641,$8201,$42C0,$4380,$8341,$4100,$ 81C1,$8081,$4040); var Crc :Word; i :Integer; begin Crc:=$FFFF; for i := Len-1 downto 0 do begin Crc:=cCrcTab[Crc and $FF xor Buff^] xor (Crc shr 8); Inc(Buff); end; Result:=Crc; end;

← →
DVM © (2012-01-04 16:15) [36]

> Андреевич (04.01.12 15:34) [33]

> оно бывает быстрее, даже со своими очередями и проверками
> на гарантию доставки, на основе udp

Про ограничения подобного я уже написал. Конечно оно будет быстрее пока уступает функционально TCP. Как только оно начнет выполнять все функции TCP оно в лучшем случае сравняется с ним по быстродействию.

Вся потеря скорости в TCP по сравнению с UDP имхо возникает в основном при реконструкции оригинального потока на основе номеров последовательности пакетов. При приеме очередного пакета так или иначе происходит просмотр внутренних списков, аккумулирующих пакеты, как только появляется блок, в котором нет "дыр" он отдается принимающей стороне. Там сложно придумать что либо более оптимальное, чем уже есть при том же функционале.

← →
DVM © (2012-01-04 16:25) [37]

> Андреевич (04.01.12 15:37) [34]

> ну и еще вырву из контекста:

фраза была адресована не тебе.

> Это был ответ или оффтоп?

у меня к [1] вопросов нет. Хотя нет, есть один, что за метод вычисления CRC там? Какой полином? Желательно использовать методы рассчета, которые можно идентифицировать, иначе потом очень сложно будет с совместимостью и поддержкой.

← →
Андреевич (2012-01-04 16:37) [38]

> фраза была адресована не тебе.

в кому?

← →
DVM © (2012-01-04 17:32) [39]

> Андреевич (04.01.12 16:37) [38]
>
>
> > фраза была адресована не тебе.
>
> в кому?

Там написано было кому - antonn © (04.01.12 12:51) [31].

← →
Андреевич (2012-01-04 21:06) [40]

значит мне

> Андреевич (04.01.12 21:06) [40]
>
> значит мне
>

Ну и зачем тебе понадобился ещё один ник на ДМ?

народ, прекратите эту вербальную резню. мне нужно было организовать наложение CRC16 на строку (переменная Data_Paket_For_Send, File_Name :AnsiString;) см [27].
Передаются данные через модем. В настоящий момент по протоколу Kermit. Работает и Гипер Терминал (ZModem) но он до ужаса глючный, поэтому я пытаюсь создать что-то своё... Если есть вопросы, задавайте пожалуйста без сарказма... на что смогу, отвечу.

не надо ничего создавать, инет завален алгоритмами расчёта crc любой разновидности на любых данных.

> не надо ничего создавать, инет завален алгоритмами расчёта
> crc любой разновидности на любых данных.

спасибо за пост в тему...

> народ, прекратите эту вербальную резню. мне нужно было организовать
> наложение CRC16 на строку (переменная Data_Paket_For_Send,
> File_Name :AnsiString;)

Тебя уже несколько раз спросили, какой именно CRC нужен, и привели несколько различных реализаций. Может за тебя программу надо написать?

> Работает и Гипер Терминал (ZModem) но он до ужаса глючный,
> поэтому я пытаюсь создать что-то своё

И при этом у тебя проблема с CRC, не в состояние восспользоваться готовыми.

> defen © (05.01.12 09:01) [42]

Вообще говоря тебе уже дали код, да и в интернет этого добра навалом. Могу дать еще:

http://dvmuratov.narod.ru/crc.pas

там для твоей задачи вероятно лучше всего подходит этот:

////////////////////////////////////////////////////////////////////////////////
// Имя алгоритма : CRC16-XMODEM (?????) //
// Стандарты : ITU-T V.41 //
// Где используется : XMODEM, PPP //
// Иннициализирующее значение : $0000 //
// Выходная XOR маска : $0000 //
// Входные данные : не инвертируются //
// Выходной CRC перед XOR : не инвертируется //
// Значение полинома : $1021 (Зеркальное значение = $8408) //
// Полином : x^16 + x^15 + x^2 + 1 //
// Значение для "123456789" : $31C3 //
////////////////////////////////////////////////////////////////////////////////

> Германн © (05.01.12 04:35) [41]
>
>
> > Андреевич (04.01.12 21:06) [40]
> >
> > значит мне
> >
>
> Ну и зачем тебе понадобился ещё один ник на ДМ?

я уже говорил, что это не надобность.

> RWolf © (05.01.12 09:26) [43]
>
> не надо ничего создавать, инет завален алгоритмами расчёта
> crc любой разновидности на любых данных.

я бы предпочел чтобы мне посоветовали, а не взять с помойки "любой" код и потом гадать из-за чего чексуммы разные. Т.к. алгоритм - это одно, а реализация - другое :)

> я бы предпочел чтобы мне посоветовали, а не взять с помойки
> "любой" код и потом гадать из-за чего чексуммы разные. Т.
> к. алгоритм - это одно, а реализация - другое :)
>
>

Спасибо, Кэп! ))

значит получается мне надо на каждую ячейку массива ( их 134) типа Byte накладывать CRC, а потом склеивать? потому как перед отправкой данные из типа Byte переводятся в AnsiSrting... Как эти значения сложить, чтобы не было ошибок?

или я снова чего-то не понял?

данные в массиве примерно выглядят так [255,255,0,1,68,54,16,34,..до..135...,0,0] 135 и 136 будет СRС. А отправляются в канал уже вот так "яя"#1#0"какой-нибудь не читаемый символ"#A7#1D..до..135....#0#0 вот...

по сути, весь пакет хранится в байтовом виде в массиве......

> на каждую ячейку массива ( их 134) типа Byte накладывать CRC, а потом склеивать?

мне неизвестны операция "накладывания на ячейку массива" и
операция "склеивания чисел"

> потому как перед отправкой данные из типа Byte переводятся в AnsiSrting...

проще сразу выбрать нужный тип данных

> Как эти значения сложить, чтобы не было ошибок?

очень редко имеет смысл как-то складывать значения CRC,
скорее всего тебе это не надо

или я снова чего-то не понял?

Конечно.
Боюсь показаться кэпом, но тебе, вероятно, надо вычислить CRC буфера,
а не сложить CRC байтов.

> данные в массиве примерно выглядят так
> [255,255,0,1,68,54,16,34,..до..135...,0,0] 135 и 136 будет СRС.

функции вычисления CRC это безразлично

> А отправляются в канал уже вот так "яя"#1#0"какой-нибудь не читаемый символ"#A7#1D..до..135....#0#0 вот...

зачем отправлять переставленные (#1#0) нечитаемые символы вместо читаемых?

> по сути, весь пакет хранится в байтовом виде в массиве......

А не по сути - в строках?
По сути тебе достаточно, наконец, разобрать работу
любого примера вычисления CRC и отправки данных.

Удалено модератором

CRC Найти похожие ветки