Дневник разработки ICQ сервиса. Часть I
Как вы можете помнить, год назад я патчила Adium для работы с IServerD, и там упомянула, что желаю написать свою реализацию, так вот...
Подруга меня смотивировала всё-таки взяться за то, что нравится, что дало свои плоды, и за что я ей благодарна ❤️
За неделю реализовала Login Sequence OSCAR протокола, реализовала сессионное хранилище, написала удобные воркеры для обработки TCP запросов, очереди обработки client << server FLAP пакетов,
Реализовала локальный регистр сессий, после чего он будет с определённого момента отражаться в какое-нибудь KV хранилище для возможности доставки данных в многоинстансной среде.


Все онлайн)
К сожалению пока не было желания разбираться с тем, почему отвечает QIP 2005, потом может разберусь, но 2010 хотя бы отвечал, но как оказалось он не особо и по спеке работает, поскольку ничего не пишет пока ты ему какой-нибудь hello package не кинешь.
А сегодня почти всю ночь не могла заснуть, заодно продумывая решения.
Архитектурные решения по инфраструктуре решила немного отложить до момента написания core сервисов, а пока продолжаю реализовывать OSCAR в минимально необходимом для функционирования виде, в частности реализация Login Sequence, доставки и получения сообщений, добавление контактов и изменение статусов.
Для контактов структурку описала, но сам список контактов пока замокала пустым массивом.
Особо «радостно» стало когда я поняла, что клиенты шлют UIN до перехода на BOS сервер, а после уже не присылают, а он мне необходим для привязки к сессии, но я не отчаилась и придумала как выкрутиться: promotion!
Придумала механизм «повышения» сессии с временной локальной с соответствующим session id до готовой к функционированию и отображению в БД, а сам UIN я решила сохранять в куку ещё на этапе SubType AUTH_REG_LOGIN_REQUEST (Family: 0x0017, subType: 0x0002), после чего когда клиент приходит на BOS сервер, он уже имеет ту самую куку и отдаёт её нам, на основании которой мы проводим миграцию новой, временной сессии на полнофункциональную 😊

Механизм повышения и миграции сессии в целом будет не нужен после разделения сервисов на AUTH и BOS, в первом в целом логика сессий и очередей не нужна, а на втором будем сразу создавать полнофункциональную сессию при получении куки!
На этом пока всё, будем доводить проект до рабочего прототипа, думаю много чего ещё будет что рассказать 😁
Шикарная спека по протоколу, которой пользуюсь: https://sobek.hsdn.org/Docs/oscar/OSCAR%20ICQ%20v7v8v9%20protocol%20documentation/index.html
А также хорошо дополняет спеку изучение исходников libpurple