Estamos escribiendo un programa TCPServer y Cliente. ¿Cuánto espacio hay en el buffer TcpClient? Al igual que, ¿en qué punto comenzará a tirar datos? Estamos tratando de determinar si el TcpClient puede estar bloqueando o si debe entrar en ella es propio hilo de fondo (para que el buffer no puede llenar) ..¿Cuánta memoria intermedia tienen NetworkStream y TcpClient?
, usted puede obtener los tamaños de búfer de TcpClient.ReceiveBufferSize y TcpClient.SendBufferSize.
Los tamaños de búfer disponibles variarán a medida que se reciban/confirmen (o no) datos en el nivel de TCP. TcpClient está bloqueando por defecto.
Los datos no serán desechadas como resultado de tampones completo, aunque los datos podrían tiro en condiciones de errores menores (como el peer desaparece/choques/salidas, etc.)
La documentación de MSDN dice el predeterminado el tamaño de los buffers send y receive para TcpClient es 8192 bytes, o 8K. La documentación no especifica un límite en cuanto al tamaño de estos búfers.
Como estoy seguro de que sabe, envía y recibe datos a través del TcpClient utilizando su objeto subyacente NetworkStream. Usted tiene el control sobre si estas son operaciones sincrónicas o asíncronas. Si desea un comportamiento sincrónico, use los métodos Read y Write de NetworkStream. Si desea un comportamiento asincrónico, use las operaciones BeginRead/EndRead y BeginWrite/EndWrite.
Si recibe datos como parte de alguna aplicación de interfaz, le recomiendo que lo haga en una secuencia secundaria, ya sea que haga esto utilizando los métodos asincrónicos o de forma síncrona en una secuencia separada. Esto permitirá que su UI responda al usuario mientras maneja el envío y recepción de datos en segundo plano.
Bueno, no estamos seguro si queremos asincrónico, o simplemente lo hacemos sincrónicamente en un hilo de fondo – Earlz
@Earlz, no estoy seguro de que haya una tremenda diferencia entre los dos. Los métodos asíncronos, por ejemplo, 'BeginRead(), ejecutan sus respectivos métodos' AsyncCallback' en un hilo separado. Al final del día, necesita usar un hilo secundario si está tratando de enviar/recibir datos mientras también procesa la entrada del usuario desde una IU. –
@MattDavis, esa es una idea errónea común. .Net Los métodos asincrónicos de E/S realmente aprovechan una característica del sistema operativo llamada Puertos de finalización de E/S, por lo que no se bloquean o están en uso mientras se espera por E/S en un socket, o desde el sistema de archivos, o una tubería con nombre o lo que sea. –
Bueno, ¿seguirá recibiendo datos hasta que la computadora se quede sin memoria? – Earlz
No, TCP proporciona control de flujo. Cuando los almacenamientos intermedios están llenos, el otro extremo detiene el envío. – nos
También estoy a cargo del servidor, entonces si eso ocurre, ¿qué ocurre en el servidor? ¿Cuándo se llenan los buffers también usando 'TcpServer' – Earlz