Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Разборка FLAP пакетов.

_stdcall © (2006-10-21 21:37:00)
В целях самообразования решил разобраться с ICQ протоколом.
Сейчас размышляю над хорошим алгоритмом разбора входящих пакетов.
Итак, весь смыс заключается в том, что начало каждого пакета представляет собой 6 байтовый FLAP заголовок, который помимо прочих данных содержит длину всего пакета (без учета заголовка).
2A - Byte, FLAP id byte xx - Byte, FLAP channel xx xx - Word, FLAP datagram seq number xx xx - Word, FLAP data size TFlapHdr = record Ident: Byte; ChID: Byte; Seq: Word; DataLen: Word; end;
В качестве сокета решил использовать сокет из ICS (TWSocket). Вот теперь и думаю, как лучше осуществить алгоритм разбора.
Т.е. ведь в сокет может как и не прийдти полного пакета, как и прийти несколько сразу. Или вообще теоретически даже первые шесть байт могут прийдти по одному байту. Я конечно немного представляю процесс с буфером, и завтра самостоятельно собираюсь этим заняться; Но хотелось бы услышать мнения, может кто-то уже подобным занимался? Что порекомендуете?

seeker (2006-10-23 17:15:00) [1]
в крысе все сделано предельно просто.
1.Все принимаемые данные добавляются в конец строки.
2.Анализируется строка, и если есть полный пакет - он удаляется из строки, обрабатывается и так пока длина строки не станет меньше DataLen+6 (подразумевается что после обработки пакета первым символом строки будет 2A, 2 - номер канала, 3,4 - Seq, 5,6 - длинна пакета...).
Надеюсь понятно объяснил...

Ketmar (2006-10-22 11:32:00) [2]
>[8] _stdcall 22-Oct-2006, 11:23
>А чего с оскаром не так?
да ничего. просто черезчур много "наворотов" на пустом месте. имо.

_stdcall (2006-10-22 11:23:00) [3]
Спасибо!

> зыж OSCAR -- не лучший протокол для "разборок".

А чего с оскаром не так?

Ketmar (2006-10-22 11:18:00) [4]
лично я в 99% случаев использую именно блокирующие. потому что мне так удобней. давно уже наваял свою "обёртку" над WinSock API, ней и пользуюсь. а вообще -- особой разницы нет. в твоём случае, полагаю, блокирующие будут удобней. главное -- не забывать, что если данных нет, то их будут ожидать, и всё на это время "замрёт". так что лучше в отдельный поток утащить.

а посоветую -- [5]. сделать функцию типа ReadBytes (...; count: Integer): Boolean;. которая прочитает ровно count байт и вернёт true, или пофиг сколько и false при ошибке. дальше уже плясать от неё.

зыж OSCAR -- не лучший протокол для "разборок".

_stdcall (2006-10-22 11:13:00) [5]
Хмм.. а что лучше то?, блокирующие? Лично мне не хочется использовать блокирующие.
И что тогда порекомендуете с общим буфером? Я просто не соображу никак с хорошим алгоритмом, голова что-то не соображает.

Ketmar (2006-10-22 10:41:00) [6]
а блокирующие сокеты тут помогут так: делаем процедуру, которая читает ровно столько, сколько надо (вызывая recv() несколько раз при необходимости). и всё. потом спокойно читаем этой процедурой -- как из простого файла.

_stdcall (2006-10-22 10:11:00) [7]
Да, ... теперь я понимаю что ничего не понимаю. А какая разница в данном случае блокирующие или нет? В WSocket на соедиенение возбуждается OnConne... На прием данных OnDataAviable, в лубом случае без центрального буфера не обойтись куда будут скидываться не полные пакеты, которые ещё полностью не пришли?

Орион (2006-10-22 09:40:00) [8]
Или блокирующие сокеты или "Я конечно немного представляю процесс с буфером...".

Ketmar (2006-10-22 01:30:00) [9]
read about automates.

Ketmar (2006-10-22 01:30:00) [10]
finite state automates, etc.

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »