Cuando uso un SSLStream para enviar un "gran" fragmento de datos (1 meg) a un cliente (ya autenticado), el paquete fragmentation/disasembly que estoy viendo es FAR mayor que cuando se usa un NetworkStream normal.Fragmentación de paquetes al enviar datos a través de SSLStream
Usando una lectura asíncrono en el cliente (es decir BeginRead()), la ReadCallback se llama repetidamente con exactamente el mismo trozo tamaño de los datos arriba hasta que el paquete final (el resto de los datos). Con los datos que estoy enviando (es un archivo zip), los segmentos tienen 16363 bytes de longitud. Nota: Mi búfer de recepción es mucho más grande que esto y cambiar su tamaño no tiene ningún efecto
entiendo que SSL encripta los datos en trozos del tamaño de 18Kb, pero dado que SSL se encuentra por encima de TCP, yo no pensaría que el número de trozos de SSL tendría alguna relevancia para la fragmentación del paquete TCP?
Esencialmente, los datos se toma cerca de 20 veces más tiempo para ser totalmente leído por el cliente que con un NetworkStream estándar (tanto en el servidor local!)
¿Qué me falta?
EDIT:
estoy empezando a sospechar que la reciben (o enviar) tamaño del búfer de un SslStream es limitado. Incluso si uso lecturas sincrónicas (es decir, SSLStream.Read()), nunca más datos estarán disponibles, independientemente de cuánto tiempo espere antes de intentar leer. Este sería el mismo comportamiento que si tuviera que limitar el búfer de recepción a 16363 bytes. Configurar el subyacente NetworkStream SendBufferSize (en el servidor), y ReceiveBufferSize (en el cliente) no tiene ningún efecto.
¿Está hablando de fragmentación de IP o de cuántas lecturas tiene que hacer en el lado del receptor? –
El número de lecturas realizadas – Ive
¿Cómo está enviando? Si no utiliza búferes en secuencias SSL, puede obtener una explosión de datos de más de 40x debido a la codificación de un byte a la vez en su propio registro SSL. – EJP