да ты лох

@figli Это твой единственный аргумент?

@ninesigns При том, что там XMPP же. Только модифицированный.

Лох

ssh + screen + profanity норм клиент

доведи

@ninesigns Работает, спасибо!

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

@anonymous Ага, он всгео лишь постояно дерджит соеденение с сервером. 70% трафика идет просто на проверку статуса о присутствии. Нет адекватной синхронизации между клиентами. Сейчас у боьшенства прогрессивного человечества есть по нескольку устройств и жаббер не умеет нормальную синхронизацию истории. ещё там какие то приоритеты нелепые. если у тебя на компе запущен клиент и на мобиле, сообщения будут приходить только на один из них, а не на оба сразу. А ещё жаббер плохо себя ведет в условиях нестабильной мобильной сети и сообщения могут просто затерятся по пути не дойдя до собеседника. При всем при этом он знатно так выжирает заряд ьбатареи мобильного устройства. Жаббер мало пригоден для использования на мобильниках.

@hunter_3000 > Сейчас у боьшенства прогрессивного человечества есть по нескольку устройств и жаббер не умеет нормальную синхронизацию истории XEP-ы есть, мобильные клиенты, вроде, даже их поддерживают. Некоторые серверы через плагины тоже. В общем, типикал жаббер-проблема с зоопарком. > ещё там какие то приоритеты нелепые. если у тебя на компе запущен клиент и на мобиле, сообщения будут приходить только на один из них, а не на оба сразу Вроде, от реализации сервера зависит. Некоторые, если приоритеты одинаковые, шлют всем клиентам. Та же самая "жабберпроблема". > А ещё жаббер плохо себя ведет в условиях нестабильной мобильной сети и сообщения могут просто затерятся по пути не дойдя до собеседника Скорее, проблема не протокола, т.к. там TCP, гарантирующий доставку, а реализаций конкретных серверов или клиентов. Ну ты понел. > При всем при этом он знатно так выжирает заряд ьбатареи мобильного устройства Для пушей же он как-то используется.

@etw > TCP, гарантирующий доставку че

@etw Херы не помогают, чел. Да, можно заставить подтянуть историю на один из клиентов, но не на несколько одновременно. Лишь на тот, что приоритетнее.

@etw > TCP, гарантирующий доставку Насколько мне известно, BSD сокеты не сообщают программе, случилась ли доставка, потому что send() возвращает сразу, до прихода ответного ACK или истечения retransmission timeout. Если в промежутке между фактической потерей связи и её обнаружением отправить сообщение, то отправитель не будет знать, какие байтики ушли получателю, а какие в буфер TCP стека. Всё из-за абстракции единого потока байтиков.

Сорь, для тупых, TCP гарантирует, что если есть подтверждение доставки данных, то данные точно доставлены. UDP же не может гарантировать, доставлены ли посланные данные или нет, т.к. не имеет соответствующего механизма.

Как минимум есть тупой способ, подходящий для соединений с небольним трафиком: крутим окно в 0 и получаем синхронно работающий send/recieve с уведомлением недоставке по EPIPE.

@etw yay, полезная информация на моём бнваче

@hunter_3000 > При всем при этом он знатно так выжирает заряд ьбатареи мобильного устройства. пруф

@etw Алсо, полистала ман/интернеты, есть еще способ, позволяющих не отключать окно - дополнительно следить за размером буфера отправки через ioctl SIOCOUTQ на сокет, а за статусом самого сокета - через setsockopt(,IPPROTO_IP,IP_RECVERR,,) и getsockopt(,SOL_SOCKET,SO_ERROR,,)

@etw Не надо ли будет после отправки каждого сообщения подолгу ждать, чтобы статус оставался нормальным?

Зачем? Просто шлешь данные, смотришь на размер буфера, чтобы понять, сколько дошло и конрольшт ошибки сокета, чтобы отличать обнуление буфера при доставке от обнуления буфера при разрыве.