Problem with a multithreaded server

Question

I am writing a server in Linux that should serve as an API.

Initially, I wanted to make it multithreaded on the same port, which means that I will have several threads working with different requests received on the same port.

One of my friends told me that this is not how it should work. He told me that when the request is received, I must first follow the Handshake procedure, create a stream that listens to some other port dedicated to the request, and then redirect the requested client to the new port.

Theoretically, this is very interesting, but I could not find any information on how to implement a handshake and perform a redirect. Can anyone help?

---

If I am not mistaken in interpreting your answers, as soon as I create a multithreaded server with the main thread listening on the port and create a new thread for processing requests, do I essentially make it multithreaded on one port?

Consider a scenario in which I receive a large number of requests every second. Isn't it true that every port request should now wait for the "current" request to complete? If not, how the connection will be performed: let's say the browser sends a request, so the stream should first listen on the port, block it, process it, respond and then unlock it.

In this case, although I have "multithreading", all I use is one single thread at a time, except for the main thread, because the port is blocked.

Answer 1

What your friend told you looks like passive FTP - the client tells the server that it needs a connection, the server sends back the port number, and the client creates a data connection with this port.

But all you wanted to do was a multithreaded server. All you need is a single server socket that listens and accepts connections on this port. Once the automatic TCP handshake is complete, you will receive a new socket from the accept function - this socket will be used to communicate with the client that has just connected. So, now you only need to create a new thread by passing this client socket to the stream function. In your server thread, you call accept again to accept another connection.

Answer 2

TCP / IP handshakes if you cannot come up with any reason for a handshake than your application does not require.

An example of a special handshake for an application is user authentication.

---

What your colleague offers sounds like FTP works. This is not good to do - the Internet these days is more or less used for protocols that use a single port, and commands with a port are bad. One reason is that state firewalls are not designed for multiport applications; they must be expanded for each individual application that does so in this way.

Answer 3

Check out the ASIO tutorial on asynchronous TCP . There, one part accepts connections on TCP and spawns handlers, each of which exchanges data with one client. How TCP servers usually work (including HTTP / web, the most common tcp protocol.)

You can ignore ASIO asynchronous stuff if you are configured to create a stream for each connection. This does not apply to your question. (It runs completely asynchronously, and one worker thread per core is good, but it cannot integrate well with the rest of the environment.)