фигли, буду писать аццкую эппопею как я писал асю, мухехе... для начала пожалуй пару скринов того, что уже готово и немного общих идей)

итаг, немножко идей и основных принципов.

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

идея вторая - всё должно работать.

идея третья - всё должно быть удобно, по крайней мере для миня)

идея следующая - всё должно быть по возможности красивым...

^ бизусловно некоторый идеи могут быть реализованы ни так как задумывалось, но на первый раз любой результат будит атличным) ^

...вот...

это конечно не всё.) на первой скрине - окно с контактами. на второй прелоад.(вся его фишка в том - что он прозрачный, неправильной формы и с тинями, в общем выпендрёж чистой воды)



ГЛАВА ОДИН НАХ)

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

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

для обмена сообщениями и клиент и сервер используют так называемые FLAP(это даже как-то расшифровывается оО) пакеты. флап пакет содержит заголовок и некие данные, которые всвою очередь представлены в виде TLV или SNAK структур.(при этом в FLAP пакете будут либо только снаки либо только тлв. причОм флапы с тлв используются только при общении с сервом авторизации и для пересылки кукисов. кроме того снак может содержать в себе тлв структуры).

достаточно важным является факт нумерации пакетов. вначале и серв и клиент произвольным образом выбирают номер первому пакету. но все последующие пакеты со стороны клиента должны нумероваться последовательно(то же самое касается и сервера) если же следом за пакетом с номером 1A 25 мы отправим пакет 1А 27, то серв будет ждать пакет с номером 1А 26 и напроч игнорировать все наши поползновения.

пока хватит)

вторая идея очень и очень привлекательна )

Глава два про флапы снаки и тлв)

вся инфа, которой обмениваются сервак и клиент передаётся в флап пакетах.
флап пакет состоит из заголовка и данных.

флап заголовок

 2A	 	byte	 	FLAP id byte                                  флап id
 xx	 	byte	 	FLAP channel                                 канал
 xx xx	 	word	 	FLAP datagram seq number         хитрый номер
 xx xx	 	word	 	FLAP data size                               размер данных

флап данные

 ......	                    FLAP data         собственно данные

флап id - всегда имеет одно и тоже значени - 2А.

канал - всиго существует 5 каналов. первый(01) - для логина, по нему общается логин серв. второй(02) - для передаи данных со снаками!!!. третий(03) - канал ошибок. четвёртый(04) - закртие соеденения (логаут) и пятый(05) фиг знает для чего)

хитрый номер - номер пакета. сервер и клиент нумируют пакеты независимо друг от друга. единственное правило - пакеты нумеруются последовательно. (собственно по номеру серв  клиент могут узнать все ли пакеты до них дошли или нет)

данные - данные могут бть представлены двумя спосабами - снак или тлв структуры. при этом в одном флап пакете может быть либо один снак, либо несколько тлв.

тлв структура, как и флап, делится на заголовок и данные

xx xx	 	word	 	TLV type number                          тип тлв
xx xx	 	word	 	TLV length value                           размер данных


 ......            	TLV data                  данные          

                         

в принципе здесь всё очень просто и понятно. тип тлв определяет тип данных(как то уин, пароль, и тд)

и снак структура

xx xx	 	word	 	Family (service) id number            id семейства
xx xx	 	word	 	Family subtype id number              внутренний id
xx xx	 	word	 	SNAC flags                                   флаги
xx xx xx xx	dword	 	SNAC request id                           id запроса


 ......	           SNAC data                 данные

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

оО Глава три про логин сервер, в которой всё просто и легко...

итаг, любой клиент перво наперво коннектится к логин серваку.

dorido написал(а):

итаг, любой клиент перво наперво коннектится к логин серваку.

хуйасе, логично %)))

Глава четыре, которая на самом деле глава три.

Итаг(какое замечательное слово)). Вначале клиент рубится к логин серваку примерно так:

ws.connect icq.hostel.nstu.ru:5190

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

затем с сервера нам приходит сообщение примерно такого вида:

2A 01 10 2С 00 00 00 01

, где 10 2С - это FLAP datagram seq number, для простоты повествования были взяты именно эти цифры, хотя реально прийти можт что угодно(важно помнить что только номер первого флапа выбирается произвольно, все остальные получаются инкрементом последнего отправленного(или полученного, если это пакеты с сервака))

так вот, увидев в флап данных строку 00 00 00 01, клиент понимает, что сервер готов его слушать и можно приступить непоспредственно к авторизаци.

(опять таки для простоты дальнейшего повествования определим три класса -  flap, snak и tlv)

class FLAP

byte chnl;
word seqnum;
word dsize;
byte *data;

FLAP::boolean read(byte *inpdata);
FLAP::boolean create(byte ch, word nm);
FLAP::boolean app_data(byte *appdata);

end class


class SNACK

word familyid;
word subipeid;
word flags;
dword recid;
byte *data;

SNACK::boolean read(byte *inpdata);
SNACK::boolean create(word fm, word st, word fl, dword rc);
SNACK::boolean app_data(byte *appdata);

end class

class TLV

word type;
word dsize;

TLV::boolean read(byte *inpdata);
TLV::boolean create(word tp, byte *appdata);

end class

честно говоря, я не знаю нафига были добавлен функции чтения, ибо пока что всё входящее будет разбиваться на адекватные для восприятия куски без каких либо каментов в виде кода, но может быть потом и понадобится)

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

 00 00 00 01	dword	protocol version number

 00 01	 	word	 	TLV.Type(0x01) - screen name (uin)
 xx xx	 	word	 	TLV.Length
 xx ..	 	string	 	Screen name (uin)

 00 02	 	word	 	TLV.Type(0x02) - roasted password
 xx xx	 	word	 	TLV.Length
 xx ..	 	array	 	roasted password array

 00 03	 	word	 	TLV.Type(0x03) - client id string
 xx xx	 	word	 	TLV.Length
 xx ..	 	string	 	Client id string (name, version)

 00 16	 	word	 	TLV.Type(0x16) - client id
 00 02	 	word	 	TLV.Length
 xx xx	 	word	 	Client id number

 00 17	 	word	 	TLV.Type(0x17) - client major version
 00 02	 	word	 	TLV.Length
 xx xx	 	word	 	Client major version

 00 18	 	word	 	TLV.Type(0x18) - client minor version
 00 02	 	word	 	TLV.Length
 xx xx	 	word	 	Client minor version

 00 19	 	word	 	TLV.Type(0x19) - client lesser version
 00 02	 	word	 	TLV.Length
 xx xx	 	word	 	Client lesser version

 00 1A	 	word	 	TLV.Type(0x1A) - client build number
 00 02	 	word	 	TLV.Length
 xx xx	 	word	 	Client build number

 00 14	 	word	 	TLV.Type(0x14) - distribution number
 00 04	 	word	 	TLV.Length
 xx xx xx xx	 	dword	 	Distribution number

 00 0F	 	word	 	TLV.Type(0x0F) - client language (2 symbols)
 xx xx	 	word	 	TLV.Length
 xx ..	 	string	 	Client language

 00 0E	 	word	 	TLV.Type(0x0E) - client country (2 symbols)
 xx xx	 	word	 	TLV.Length
 xx ..	 	string	 	Client country

объявляем и создаём флап, который хотим послать

FLAP oflap;
SNAK s;
TLV t;

01:    oflap.create 1, 2000 
02:    oflap.app_data cnvHex("00 00 00 01")
03:    oflap.app_data t.create(1, "131313")
04:    oflap.app_data t.create(2, Calc_Pass("password"))
05:    oflap.app_data t.create(3, "ICQ  Inc. - Product of ICQ (TM).2001b.5.18.1.3659.85")
06:    oflap.app_data t.create(22, cnvHex("01 0A"))
07:    oflap.app_data t.create(23, cnvHex("00 14")) 
08:    oflap.app_data t.create(24, cnvHex("00 34")) 
09:    oflap.app_data t.create(25, cnvHex("00 00")) 
10:    oflap.app_data t.create(26, cnvHex("0B B8"))
11:    oflap.app_data t.create(20, cnvHex("00 00 04 3D")) 
12:    oflap.app_data t.create(15, "en")
13:    oflap.app_data t.create(14, "us")

ws.send oflap

01: создаём флап с каналом 01(канал логина) и seq номером 2000.
02: добавляем строку 00 00 00 01, по которой серв поймёт, что мы начале авторизацию. (функция cnvHex() кнвертировала строку(string) в хекс код.)
03: добавляем тлв с номером 00 01 - тлв , содержащий уин.
04: тлв 00 02, содержит пароль. пароль передаётся MD5 хешем.
05: тлв 00 03 - id строка клиента. по этой строке другие клиенты смогут опознать нас)
06: тлв 00 16 - id клиента, опять таки для идентификации
далее идёт информация о версии клиента и языках.

если мы всё собрали правильно и пароль с уином подошли, то сервер пришлёт нам флап, data которого будет иметь вид:

00 01	 	word	 	TLV.Type(0x01) - screen name (uin)
 xx xx	 	word	 	TLV.Length
 xx ..	 	string	 	Screen name (uin)

 00 05	 	word	 	TLV.Type(0x05) - BOS server address
 xx xx	 	word	 	TLV.Length
 xx ..	 	string	 	BOS server address string

 00 06	 	word	 	TLV.Type(0x06) - authorization cookie
 xx xx	 	word	 	TLV.Length
 xx ..	 	array	 	authorization cookie

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

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

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

как оказалось, авторизация на логин серваке - самое простое, из того, что нужно реализовать. в итоге всех наших стараний, логин сервак даст нам куки и пошлёт по адресу, который тоже даст.

теперь коннектимся к нормальному серву, и он нам присылает сообщение, что готов(опять таки его любимое 2А 00 00 00 01, а может и нет, я уже не помню)) и мы должны ему ответить чем можем, а можем мы собственно говоря, только уином и кукисами, коих у нас ну просто завались...)

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

авторизация на нормальном серваке вглядит примерно так: (тут я решилд пойти спать, так что продолжение позже.))