Протокол двусторонней связи .NET в реальном времени - PullRequest
4 голосов
/ 07 сентября 2010

Мне нужно поддерживать соединение между сервером и несколькими клиентами, чтобы клиенты могли отправлять команды и запускать события на сервере. Сервер в основном является музыкальным проигрывателем, и клиенты отправляют такие команды, как «Play ()», «Pause ()», «GetPlaylists ()» и т. Д. Сервер на его стороне должен иметь возможность сообщать клиентам такие вещи, как "SongEnded" или "PlayerPaused". Кроме того, должна быть возможность отправлять некоторые данные вперед и назад (например, текущая песня, изображение альбома, списки воспроизведения и т. Д.). Я мог бы, конечно, пойти дальше и сам создать сокет и создать свой собственный протокол для обработки всех вышеперечисленных сценариев, но есть вероятность, что кто-то уже сделал это до меня, так что я действительно хочу, чтобы инфраструктура создавалась в реальном времени. связь между сервером и клиентом для .NET. Я, например, посмотрел на xml-rpc, но не уверен, как мне с этим справиться с OnClientSend. Также, если я не ошибаюсь, xml-rpc сделан как REST-подобный. Я также посмотрел на wcf, но, поскольку у меня нет опыта работы с ним, я не знаю, с чего начать и как разместить сервер в простом консольном приложении.

Важно: Клиент должен быть не в состоянии .NET.
Важно: Это должно быть возможно для подключения к Java (Android).
Важно: Основными платформами являются Windows (сервер и клиент) и Android (клиент).
Важно: Потоковая передача аудио не производится. Тем не менее, изображения должны быть отправлены.

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

[Изменить] Проблема в том, что при отправке данных через сокеты нет никакой гарантии (вообще!), Что отправленные вами пакеты будут одновременно прочитаны сервером. Я мог бы отправить 50, затем 100, затем 50 байтов еще раз, но сервер мог бы прочитать это как 200-байтовый фрагмент, или сначала 100, затем 100 и т. Д., Что означает, что мне нужно создать буфер, читать сообщения, пока я не узнаю наверняка (это это проблема), что я получил целое сообщение (и не более того).

Ответы [ 4 ]

2 голосов
/ 14 сентября 2010

ZeroMQ выглядит хорошо подходит для вашей проблемы. Кажется, вы реализовали нечто подобное сами.

  • Библиотека Supersocket, которая действует как среда параллелизма.

  • Переносит сообщения через inproc, IPC, TCP и многоадресную рассылку.

  • Подключите N-to-N в шаблонах разветвления, публикации, конвейера и запроса-ответа.

  • Достаточно быстро для кластерных продуктов и суперкомпьютеров.

  • Асинхронный ввод-вывод для масштабируемых многоядерных приложений передачи сообщений.

  • Большое и активное сообщество разработчиков открытого исходного кода.

  • 20 + языки, включая C, C ++, Java, .NET, Python.

  • Большинство операционных систем, включая Linux, Windows, OS X.

  • Бесплатное программное обеспечение LGPL, коммерческая поддержка от корпорации iMatix.

1 голос
/ 07 сентября 2010

Вы должны пойти на WCF: http://msdn.microsoft.com/en-us/netframework/aa663324.aspx

0 голосов
/ 14 сентября 2010

В итоге я создал свой собственный простой протокол, который легко реализовать на нескольких языках. Я достиг желаемого результата, добавив дополнительный слой буферов с обеих сторон сокета, а затем отправив каждое сообщение с последующей байтовой последовательностью, которая сообщает другой стороне, что это конец сообщения. Также я добавил идентификаторы к сообщению, чтобы включить специальное сообщение «$ Return».

Сообщения - это просто сериализованные классы, использующие xmlserializer. Классы генерируются из xsd.

0 голосов
/ 14 сентября 2010

Вы также можете посмотреть XMPP и WebSockets .XMPP не ограничен только обменом сообщениями, вы всегда можете расширить его для своих собственных целей.WebSockets идет хорошо, как часть HTML5.

...