Stiamo scrivendo un programma TCPServer e client. Quanto spazio c'è nel buffer TcpClient? Ad esempio, a che punto inizierà a buttare via i dati? Stiamo provando a determinare se il TcpClient può essere bloccato o se deve entrare nel proprio thread in background (in modo che il buffer non possa esaurirsi).Quanto buffer ha NetworkStream e TcpClient?
È possibile ottenere le dimensioni del buffer da TcpClient.ReceiveBufferSize e TcpClient.SendBufferSize.
Le dimensioni del buffer disponibili variano in base alla ricezione/conferma (o meno) dei dati a livello TCP. TcpClient sta bloccando per impostazione predefinita.
Nessun dati saranno gettati via come un risultato di buffer pieno, anche se i dati potrebbero essere buttare via in condizioni di errore sotto (come il peer scompare/crash/uscite, ecc)
La documentazione MSDN dice il predefinito la dimensione dei buffer send e receive per TcpClient è 8192 byte o 8K. La documentazione non specifica un limite su quanto possono essere grandi questi buffer.
Come sono sicuro di sapere, si inviano e si ricevono dati tramite lo TcpClient utilizzando l'oggetto sottostante NetworkStream. Hai il controllo sul fatto che si tratti di operazioni sincrone o asincrone. Se si desidera un comportamento sincrono, utilizzare i metodi Read e Write di NetworkStream. Se si desidera un comportamento asincrono, utilizzare le operazioni BeginRead/ e BeginWrite/EndWrite.
Se si ricevono dati come parte di alcune applicazioni front-end, si consiglia vivamente di farlo in un thread secondario, indipendentemente dal fatto che lo si faccia utilizzando i metodi asincroni o in modo sincrono in un thread separato. Ciò consentirà all'interfaccia utente di rispondere all'utente mentre continua a gestire l'invio e la ricezione di dati in background.
Beh, non lo siamo certo se vogliamo asincroni, o semplicemente farlo in modo sincrono in un thread in background – Earlz
@Earlz, non sono sicuro che ci sia un'enorme differenza tra i due. I metodi asincroni, ad es., BeginRead(), eseguono i rispettivi metodi 'AsyncCallback' su un thread separato. Alla fine della giornata, è necessario utilizzare un thread secondario se si sta tentando di inviare/ricevere dati mentre si sta elaborando l'input dell'utente da un'interfaccia utente. –
@MattDavis, è un malinteso comune. I metodi di I/O Async di rete sfruttano in realtà una porta di I/O di chiamata di una funzione del sistema operativo, quindi nessun thread è bloccato o in uso durante l'attesa di I/O in un socket o dal file system o una named pipe o qualunque cosa. –
Bene, continuerà a ricevere i dati finché il computer non esaurirà la memoria? – Earlz
No, TCP fornisce il controllo di flusso. Quando i buffer sono pieni, l'altra estremità interrompe l'invio. – nos
Anche io sono responsabile del server, quindi se ciò accade, cosa succede al server? Quando i suoi buffer si riempiranno anche usando 'TcpServer' – Earlz