Какой протокол связи вы бы порекомендовали? - PullRequest
1 голос
/ 22 июля 2010

Я собираюсь разработать клиентское приложение, и серверная часть тоже не предназначена.

Мне нужно определиться с протоколом связи.

Требования:

  • быстро, компактно
  • поддерживает передачу двоичных файлов в обе стороны
  • сервер, вероятно, PHP, клиент .NET

Пока я рассмотрел это:

  • пользовательский XML через HTTP - я делал это в прошлом, но он не очень подходит для передачи файлов, в противном случае ОК
  • SOAP - нет опыта, я читаю, это очень многословно и сложно
  • Google protobuf - прочитайте много хорошего об этом
  • чистый HTTP - используя get и post - это может быть плохо расширяемым.

Я открыт для предложений. Пока я склоняюсь к протобуфу.

Редактировать: Подробнее

  • Сервер будет иметь большой объем данных, тонкий прикладной уровень, возможно, только саму базу данных. Миллионы на миллиард записей, интенсивный поиск (полнотекстовый и пользовательский поиск).
  • Ожидаемое число клиентских приложений в больших количествах, но может возрасти
  • 2 типа сообщений от сервера к клиенту, небольшие (до 100 КБ), но очень распространенные, большие (загрузка файлов, до 10 МБ приблизительно)
  • клиент отправляет обратно только сообщения меньшего размера, но с дополнительной информацией.
  • Я бы хотел структурировать информацию, чтобы мета-информация предоставлялась обоими способами.
  • я бы хотел, чтобы его можно было расширить для будущих изменений
  • Шифрование обязательно (с учетом https в качестве транспортного уровня)
  • Lantency очень важен, я хотел бы добиться «стандартных» задержек в сети (меньше 200 мс), для небольших сообщений. Это действительно зависит от многих вещей.

Ответы [ 6 ]

0 голосов
/ 24 июля 2010

Я бы не использовал HTTP для одного из ваших общих типов сообщений, «большого» (но <10 МБ) двоичного файла, который может оказаться слишком медленным для ваших приложений. Но тестирование покажет, что все, что основано на HTTP, приемлемо для ваших случаев использования. Поэтому, возможно, используйте FTP для больших двоичных сообщений и что угодно еще для маленьких сообщений. Да, я рекомендую использовать здесь два типа протоколов связи. </p>

0 голосов
/ 22 июля 2010

Я бы также рекомендовал буферы протокола через TCP.HTTP следует избегать, если вы не используете абстракцию более высокого уровня, которая неявно использует HTTP.

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

Я написал несколько рекомендаций по разработке протокола в моих .NET TCP / IP FAQ , включая XML по TCP / IP (я согласен, что XML не являетсяхорошо подходит для ваших нужд).

0 голосов
/ 22 июля 2010

Я думаю, что Protocol Buffers звучит как отличный выбор. Это почти то, для чего оно было разработано.

Порт .NET записывается не кем иным, как Джоном Скитом:

http://code.google.com/p/protobuf-csharp-port/

Я не уверен, насколько велика поддержка в PHP. Это может быть проблемой.

0 голосов
/ 22 июля 2010

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

Я хотел добавить этов качестве комментария, но я не могу это сделать.

0 голосов
/ 22 июля 2010

Хорошо, буферы протокола, безусловно, хорошо работают для нас:)

Хотя вы можете захотеть наложить их поверх HTTP.Очевидно, вам понадобится некоторый вид транспортного уровня между TCP / IP и самими буферами протокола - protobufs не определяют ничего, кроме сериализованных сообщений.HTTP, как правило, хорошо понимается, легко проходит через брандмауэры и имеет поддержку как клиента, так и сервера на нескольких платформах.

Одна проблема: я не уверен, какая поддержка буфера протокола существует в PHP.Здесь есть бета-библиотека , но это все, что я увидел в списке сторонних дополнений .

0 голосов
/ 22 июля 2010

Я бы использовал простой HTTP, TCP (с сокетами) или FTP, если вам действительно не нужны более сложные функции

...