Unix TCP and UDP Servers

Question

Why is the design of TCP servers basically such that whenever it accepts a connection, a new process is called to process it. But why, in the case of UDP servers, basically, there is only one process that processes all client requests?

Answer 1

The main difference between TCP and UDP, as stated above, is that UDP is contactless.

In a program that uses UDP, there is only one socket where it receives messages. Therefore, there is no problem if you just block and wait for the message.

When using TCP, you get one socket for each connected client. Then you cannot just block and wait for the ONE socket to receive something, because there are other sockets that need to be processed at the same time.
Thus, you have two options: use non-blocking methods or use threads. The code, as a rule, is much simpler if you do not have one while loop that each client should process, so multi-threading is often required. You can also save some CPU time by using locking methods.

Answer 2

When you are talking to a client over a TCP connection, you are maintaining a TCP session. Therefore, when a new connection is established, you need a separate process (or thread, regardless of how it is implemented and which OS is used), and to maintain a conversation. But when you use a UDP connection, you can get a datagram (and you will be informed about the sender ip and port), but in the general case you cannot answer it.

Answer 3

First of all, the classic Unix server paradigm is based on filters. For example, various network services can be configured in / etc / services, and a program, such as inetd, listens on all TCP and UDP sockets for incoming connections and datagrams. When the / DG connection comes in forks, redirects stdin, stdout and stderr to the socket using the dup2 system call, and then runs the server process. You can take any program that reads from stdin and writes to stdout and turns it into a network service such as grep .

According to Stephen in Unix Network Programming , there are five types of server I / O models (p. 154):

• blocking
• non-blocking
• multiplexing (selection and polling)
• Signal management
• asynchronous (POSIX aio_ functions)

In addition, servers can be iterative or parallel.

You ask why TCP servers are usually parallel, whereas UDP servers are usually iterative.

UDP is easier to answer. Typically, UDP applications follow a simple query response model when a client sends a short request followed by a response, with each pair representing a separate transaction. UDP servers are the only ones that use Signal Drive I / O, and very rarely.

TCP is a bit more complicated. Iterative servers can use any of the above I / O models, except for # 4. The fastest servers on a single processor are actually iterative servers that use non-blocking I / O. However, they are considered relatively difficult to implement and that is plus the Unix filter idiom, where traditionally are the main reasons for using a parallel model with I / O blocking, be it multi-processor or multi-threaded. Now, with the advent of common multi-core systems, the parallel model also has a performance advantage.

Answer 4

Your generalization is too general. This is a template that you can see on a Unix-based server where creating a process is inexpensive. The .NET-based service will use the new thread from the thread pool instead of creating a new process.

Answer 5

Programs that can continue to do useful work while they wait for I / O will often be multithreaded. Programs that perform many calculations that can be neatly divided into separate sections can benefit from multithreading if there are multiple processors. Programs that serve many network requests can sometimes be useful, having a pool of available threads for serving requests. GUI programs that also need to perform computation can benefit from multithreading because it allows you to continue serving graphical interfaces.

That is why we use TCP as the Internet protocol.