¿Es la serialización una obligación para transferir datos a través del cable?

Question

A continuación hay algo que leí y me preguntaba si la afirmación es cierta.

serialización es el proceso de la conversión de una estructura de datos u objeto en una secuencia de bits de modo que pueda ser almacenado en una memoria intermedia de archivo o la memoria, o transmitida a través de una red de enlace conexión para ser " resucitó " más tarde en el mismo u otro entorno de computadora . [1] Cuando la serie resultante de bits se vuelve a leer de acuerdo con el formato de serialización, puede ser utilizado para crear de forma semántica clon del objeto original . Para muchos objetos complejos, como , como aquellos que hacen un uso extensivo de las referencias , este proceso no es directo.

Answer 1

La serialización es simplemente una forma elegante de describir lo que se debe hacer cuando se desea transmitir cierta estructura de datos, clase, etc.

Por ejemplo, decir que tengo una estructura:

struct Color 
{ 
    int R, G, B; 
}; 

Al transmitir esta en una red que no dicen enviar color. Usted crea una línea de bits y lo envía. Podría crear un char * sin signo y concatenar R, G y B y luego enviarlos. Acabo de hacer la serialización

Answer 2

Para cualquier cosa más compleja que una primitiva u homogénea de primitivas, sí.

Answer 3

Sí, la serialización es la única forma de transmitir datos a través del cable. Considere cuál es el propósito de la serialización. Usted define la forma en que se almacena la clase. En memoria, no tienes forma de saber exactamente dónde está cada parte de la clase. Especialmente si tiene, por ejemplo, una lista, si ha sido asignada antes pero luego reasignada, es probable que esté fragmentada por todos lados, por lo que no es un bloque contiguo de memoria. ¿Cómo se envía esa clase fragmentada a través de la línea?

Para el caso, si envía un List<ComplexType> sobre el cable, ¿cómo sabe dónde comienza y termina cada ComplexType?

Answer 4

Se requiere la serialización de algún tipo, pero esto puede tomar muchas formas. Puede ser algo así como la serialización dotNET, que maneja el lenguaje, o puede ser un formato personalizado. Tal vez una serie de bytes donde cada byte representa algún "valor mágico" que solo tú y tu aplicación entienden.

Por ejemplo, en dotNET puedo crear una clase con una sola propiedad de cadena, marcarla como serializable y el framework dotNET se ocupa de casi todo lo demás.

También puedo crear mi propio formato personalizado donde los primeros 4 bytes representan la longitud de los datos que se envían y todos los bytes posteriores son caracteres en una cadena. Pero, por supuesto, debe preocuparse por el orden de bytes, codificación Unicode frente a ANSI, etc. etc.

Normalmente, es más fácil utilizar cualquier marco que utilice su lenguaje/marco OS/dev, pero no es necesario.

Answer 5

La serialización binaria no es la única opción. También puede serializar un objeto como un archivo XML, por ejemplo. O como un JSON.

Answer 6

El problema real aquí no es superar el problema, el problema es terminar con el mismo objeto semántico en el otro lado del cable. Para transportar correctamente los datos entre sistemas diferentes, ya sea a través de TCP/IP, disquete o tarjeta perforada, los datos deben estar codificados (serializados) en una representación independiente de la plataforma.

Debido a problemas de alineación y tamaño de tipo, si intenta realizar una transferencia binaria directa de su objeto, esto provocaría un comportamiento no definido (para tomar prestada la definición de los estándares de C/C++).

Por ejemplo, el tamaño y la alineación del long datatype pueden diferir entre arquitecturas, plataformas, idiomas e incluso compilaciones diferentes del mismo compilador.

Answer 7

Creo que estás haciendo la pregunta incorrecta. La serialización es un concepto en la programación de computadoras y existen ciertos requisitos que deben cumplirse para que algo se considere un mecanismo de serialización.

Cualquier medio de preparación de datos de manera que pueda transmitirse o almacenarse de tal forma que otro programa (incluyendo pero no limitado a otra instancia del mismo programa en otro sistema o en otro momento) pueda leer los datos y re -instalar los objetos que representan los datos.

Nota Deslicé el término "objetos" allí. Si escribo un programa que almacena un montón de texto en un archivo; y luego uso algún otro programa, o alguna instancia de ese primer programa para leer esos datos ... Realmente no he usado un mecanismo de "serialización". Si lo escribo de tal manera que el texto también se almacena con algún estado sobre cómo se manipulaba ... eso podría implicar una serialización.

El término se utiliza principalmente para transmitir el concepto de que las combinaciones activas de comportamiento y estado se procesan en una forma que puede leerse mediante otro programa/instancia e instanciarse. La mayoría de los mecanismos de serialización están vinculados a un lenguaje de programación particular, o sistema de máquina virtual (en el sentido de una máquina virtual Java, una máquina virtual C# etc., no en el sentido de máquinas virtuales "VMware"). JSON (y YAML) son una notable excepción a esto. Representan datos para los que hay clases de objetos razonablemente cercanas con una semántica razonablemente similar, de modo que puedan crearse instancias en múltiples lenguajes de programación diferentes de una manera significativa.

No es que toda transmisión de datos o almacenamiento implique "serialización" ... es que ciertas maneras de almacenar y transmitir datos pueden utilizarse para la serialización. En la misma lista, debe ser posible desambiguar entre los tipos de datos que admite el lenguaje de programación. Si dice: 1 tiene que saber si eso es texto o un número entero o real (equivalente a 1.0) o un bit.

Answer 8

Estrictamente hablando, no es la opción solamente; podrías poner un argumento de que "remoting" cumple con el significado en el texto; aquí se crea un objeto falso en el receptor que contiene sin estado. Se interceptan todas las llamadas (métodos, propiedades, etc.) y solo se transfieren llamada y resultado. Esto evita la necesidad de transferir el objeto en sí, pero puede ser muy costoso si se trata de un uso excesivamente "hablador" (es decir, muchas llamadas) ya que cada uno tiene la latencia de la velocidad de la luz (que se suma).

Sin embargo, "remoting" ahora está pasado de moda. Muy a menudo, sí: el objeto tendrá que ser serializado y deserializado de alguna manera (hay lotes de opciones aquí). El párrafo es bastante, muy correcto.

Answer 9

¿Es la serialización una necesidad para transferir datos a través del cable?

Literalmente no.

Es concebible que pueda mover datos de un espacio de direcciones a otro sin serializarlo. Por ejemplo, un sistema hipotético que utiliza memoria virtual distribuida podría mover datos/objetos de una máquina a otra enviando páginas ... sin ningún paso de serialización específico.

Y dentro de una máquina, los objetos se pueden transferir cambiando páginas de un espacio de direcciones virtual a otro.

Pero en la práctica, la respuesta es sí. No conozco ninguna tecnología convencional que funcione de esa manera.

Answer 10

Tener un mensaje como objeto y serializar en bytes es una mejor manera de entender y gestionar lo que se transmite por cable. En el pasado, los protocolos y los datos eran mucho más simples, a menudo, los programadores simplemente ponían bytes en el flujo de salida. La comprensión común fue compartida por tener especificaciones bien conocidas y simples.

Answer 11

Yo diría que la serialización es necesaria para almacenar los objetos en el archivo de persistencia, pero los punteros asignados dinámicamente en los objetos deben volverse a construir cuando deserializamos, pero la serialización para la transferencia depende del protocolo físico y el mecanismo utilizado , por ejemplo, si uso UART para transferir datos, entonces se serializa poco a poco, pero si uso puerto paralelo, se transfieren 8 bits juntos, que no se serializan