Внедрить порт TCP/UDP в Windows Azure

Question

Мы хотим реализовать порт через Windows Azure Cloud Service и хотели бы получить некоторые отзывы о нашей стратегии.

Наш текущий проект:

• Физическое GPS модуль, который работает в качестве клиента .
• Windows Azure Cloud Service, который работает как сервер .

1) Физическая единица GPS: Мы используем XT-4000 [Xirgo Technologies] физический Gps блок, который является мощным отслеживания, мониторинга и управления шлюзом device.This устройство требует UDP или TCP-порт для связи.

2) Windows Azure Cloud Service: Здесь нам нужно открыть порт TCP или UDP и прослушать там прослушивающие данные, которые выталкиваются устройством [XT-4000].

Вот что мы думаем, что наша стратегия должна быть. Все советы приветствуются.

• Создание порта TCP на Azure.
• Установите прослушиватель для приема входящих сигналов с устройства.

[Но вопрос мы можем создать TCP-порт на Windows Azure Cloud Service в качестве платформы на основе облака, и если да, то как?]

Две дополнительные вопросы:

• Как устройство поддерживает как UDP, так и TCP-порт для связи, какой из них лучше?

• Для получения сигналов от устройства к порту нужна ли какая-либо сторонняя помощь?

Answer 1

Вы должны использовать Windows Azure Cloud Service и не Windows Azure Web Site.

Для облачного сервиса вам потребуется использовать роль рабочего для реализации протокола, поддерживаемого устройством. Вы можете использовать TCP или UDP - все, с чем вам удобнее программировать. Вам понадобится define an input endpoints для вашего облачного сервиса.

Что касается дополнительных вопросов:

As the device supports both UDP or TCP port to communicate, which one is better? 

В зависимости от протокола, поддерживаемого устройством. Я видел множество протоколов, используемых устройствами GPS. От «просто отправить и забыть» «очень надежную проверку ошибок и получить подтверждение». Если протокол вашего устройства имеет тип «просто отправить и забыть», возможно, TCP лучше, так как он более надежный. Если протокол устройства подвержен ошибкам и подтверждает подтверждение/CRC-Check/receive, тогда вы в порядке, чтобы идти с UDP.

Для получения сигналов от устройства к порту нам нужна какая-либо третья сторона help?

Это зависит от ваших навыков программирования ...

Answer 2

Мы внедрили подобную услугу (слежения за автотранспортными средствами) успешно работает на платформе Windows Azure. Некоторые наблюдения:

• Согласно ответу astakov, вы смотрите на облачный сервис (работник роли)
• Azure поддерживает как TCP и UDP, но если у вас есть выбор, идти на TCP. UDP не имеет подключений, и у устройства нет способа узнать, получил ли ваша служба данные. Мы были вынуждены использовать UDP и должны отправлять подтверждающие данные на устройство, иначе он будет возмущаться (нам действительно нужно было написать собственный протокол по UDP). Отправка UDP-пакетов с вашего сервера на устройство может быть заблокирована правилами брандмауэра мобильной сети (и другой сетевой конфигурацией). Борьба с UDP в максимально возможной степени - потерянный характер UDP совершенно не подходит для отслеживания транспортных средств.
• Проверьте, поддерживает ли устройство DNS. Многие из этих устройств отправляют только IP-адреса, что делает развертывание немного сложнее.
• Эти устройства должны минимизировать передаваемые данные (из-за стоимости данных GSM) и обычно отправлять данные в собственном и сжатом формате. Большая часть ваших усилий будет потрачена на сбор двоичных данных. Если можно, найдите поставщика, у которого есть библиотека, которую вы можете использовать на стороне сервера для декодирования данных. В нашем конкретном случае (для специально разработанного и построенного устройства) потребовалось около 10 человеко-месяцев разработки, чтобы правильно декодировать данные.