1)распознавать FLAP, SNAC, TLV в потоке данных из сети и соответствующим образом обрабатывать их

2)составлять соответсвующие пакеты и отправлять их

3)распознает основные типы SNAC

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

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

1)малое количество известных SNAC

2)в некоторых случаях были замечены проблемы со скачиванием контакт-листа. скорее всего, проблема была в недостаточном к-ве памяти

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

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

5)нет средств для конфигурации, UIN и пароль можно изменить только перекомпилировав.

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

Недоработка состоит в следующем. Если сервер посылает нам на сокет меньше 256 байт, то мы их "видим"(vStreamReady!=0) и можем спокойно прочитать. При этом читаются все данные, как и должно быть. Если же сервер посылает нам 256 байт или больше то, мы можем прочесть только перве 255 из них, остальные же мы не видим(vStreamReady==0), а если и проигнорировать это, тупо пытаясь считать остальные, то мы получаем ошибку.

Но, что самое интересное, когда на сокет придут ещё данные, хотя бы 1 байт, мы сможем прочитать все до конца.

Проблема состоит как раз в том, что дождаться этого байта не всегда удается. Возьмем например ответ логин сервера на наше подключение: он содержит адрес BOS сервера и ещё cookie, в сумме получается 300 байт. После этого логин-сервер нам ничего не посылает и посылать не должен. Естественно, что на этом месте программа блокируется, т.к. ждет оставшиеся 45 байт. Очевидно, что никакие keep-alive пакеты здесь не спасут - проблемы начинаются ещё на стадии аутенификации.

Если не считать надежды на исправление реализации сокетов в телефоне разработчиками, то единственное решение - искуственное разбиение данные на пакеты по 200-255 байт. Протокол ICQ такого не предусматривает, поэтому наиболее простым решением, на мой взгляд, является использование промежуточного прокси-сервера, работающего про принципу: получил данные от сервера-отправил клиенту-дождался подтверждения от клиента-и т.д. Подтверждение необходимо, дабы не пришло 2 подряд пакета по 200 байт, тогда опять всплывет описанная выше проблема. Я не скажу, что сложно написать такой сервер, но идея создания промежуточного сервера не очень хороша, т.к. его как-то, где-то и кому-то нужно будет поддерживать.

В общем-то в данном случае прокси чем-то похож на sock4. От него в нашем случае требуется слудующее:

• Принять входящее подключение от моб.клиента, получить от него адрес и порт ICQ-сервера, а также, возможно, некие username и password, если придется ограничивать доступ
• По этому адресу и порту окрыть подключение
• Все данные, которые приходят от ICQ-сервера скидываем в буфер, а затем отправляем кусками, каждый не больше, допустим, 200 байт. При этом после отправки каждого куска ждем подтверждения от клиента, о том, что они пришли.
• Все данные, которые приходят от клиента, можно сразу отправлять, при этом уже сами отправляем клиенту подтверждение, которого он должен дождаться.
• Т.к. прямо так все эти данные передавать по сети не получится, необходимо придумать какой-то контейнер для данных. Например такой:

  byte	content
  1	всегда 255, дабы контролировать: ботву мы получили и пора отключиться, или не ботву и можно читать дальше
  2	тип. например:информация о сервере,ошибка,данные,подтверждение.
  3-4	размер последующего куска, чтобы знать, сколько данных нужно считать
  последующие байты	данные

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

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