Configuración del desplazamiento en una secuencia

Question

Aquí dice msdn.microsoft.com/en-us/library/system.io.stream.read.aspx que los métodos Stream.Read y Stream.Write adelantan la posición/desplazamiento en la secuencia automáticamente, por lo que ¿Por qué los ejemplos están aquí http://msdn.microsoft.com/en-us/library/system.io.stream.read.aspx y http://msdn.microsoft.com/en-us/library/system.io.filestream.read.aspx cambiando manualmente el desplazamiento?

¿Solo establece el desplazamiento en un bucle si conoce el tamaño del flujo y lo establece en 0 si no conoce el tamaño y utiliza un búfer?

// Now read s into a byte buffer. 
    byte[] bytes = new byte[s.Length]; 
    int numBytesToRead = (int) s.Length; 
    int numBytesRead = 0; 
    while (numBytesToRead > 0) 
    { 
     // Read may return anything from 0 to 10. 
     int n = s.Read(bytes, numBytesRead, 10); 
     // The end of the file is reached. 
     if (n == 0) 
     { 
      break; 
     } 
     numBytesRead += n; 
     numBytesToRead -= n; 
    } 

y

using (GZipStream stream = new GZipStream(new MemoryStream(gzip), CompressionMode.Decompress)) 
{ 
    const int size = 4096; 
    byte[] buffer = new byte[size]; 
    using (MemoryStream memory = new MemoryStream()) 
    { 
    int count = 0; 
    do 
    { 
     count = stream.Read(buffer, 0, size); 
     if (count > 0) 
     { 
     memory.Write(buffer, 0, count); 
     } 
    } 
    while (count > 0); 
    return memory.ToArray(); 
    } 
} 

Answer 1

Editar (a la pregunta editada):

En ninguno de los fragmentos de código que pegó en la cuestión veo cualquier flujo de desfase está estableciendo.

Creo que está confundiendo el cálculo de bytes para leer contra los bytes recibidos. Este protocolo puede parecer gracioso (¿por qué recibiría menos bytes de los solicitados?), Pero tiene sentido si considera que podría estar leyendo desde una fuente orientada a paquetes de alta latencia (piense en los sockets de red).

Puede estar recibiendo 6 caracteres en una ráfaga (de un paquete TCP) y solo recibirá los 4 caracteres restantes en su próxima lectura (cuando haya llegado el siguiente paquete).

Editar En respuesta a su linked example del comentario:

using (GZipStream stream = new GZipStream(new MemoryStream(gzip), CompressionMode.Decompress)) 
    { 
     // ... snip 

     count = stream.Read(buffer, 0, size); 
     if (count > 0) 
     { 
     memory.Write(buffer, 0, count); 
     } 

Parece ser que los programadores utilizan el conocimiento previo acerca de la implementación secuencia subyacente, que stream.Read siempre devolverá 0 O el tamaño pedido. Eso parece una apuesta arriesgada, para mí. Pero si los documentos para GZipStream afirman eso, podría estar bien. Sin embargo, dado que los ejemplos de MSDN usan una variable genérica Stream, es (mucho) más correcto verificar el número exacto de bytes leídos.

---

El primer ejemplo vinculado usa un MemoryStream tanto en escritura como en lectura. La posición se pone a cero en el medio, por lo que se leen los datos que fue escrito primero:

Stream s = new MemoryStream(); 
    for (int i = 0; i < 100; i++) 
    { 
     s.WriteByte((byte)i); 
    } 
    s.Position = 0; 

El segundo ejemplo los vinculados hace no establecer la posición corriente. Por lo general, habría visto una llamada al Seek si lo hiciera. ¿Tal vez confundir las compensaciones en el búfer de datos con la posición de secuencia?

Answer 2

El desplazamiento es en realidad el desplazamiento del búfer, no la secuencia. Los flujos se avanzan automáticamente a medida que se leen.