Я создаю веб-приложение с Ruby on Rails, которое должно быть очень масштабируемым. В этом приложении данные производятся мобильным клиентом (приблизительно 20 байт) каждую секунду. Все эти данные должны быть переданы на сервер в какой-то момент, желательно как можно скорее.
Чтобы выполнить эту задачу, я хочу, чтобы сервер работал как служба RESTful. Клиент может буферизовать места (скажем, каждые 5-30 секунд), а затем снимать их как запрос HTTP-запроса, где сервер может их сохранить. Я считаю, что эта модель проще реализовать и лучше обрабатывает большой объем трафика, так как клиенты могут сохранять данные буферизации, пока не услышат ответ от сервера.
Мой босс, с другой стороны, хочет реализовать сервер, используя программирование сокетов. Он считает, что программирование сокетов приведет к уменьшению количества передаваемых данных, что увеличит общую эффективность системы. Я не могу не согласиться на этот вопрос, но я думаю, что с учетом современной пропускной способности дополнительные накладные расходы с HTTP стоит того. Плюс, я думаю, что попытка поддерживать тысячи (или миллионы) одновременных подключений к пользователям приведет к собственным проблемам и значительно увеличит сложность сервера.
Честно говоря, я не знаю правильного подхода к этой проблеме, поэтому я подумал, что отправлю его здесь и получу мнение более умных людей, чем я. Я был бы признателен, если бы в ответ были включены плюсы и минусы предлагаемого решения.
Спасибо.
Обновление
Теперь у нас появилось несколько дополнительных требований. Во-первых, мобильный клиент не может загружать более 5 ГБ данных в месяц. В этом случае мы говорим одно сообщение в секунду по восемь часов в день в месяц. Во-вторых, мы хотим как можно меньше сочетать сообщения. Это делается для того, чтобы что-то случилось с мобильным клиентом (скажем, с автокатастрофой), мы теряем как можно меньше данных.