Hello, We are writing a TCPServer and Client program. How much space is there in the TcpClient buffer? Like, at what point will it begin to throw away data? We are trying to determine if the TcpClient can be blocking or if it should go into it's own background thread(so that the buffer can not get full)..
A:
You can get the buffer sizes from TcpClient.ReceiveBufferSize and TcpClient.SendBufferSize .
The available buffer sizes will vary as data is received/acknowledged(or not) at the TCP level. TcpClient is blocking by default.
No data will be thrown away as a result of full buffers, though data could be throw away in under error conditions (such as the peer disappears/crashes/exits etc.)
nos
2010-03-28 18:36:23
Well so it will keep receiving data until the computer runs out of memory?
Earlz
2010-03-28 22:11:05
No, TCP provides flow control. When the buffers are full, the other end stops sending.
nos
2010-03-29 07:08:04
I'm in charge of the server too, so if that happens, then what happens at the server? When will it's buffers fill up also using `TcpServer`
Earlz
2010-03-29 13:57:00
It's the same for the client side as for the server. Sending blocks. It will block when the internal buffers are full, and no data can be sent at this time to empty those buffers (e.g. as a result that the other end havn't read all the data that has been sent )
nos
2010-03-29 17:37:13
A:
The MSDN documentation says the default size of the send and receive buffers for TcpClient is 8192 bytes, or 8K. The documentation does not specify a limit as to how big these buffers can be.
As I'm sure you're aware, you send and receive data via the TcpClient using its underlying NetworkStream object. You are in control over whether these are synchronous or asynchronous operations. If you want synchronous behavior, use the Read and Write methods of NetworkStream. If you want asynchronous behavior, use the BeginRead/EndRead and BeginWrite/EndWrite operations.
If you are receiving data as part of some front-end application, I would highly recommend doing this in a secondary thread, whether you do this using the asynchronous methods or synchronously in a separate thread. This will allow your UI to be responsive to the user while still handling the sending and receiving of data in the background.
Matt Davis
2010-03-28 19:18:06
Well we aren't sure if we want asynchronous, or to just do it synchronously in a background thread
Earlz
2010-03-28 22:12:05
@Earlz, I'm not sure there's a tremendous difference between the two. The asynchronous methods, e.g., `BeginRead(), execute their respective `AsyncCallback` methods on a separate thread. At the end of the day, you need to use a secondary thread if you are trying to send/receive data while you are also processing user input from a UI.
Matt Davis
2010-03-29 13:33:41