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

← →
_stdcall (2006-10-21 21:37) [0]

В целях самообразования решил разобраться с 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). Вот теперь и думаю, как лучше осуществить алгоритм разбора.
Т.е. ведь в сокет может как и не прийдти полного пакета, как и прийти несколько сразу. Или вообще теоретически даже первые шесть байт могут прийдти по одному байту. Я конечно немного представляю процесс с буфером, и завтра самостоятельно собираюсь этим заняться; Но хотелось бы услышать мнения, может кто-то уже подобным занимался? Что порекомендуете?

← →
Ketmar © (2006-10-22 01:30) [1]

read about automates.

← →
Ketmar © (2006-10-22 01:30) [2]

finite state automates, etc.

← →
Орион © (2006-10-22 09:40) [3]

Или блокирующие сокеты или "Я конечно немного представляю процесс с буфером...".

← →
_stdcall (2006-10-22 10:11) [4]

Да, ... теперь я понимаю что ничего не понимаю. А какая разница в данном случае блокирующие или нет? В WSocket на соедиенение возбуждается OnConne... На прием данных OnDataAviable, в лубом случае без центрального буфера не обойтись куда будут скидываться не полные пакеты, которые ещё полностью не пришли?

← →
Ketmar © (2006-10-22 10:41) [5]

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

← →
_stdcall (2006-10-22 11:13) [6]

Хмм.. а что лучше то?, блокирующие? Лично мне не хочется использовать блокирующие.
И что тогда порекомендуете с общим буфером? Я просто не соображу никак с хорошим алгоритмом, голова что-то не соображает.

← →
Ketmar © (2006-10-22 11:18) [7]

лично я в 99% случаев использую именно блокирующие. потому что мне так удобней. давно уже наваял свою "обёртку" над WinSock API, ней и пользуюсь. а вообще -- особой разницы нет. в твоём случае, полагаю, блокирующие будут удобней. главное -- не забывать, что если данных нет, то их будут ожидать, и всё на это время "замрёт". так что лучше в отдельный поток утащить.

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

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

← →
_stdcall (2006-10-22 11:23) [8]

Спасибо!

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

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

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

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

Разборка FLAP пакетов. Найти похожие ветки