Подтвердить что ты не робот

Отправка двоичных данных по http

Я ищу предложения по наилучшему способу отправки/получения данных с удаленного устройства GPRS через порт 80.

Создание простого TCP-сокета на случайном порту прекрасно работает, но многие операторы разрешают только HTTP-трафик HTTP-порта через их прокси, а затем ожидают HTTP-данные ascii (для которых они могут изменять заголовки по мере необходимости.

Итак, должно ли мое устройство создать запрос POST на постоянном http-соединении, а затем получить ответ с кодировкой base64 от веб-службы? Я не уверен, как ведут себя мобильные прокси, когда участвуют двоичные данные. Есть ли рекомендуемый способ сделать это?

Я могу адаптировать как прошивку устройства, так и приложение на стороне сервера.

[изменить]

Я хотел бы знать, существует ли стандартный (более или менее) способ сделать это. Для различной регистрации данных и промышленных систем необходимо отправлять множество двоичных данных по соединениям сокетов. Для Ethernet-соединений обычно возникают проблемы с адаптацией некоторых брандмауэров, но постоянные двоичные соединения не создают проблем с произвольными портами.

Мобильные интернет-провайдеры, однако, имеют тенденцию ограничивать свои "планы данных" только для порта 80. Они также берут на себя смелость связываться с заголовками HTTP и, возможно, самими данными HTML. Здесь мне нужно определить потенциальные ловушки и способы их обойти.

  • Будет ли просто отправлять данные с кодировкой base64?
  • Как обрабатываются сеансы HTTP? Произвольные сокеты могут поддерживаться в течение длительного времени, но HTTP-глаголы обычно недолговечны. Означает ли это, что мне нужно будет создать новое соединение для каждого пакета данных? Или есть способ отправить ответы сервера в кусках по одному соединению?
  • Каким образом может быть прокси-сервер ISP с данными или заголовками? Например, прокси-сервер иногда может поддерживать соединение, даже если сервер закрывает его.
4b9b3361

ОТВЕТЫ

Ответ 1

Будет ли просто отправлять данные с кодировкой base64?

Нет необходимости использовать кодировку base 64 - это просто увеличит количество байтов, которые вы должны перенести. Мобильные операторы обычно ограничивают обработку ответов на типы контента, которые они понимают, т.е. Изображения, таблицы стилей и т.д.

Как обрабатываются сеансы HTTP?

HTTP-сеансы обычно обрабатываются либо через параметр запроса URL-адреса, либо через значение cookie. Однако из того, что вы сказали, это не похоже на сеансы.

Произвольные сокеты могут поддерживаться в течение длительного времени, но HTTP-глаголы обычно недолговечны. Означает ли это, что мне нужно будет создать новое соединение для каждого пакета данных?

HTTP-запросы могут выполняться в течение сколь угодно длительного периода времени, как и для сырых сокетов TCP. Запрос GET может продолжаться в течение нескольких часов, если это необходимо. Вам не нужно создавать новое соединение для каждого запроса — посмотрите заголовок Connection: Keep-Alive HTTP.

Или есть способ отправить ответы сервера в кусках по одному соединению?

Если вы не знаете длину ответа, вы можете либо опустить заголовок Content-Length, либо, желательно, использовать заголовок Transfer-Encoding: chunked HTTP.

Каким образом может быть прокси-сервер ISP с данными или заголовками? Например, прокси-сервер иногда может поддерживать соединение, даже если сервер закрывает его.

Интернет-провайдеры не склонны раскрывать изменения, которые они вносят в ответы HTTP. Если вас это беспокоит, простым решением было бы зашифровать данные и указать заголовок Content-Encoding HTTP. Это потребует, чтобы вы контролировали как клиент HTTP, так и сервер.

Ответ 2

Если возможно, вы можете просто отправить данные в виде HTTP-запросов и ответов.

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

Просто дайте ему тип mime "application/octet-stream" - который в основном является универсальным типом mime для двоичных данных без дополнительной спецификации какого-либо типа - и любые прокси-серверы по пути должны оставить его в покое.

Ответ 4

Я бы порекомендовал SOAP веб-сервис. Он принимает запрос POST, содержащий параметры XML. Существует стандартный способ отправки двоичных данных через SOAP/XML. Мы делаем это все время для передачи байта [] через SOAP.

В вашем WSDL объявите поле этого типа:

<xs:element name="myByteArrayFieldName" type="xs:base64Binary"/>

Мы магазин Java, и мы используем JAXB/CXF и генерируем WSDL на лету из объектов Java. JAXB автоматически обрабатывает перевод из byte [] в xs: base64Binary, поэтому вам даже не нужно знать, что ваши данные кодируются как base64!

Сервисы SOAP не имеют сессий, поэтому вам не нужно беспокоиться о http-сессиях. Скорее всего, это создаст новое соединение, но я бы беспокоился об этом только в том случае, если на самом деле есть проблема с ним. Поскольку это POST-запрос без cookie файла сеанса, я сомневаюсь, что провайдер с этим справится. Вы всегда можете использовать HTTPS просто для уверенности. На соединении GPRS, которое будет иметь тенденцию соединяться/разъединяться, я не буду пытаться держать сокет открытым.