title: TCP/IP .NET Sockets Efficiency
body: <p>I've created a library which handles TCP connections. It exists out of a Server and a Client. According to all the examples of MSDN and the recommendations of trusted sources, I should establish a connection between the TcpClient and the TcpListener then send data from the TcpClient to the TcpListener and receive a response and finally close the connection.</p>
  
  <p>But I took a different approach: First of all I didn't use asynchronous connections. Secondly I didn't make the client wait for a response after sending data to the server. Thirdly I didn't close the connection.</p>
  
  <p>I have't chosen the asynchronous path since I don't know the advantages of using it. I didn't make the client wait for a response, since the server won't respond to some messages. I didn't close the connection since I feel the client takes to long to reconnect to the server just to quickly send some data over the stream. Since the connection isn't closed and I still want new clients to be able to connect I made the stream listener - of the existing clients - listen on different threads. Since I don't know how to use FTP, I used FileStream to read files and convert them into bytes to be sent over my TCP connection.</p>
  
  <p>My questions are:
  1. Why use asynchronous connections?
  2. Should the client always receive a response from the server?
  3. Should the connection be closed if you know data will be send shortly after the previous data sent.
  4. Is it a good idea to make different threads handle each client's communication. I used ThreadPool, even though I'm not sure how the execution of the threads work. Is it different operations being executed asynchronously in one thread?
  5. Is there any disadvantage of using my method of sending read bytes from a file over a TCP connection to achieve file sharing rather than using an FTP approach?</p>