Comments 13
1. Что по факту произойдет у игроков при превышении лимита на базовом тарифе? Сообщения нельзя будет отправлять?
2. В каком виде вы предоставляете JavaScript-клиент? Это серия запросов для REST API или набор из скриптов и верстки? Возможно ли их кастомизировать?
3. У вас есть какие-либо механизмы шифрования / защиты переписки?
2. В каком виде вы предоставляете JavaScript-клиент? Это серия запросов для REST API или набор из скриптов и верстки? Возможно ли их кастомизировать?
3. У вас есть какие-либо механизмы шифрования / защиты переписки?
1. При превышении лимита придет алерт с предложением перейти на платный тариф, через несколько дней будет заблокирована отправка сообщений
2. По факту это набор скриптов без верстки, включая библиотеку web sockets. А как и для чего хотелось бы их кастомизировать?
3. Пока таких механизмов нет, но идея хорошая — подумаем над реализацией.
2. По факту это набор скриптов без верстки, включая библиотеку web sockets. А как и для чего хотелось бы их кастомизировать?
3. Пока таких механизмов нет, но идея хорошая — подумаем над реализацией.
Недавно искал подобный сервис, не нашёл.
Напишу свои требования, вдруг кому будет интересно.
1) Реально низкий порог вхождения. В идеале Init(appKey), Subscribe(channel) и колбэк OnMessage(channel, message). Все остальные навороты, в том числе и авторизацию, сделать опциональными.
2) Надёжность клиентской библиотеки. К примеру, отправляемые сообщения не должны теряться при дисконнекте или нормальном выключении приложения. Наличие SDK для мобильных платформ (iOS, Android, Win8).
3) Возможность задавать максимальное время хранения на сервере для отдельных сообщений. При TTL = 0 сообщения получают только те, кто онлайн в данный момент. Это нужно хотя бы для пингов и подобных сообщений.
Напишу свои требования, вдруг кому будет интересно.
1) Реально низкий порог вхождения. В идеале Init(appKey), Subscribe(channel) и колбэк OnMessage(channel, message). Все остальные навороты, в том числе и авторизацию, сделать опциональными.
2) Надёжность клиентской библиотеки. К примеру, отправляемые сообщения не должны теряться при дисконнекте или нормальном выключении приложения. Наличие SDK для мобильных платформ (iOS, Android, Win8).
3) Возможность задавать максимальное время хранения на сервере для отдельных сообщений. При TTL = 0 сообщения получают только те, кто онлайн в данный момент. Это нужно хотя бы для пингов и подобных сообщений.
Хм, если я правильно вас понял, то pusher.com и pubnub.com как раз для этого и существуют. Вписываешь appKey, подписываешся на канал и ждешь сообщений.
Конечно там нет протокола обмена изображениями, эмоций и т.д., но это не сложно делается и получается более гибко, когда сервис передает лишь сообщения (можно сделать свой простой протокол, например, на основе JSON).
Оба сервиса поддерживают WebSocket, online-статусы (кто в сети на канале). На канал может подписатся как 1 человек (приватная комната), так и много (групповой чат).
В общем то они заявляют, что их сервисы подходят не только для чатов и приложений в реальном времени, но даже для мультиплеерных игр.
Конечно там нет протокола обмена изображениями, эмоций и т.д., но это не сложно делается и получается более гибко, когда сервис передает лишь сообщения (можно сделать свой простой протокол, например, на основе JSON).
Оба сервиса поддерживают WebSocket, online-статусы (кто в сети на канале). На канал может подписатся как 1 человек (приватная комната), так и много (групповой чат).
В общем то они заявляют, что их сервисы подходят не только для чатов и приложений в реальном времени, но даже для мультиплеерных игр.
Если я не путаю, то оба этих сервиса не хранят сообщения на сервере для оффлайновых пользователей. Вы можете отправить сообщение в «канал», и его получат те, кто онлайн, но те, кто оффлайн это сообщение не получат.
Там также есть возможность хранить историю сообщений — вновь подключившиеся юзеры могут посмотреть, что они «пропустили», но это всё не то, да и ненадёжно.
Есть сервисы другого плана — например, Amazon SQS — хранят сообщения до тех пор, пока их кто-нибудь не получит, но там нет возможности отправлять сообщения только онлайн пользователям (ping).
Там также есть возможность хранить историю сообщений — вновь подключившиеся юзеры могут посмотреть, что они «пропустили», но это всё не то, да и ненадёжно.
Есть сервисы другого плана — например, Amazon SQS — хранят сообщения до тех пор, пока их кто-нибудь не получит, но там нет возможности отправлять сообщения только онлайн пользователям (ping).
Спасибо за отклик! Мы как раз стараемся сделать SDK максимально простым для интеграции — оно примерно так и выглядит, как вы описали. В ближайшее время опубликуем документацию на сайте cloud.salut.im
По поводу введения TTL — будем делать обязательно, у разных приложения свои требования к обеспечению отложенной доставки.
По поводу введения TTL — будем делать обязательно, у разных приложения свои требования к обеспечению отложенной доставки.
Сервис нужный, но пока нет хотябы примерных тарифов и документации, что-либо сказать сложно.
Для своего проекта ищу что-то похожее, пока не нашёл.
Для своего проекта ищу что-то похожее, пока не нашёл.
По тарифам: будет бесплатный базовый тариф для отладки и релиза приложений с небольшой аудиторией с лимитом по количество одновременных соединений. При его превышении будет предлагаться переход на платный тарифный план с минимальной стоимостью от $100-$150 в месяц.
Документацию мы опубликуем в ближайшее время на нашем сайте — cloud.salut.im
Документацию мы опубликуем в ближайшее время на нашем сайте — cloud.salut.im
Скажите пожалуйста, чем ваш сервис, помимо протокола, отличается от известных решений pusher.com и pubnub.com?
Мы предоставляем готовое решение для встройки пользовательского чата, в то время как эти два сервиса скорее дают решения для транспорта событий на прикладном уровне, поверх которого надо будет строить свой чат. В этом плане наше решение, хоть и более узкое фукнционально, но за счет этого же и проще.
Кроме этого, могу ошибаться, но не уверен, что у них обоих есть возможности по передаче кастомного контента, включая аудио и видео.
Кроме этого, могу ошибаться, но не уверен, что у них обоих есть возможности по передаче кастомного контента, включая аудио и видео.
Расскажите, если возможно, как у вас технически организованы аудиочаты / видеочаты? Аудио/видео поток передается p2p или через ваш сервер? Сколько человек может одновременно участвовать в видео чате?
Sign up to leave a comment.
Облачная платформа для чатов в мобильных приложениях