Ответ 1
Веб-сервисы, как правило, "легче", благодаря огромному интересу к ним и поддержке их в инструментах разработчика, а также через библиотеки и структуры.
Однако, особенно если ваша полезная нагрузка небольшая (думаю, что сообщения имеют размер типичного SMS или твита), накладные расходы, которые вы создаете с помощью веб-сервисов, являются запретительными: байты, отправленные по беспроводной сети, такой как GPRS или UMTS, по-прежнему очень дороги, по сравнению с байты, переносимые кабелем или ADSL. И веб-службы несут несколько слоев невидимой информации вокруг того, что конечный клиент также должен будет заплатить.
Итак, если ваш случай использования основан на коротких сообщениях, я бы хотя бы советовал сделать некоторые расчеты симуляции пропускной способности и основывать ваше решение на экономии пропускной способности и повышенной сложности вашего приложения.
Если посмотреть на сокеты, посмотрите также на UDP: если вы можете жить с тем, что в основном вы бросаете кому-то пакет и не разрабатываете какой-либо механизм ack в свой протокол, вы никогда не будете уверены, что сообщение пришло, оно очень эффективный, потому что нет никакого трафика для создания и обслуживания соединения, и даже довольно длинные сообщения могут быть очень хорошо транспортированы внутри 1 пакета UDP.
EDIT на основе комментария:
- stream socket: не уверен, как вы определяете потоки, но потоки и сообщения - две очень разные концепции для меня, поток - это, как правило, более длинная последовательность отправленных данных, тогда как сообщение - это объект, который отправил и, возможно, подтвердил или ответил получатель. Моделирование пропускной способности
- : самый простой способ понять, о чем я говорю, - это получить Wireshark и добавить все, что транспортируется по сети, чтобы сделать простой запрос очень короткой строки - вы увидите несколько уровней административной информации (т.е. невидимый, чтобы там работали разные уровни протокола), которые являются всем трафиком, оплачиваемым конечным пользователем. Затем напишите небольшую макетную службу с использованием UDP для переноса одного и того же сообщения или используйте инструмент, например netcat, хороший учебник здесь, и добавьте байты, которые будут транспортироваться. Вы увидите довольно большие различия в количестве обмениваемых байтов.
EDIT2, я забыл упомянуть: мобильные сети были открытыми, прозрачными сетями с устройствами, идентифицированными публичными IP-адресами. Там происходит стремительная эволюция в отношении мобильных сетей NAT, которые влияют на то, как устройства внутри и снаружи этого "огороженного сада" могут общаться (NAT traversal). Это необходимо учитывать при разработке вашего канала связи.
Что касается использования потоков для приложения чата: он предлагает некоторые концептуальные преимущества, но вы можете очень хорошо сложить приложение чата поверх UDP, посмотрите здесь или здесь