Программирование сокетов против веб-службы?

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

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

Если вам нужна дополнительная информация, просто скажите мне, прежде чем голосовать, вопрос или закрыть!

Ответ 1

Веб-сервисы, как правило, "легче", благодаря огромному интересу к ним и поддержке их в инструментах разработчика, а также через библиотеки и структуры.

Однако, особенно если ваша полезная нагрузка небольшая (думаю, что сообщения имеют размер типичного SMS или твита), накладные расходы, которые вы создаете с помощью веб-сервисов, являются запретительными: байты, отправленные по беспроводной сети, такой как GPRS или UMTS, по-прежнему очень дороги, по сравнению с байты, переносимые кабелем или ADSL. И веб-службы несут несколько слоев невидимой информации вокруг того, что конечный клиент также должен будет заплатить.

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

Если посмотреть на сокеты, посмотрите также на UDP: если вы можете жить с тем, что в основном вы бросаете кому-то пакет и не разрабатываете какой-либо механизм ack в свой протокол, вы никогда не будете уверены, что сообщение пришло, оно очень эффективный, потому что нет никакого трафика для создания и обслуживания соединения, и даже довольно длинные сообщения могут быть очень хорошо транспортированы внутри 1 пакета UDP.

EDIT на основе комментария:

stream socket: не уверен, как вы определяете потоки, но потоки и сообщения - две очень разные концепции для меня, поток - это, как правило, более длинная последовательность отправленных данных, тогда как сообщение - это объект, который отправил и, возможно, подтвердил или ответил получатель. Моделирование пропускной способности
: самый простой способ понять, о чем я говорю, - это получить Wireshark и добавить все, что транспортируется по сети, чтобы сделать простой запрос очень короткой строки - вы увидите несколько уровней административной информации (т.е. невидимый, чтобы там работали разные уровни протокола), которые являются всем трафиком, оплачиваемым конечным пользователем. Затем напишите небольшую макетную службу с использованием UDP для переноса одного и того же сообщения или используйте инструмент, например netcat, хороший учебник здесь, и добавьте байты, которые будут транспортироваться. Вы увидите довольно большие различия в количестве обмениваемых байтов.

EDIT2, я забыл упомянуть: мобильные сети были открытыми, прозрачными сетями с устройствами, идентифицированными публичными IP-адресами. Там происходит стремительная эволюция в отношении мобильных сетей NAT, которые влияют на то, как устройства внутри и снаружи этого "огороженного сада" могут общаться (NAT traversal). Это необходимо учитывать при разработке вашего канала связи.

Что касается использования потоков для приложения чата: он предлагает некоторые концептуальные преимущества, но вы можете очень хорошо сложить приложение чата поверх UDP, посмотрите здесь или здесь