Чем плох ajax чат?

Question

[Дмитрий]

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

Но кроме периодических запросов со страницы на сервер от ajax, какие еще отрицательные стороны подхода чата на ajax?
И если кто-то в курсе, что будет если несколько часов просидеть в чате на ajax и все это время будут подгружаться данные? Каждый запрос подгружает данные и через какое-то время подгрузит мегабайты данных, однако я сомневаюсь что браузеры не справятся с этим. Так чем же тогда плох чат на ajax, что все так плюются от этого метода?

Answer 1

[bromzh]

Подумай, как в случае с AJAX сервер будет отдавать сообщения.
В случае с websocket всё просто: список подключённых пользователей известен. Подключился новый пользователь, на сервере вызвался callback, соединение создалось и добавилось в список всех соединений. При получении сообщения от клиента сервер просто пройдёт в цикле по этому списку соединений, отправит данные и забудет про них. Пользователь отключился, вызвался callback, соединение удалилось из списка на сервере.

А как в случае AJAX? Сервер не знает, сколько пользователей активно в данный момент. Клиент отправил запрос, создалось соединение, запрос пришёл на сервер, сервер ответил на него, соединение разорвалось. Если юзер уйдёт с сайта, то сервер просто не будет получать запросы. Как он определит, ушёл ли юзер или просто таймаут ещё не сработал? Можно, конечно, на сервере хранить список с пользователями, которые что-то прислали и раз в N секунд выкидывать протухших. Но это дополнительная нагрузка на серв, который и так будет нагружен огромным количеством периодических запросов (выгоднее держать 1000 открытых соединений, чем раз в секунду открывать и закрывать по тысячи соединений).
Вот тебе ещё простой пример: есть 3 пользователя. Один ничего не пишет и каждые 3 секунды отправляет запрос на получение сообщений. 2 других каждые полсекунды отправляют сообщения. Сервер может только догадываться, в сети ли необщительный юзер, или у него таймаут не вышел. А до тех пор, он хранит все сообщения от 2-го и 3-го пользователей. Но они уже получили сообщения друг от друга, поэтому надо где-то хранить инфу для каждого пользователя, какие сообщения он уже получал, а какие - нет. Можно, конечно, и сообщения хранить только некоторое время, и отправлять на клиент всё, что есть, а уже на клиенте пропускать дубликаты. Но это, опять же, доп. нагрузка на сервер и клиент.

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

Comments

[Дмитрий]

Позвольте вам возразить. Из всего выше написанного вами, я как и раньше придерживаюсь что метод с ajax не выгоден по одной причине, это нагрузка на сервер. Все остальное не так сложно реализовать, хотя даже зачем, уже десятки приложений написаны. А возражение по сложной логике, ни чють не сложнее будет, чем реализовать тот же чат на WebSockets, а в некоторых случаях на порядок проще.
Но за описание спасибо. Учту эти моменты.

[bromzh]

Дмитрий: Ну это можно проверить. Вот пример простого java-класса, рассылающего сообщения. Да, ява довольно многословна, но кода там всего 5 строчек: 3 метода, в двух по 1-й строчке (добавление/удаление сессии), в одном один цикл и одно условие и отправка сообщения:

@ServerEndpoint("/ws")
class WSHandler {
    static final Set sessions = new HashSet<>();

    @OnOpen
    public void onOpen(Session session) {
        sessions.add(session);
    }

    @OnClose
    public void onClose(Session session) {
        sessions.remove(session);
    }

    @OnMessage
    public void onMessage(String message, Session session) {
        for (Session session : sessions) {
            if (!session.equals(session)) {
                session.getAsyncRemote().sendText(message);
            }
        }
    }
}

Сообщения отправляются асинхронно. Вероятность ошибки в логике нулевая, здесь и логики-то нет. Да и вообще, очень маловероятно, что что-то пойдёт не так.

Вот код на питоне + tornado. Он лаконичнее, но суть та же: добавление, удаление. цикл, условие и отправка:

class ChatWebSocket(websocket.WebSocketHandler):
    connections = set()

    def open(self):
        self.connections.add(self)

    def on_message(self, message):
        [c.write_message(message) for c in self.connections if c is not self]

    def on_close(self):
        self.connections.remove(self)

Можешь привести пример серверной части с таким же функционалом в случае AJAX? Будем считать, что в строке сообщения есть все данные: кто отправил, время, если надо, и т.д. (клиент, в моём случае, получает всегда 1 сообщение в ответе за 1 отправленное сообщение от другого пользователя).

[Дмитрий]

bromzh: на вскидку: с клиента летит запрос раз в 5 секунд с номером сообщения которое сейчас последнее. Сервер проверяет номер сообщения и возвращает все новее сообщения.
Все остальные изменения на клиенте так же могут инициировать лишний запрос и уведомить сервер что данные у клиента изменились.

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

[Илья Шатохин]

на вскидку: с клиента летит запрос раз в 5 секунд с номером сообщения которое сейчас последнее. Сервер проверяет номер сообщения и возвращает все новее сообщения.

Для этого серверу нужно для каждого чата хранить всю историю сообщений в памяти/DB и сопоставлять их на каждый ajax пинг, чтобы у клиента была актуальные данные.

[bromzh]

Ну да, менее надёжный, при этом более длинный и запутанный код (на обеих сторонах) - это мелочи.

Answer 2

[Илья Шатохин]

Чтобы иметь актуальные данные, каждому клиенту нужно постоянно делать ajax обращение к серверу для синхронизации по таймауту. Это дает дополнительную нагрузку, да и отсутствует двухсторонняя связь. Сервер не может самовольно послать пакет клиенту.

Для чата лучше использовать WebSockets.

p.s. не понял пассаж про асинхронность, ajax тоже асинхронен.

Comments

[Дмитрий]

Ну да под асинхронностью и имел в виду типа WebSockets
Хорошо, тогда это единственный минус ajax подхода? Что каждый юзер будет периодически обращаться к серверу.

[sim3x]

Дмитрий: AJAX short for asynchronous JavaScript and XML

[Дмитрий]

Можно юзать longpoll requests и тогда нагрузка станет в разы меньше

[Илья Шатохин]

Дмитрий: повторюсь - ajax не полнодуплексный канал связи. Кроме нагрузки на канал усложняется логика чата. Как определить, что клиент отвалился? Ждать на сервере, когда от него перестанут приходить ajax пинги? Или как ему срочно доставить пакет с ответом другого клиента, не дожидаясь пинга?

[Дмитрий]

Илья Шатохин: Спасибо за более широкий ответ.

Answer 3

[Adamos]

1. Нагрузка на сервер, как уже было сказано.
2. Из-за п. 1 придется выставлять значительный таймаут (несколько секунд), чат превратится в быструю переписку, а народ уже приучен аськами, скайпами и соцсетями к мгновенности чата.
3. Придется просто забыть про всякие плюшки типа "пользователь начал вам писать", к которым народ также привык.
4. ...
В результате всех подобных ограничений окажется, что, как вы ни старались, получилось барахло, несовременное и неулучшаемое. Увы.

Comments

[Дмитрий]

Во. Спасибо. Собственно какой-то такой ответ и хотелось услышать.