viceversa tutorial sistema hacer facil ejercicios convertir conversion como combinacion binario http proxy binary-data

http - sistema - tutorial de binario a decimal



Enviando datos binarios a través de http (4)

¿Simplemente el envío de datos codificados en base64 funcionará?

No es necesario utilizar la codificación base 64, esto simplemente aumentará el número de bytes que debe transferir. Los operadores móviles normalmente limitan la manipulación de respuestas a los tipos de contenido que comprenden, es decir, imágenes, hojas de estilo, etc.

¿Cómo se manejan las sesiones HTTP?

Las sesiones HTTP normalmente se manejan mediante un parámetro de consulta de URL o mediante un valor de cookie. Sin embargo, por lo que has dicho, no parece que las sesiones sean necesarias.

Los sockets arbitrarios pueden mantenerse vivos durante mucho tiempo, pero los verbos HTTP suelen ser de corta duración. ¿Significa esto que necesitaré crear una nueva conexión para cada paquete de datos?

Las solicitudes HTTP pueden durar un período de tiempo arbitrariamente largo, al igual que para sockets TCP sin procesar. Una solicitud GET puede durar horas si es necesario. No necesita crear una nueva conexión para cada solicitud; eche un vistazo al encabezado HTTP de Connection: Keep-Alive .

¿O hay una manera de enviar respuestas del servidor en trozos, a través de una sola conexión?

Si no sabe la longitud de la respuesta, puede omitir un encabezado Content-Length o, preferiblemente, usar el encabezado HTTP Transfer-Encoding: chunked .

¿De qué manera puede un proxy ISP desordenar los datos o los encabezados? Por ejemplo, un proxy a veces puede mantener viva una conexión, incluso si el servidor la cierra.

Los ISP no tienden a revelar los cambios que hacen a las respuestas HTTP. Si le preocupa esto, una solución simple sería cifrar los datos y especificar un encabezado HTTP de Content-Encoding . Esto requeriría que usted controle el cliente y el servidor HTTP.

Estoy buscando sugerencias sobre la mejor manera de enviar / recibir datos desde un dispositivo GPRS remoto, a través del puerto 80.

La creación de un socket TCP simple en un puerto aleatorio funciona bien, pero muchos operadores solo permiten el tráfico HTTP del puerto 80 a través de sus proxies, y luego esperan datos HTTP ascii (para los que pueden modificar los encabezados según sea necesario).

Entonces, ¿debería mi dispositivo crear una solicitud POST en una conexión http persistente y luego recibir una respuesta codificada en base64 del servicio web? No estoy seguro de cómo se comportan los proxies móviles cuando se trata de datos binarios. ¿Hay alguna forma recomendada de hacer esto?

Puedo adaptar el firmware del dispositivo y la aplicación del lado del servidor.

[Editar]

Me gustaría saber si hay una forma estándar (más o menos) de hacer esto. Para diversos sistemas industriales y de registro de datos, es necesario enviar muchos datos binarios a través de conexiones de socket. Para las conexiones Ethernet, generalmente solo hay problemas relacionados con la adaptación de algunos firewalls, pero las conexiones binarias persistentes no tienen problemas para establecerse sobre puertos arbitrarios.

Sin embargo, los ISP móviles tienden a limitar sus "planes de datos" solo para el puerto 80. También se toman la libertad de meterse con los encabezados HTTP y, potencialmente, los propios datos HTML. Aquí es donde necesito identificar los peligros potenciales y las formas de sortearlos.

  • ¿Simplemente el envío de datos codificados en base64 funcionará?
  • ¿Cómo se manejan las sesiones HTTP? Los sockets arbitrarios pueden mantenerse vivos durante mucho tiempo, pero los verbos HTTP suelen ser de corta duración. ¿Significa esto que necesitaré crear una nueva conexión para cada paquete de datos? ¿O hay una manera de enviar respuestas del servidor en trozos, a través de una sola conexión?
  • ¿De qué manera puede un proxy ISP desordenar los datos o los encabezados? Por ejemplo, un proxy a veces puede mantener viva una conexión, incluso si el servidor la cierra.


Si es posible, puede enviar los datos como solicitudes y respuestas HTTP.

HTTP es perfectamente capaz de manejar datos binarios: las imágenes se envían a través de HTTP todo el tiempo y son binarias. La gente carga y descarga archivos de tipos de datos arbitrarios todo el tiempo sin ningún problema.

Solo dale un tipo mime de "application / octet-stream", que es básicamente un tipo mime genérico para datos binarios sin especificación adicional de qué tipo, y cualquier proxy en el camino debería dejarlo solo.


Yo recomendaría un servicio web SOAP. Acepta una solicitud POST que contiene parámetros XML. Hay una forma estándar de enviar datos binarios a través de SOAP / XML. Hacemos esto todo el tiempo para transportar el byte [] sobre SOAP.

En su WSDL, declare que su campo es de este tipo:

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

Somos una tienda de Java y usamos JAXB / CXF y generamos el WSDL sobre la marcha a partir de los Objetos de Java. JAXB maneja automáticamente la traducción de byte [] a xs: base64Binary, por lo que ni siquiera necesita saber que sus datos se están codificando como base64.

Los servicios SOAP no tienen sesiones, por lo que no debe preocuparse por las sesiones http. Lo más probable es que cree una nueva conexión, pero solo me preocuparía si realmente hay un problema con ella. Debido a que esta es una solicitud POST sin una cookie de sesión, dudo que el ISP la altere. Siempre puedes usar HTTPS solo para estar seguro. En un enlace GPRS que tenderá a conectarse / desconectarse, no intentaría mantener un socket abierto.