CODEWITHSUNDEEP
c#multithreadingsocketstcp
Rudi Jansen van Vuuren
Rudi Jansen van Vuuren

Reputation: 455

TCP/IP .NET Sockets Efficiency

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.

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.

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.

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?

Upvotes: 0

Views: 551

Answers (2)

Sergey Kilimnik
Sergey Kilimnik

Reputation: 1

  1. Why async? It's easy! You have 2 choices: open new thread and block it on socket read operation or use async sockets. The only problem with thread is that thread is heavy object. Every opened .net thread takes 1MB of memory, and also you need to start thinking in multi-threading paradigm.

  2. No

  3. No

  4. Without async you do not have any other choice

Upvotes: 0

Richard
Richard

Reputation: 108975

  1. Why use asynchronous connections?

Being asynchronous avoids blocking operations. Blocking operations mean the blocked thread is not usable for anything else, and if it is the UI thread then the UI is blocked as well.

Threads are a valuable resource and, on Windows*, don't waste them waiting on some other process that may never respond.

  1. 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.

These are both dependent on the protocol you're implementing. In some cases a simple request, response, and close is the way. In other cases connections may be long lived with most data one way. In some cases a single client may use multiple concurrent sockets.

  1. Is it a good idea to make different threads handle each client's communication

No. See above about threads being expensive. Better to have a small pool of thread serve a large pool of clients. For simple cases – eg. when learning – it can be easier to start with the thread per client model, but it just does not scale beyond a small** number of clients.

Finally it is highly unlikely that you will be able to do better than what is in the framework: there is a lot of experience (and failed approaches***) in the history of implementing servers using TCP/IP.

  1. 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?

How long a list do you want? Start with:

  • FTP is a standard and widely supported.
  • FTP allows a single client session to perform many operations.
  • You'll bog the CPU down with thread scheduling before you run out of other resources (assuming you don't run out of virtual address space for thread stacks first).

* Different operating systems have different threading/process models with different engineering trade-offs.

** You say nothing about the size of your system (number of clients, connection rate, amount of data, …) so I can only be very general.

*** For example the Socket class has support for three different models of asynchronicity in it.

Upvotes: 3

Related Questions