Is it rational if there are two threads for each connection on the server: one for receiving and the other for sending?

  • four
    brilliant question ... It would be more rational to ask correctly. - Barmaley
  • Why two streams? One for each connection is enough. The code runs faster than the data is sent. - nitrocaster
  • 2
    @ alex91, you would have written in more detail what kind of server, which protocol in principle, processing requirements, etc. I understand that it is in your head, but we know nothing about it. And you will receive the same answers to such a general question as now. - avp
  • The architecture is as follows: There is a main stream. There is a stream that waits for a connection and, when connected, creates a stream for a new connection. For a start, I want to make an exchange of messages between users. This is my first server application and I have a lot of different ideas in my head, how can I do it :) I plan to send messages like this: there will be a class with all connections, the class will be made as singleton. In each connection thread there is a SetMess function, which puts a string in one of the fields and the flag sets true. Connection flow in while loop looks, if that flag is true then send - alex91
  • Message exchange. Delayed delivery is, or as in the chat, only those who are online? - avp

3 answers 3

"I see the dark side of power in you" (c) In general, multithreading should be used, when actions should be performed in parallel (c) Cap. Those. if you want, as I understood from the comments, to write a chat, it is not rational, if you can call it that. It turns out one juzver - 2 streams, somehow dofig 1 - you do not have such a wild flow of information, for which you would need to allocate a separate stream 2 - The number of possible flows is not dimensionless ;-) 3 - Synchronization, all this is necessary then sync, if not difficult, but there are subtle points

Personally, my advice is to use non-blocking sockets and an event model — simply, beautifully, elaborately, and if you decode streams in parallel, you need something, you need to calculate the total control, etc.

  • Began to read about non-blocking sockets. At least thanks for the new food for the brain :) - alex91

Rationally only if your server transmits data faster than it executes the code of your application. What seems to me (nonsense) fiction.

    No, you need 3: one for receiving, one for sending, and one for computing. However, for calculations, you can take the flow and more.

    • one
      What small things, let's just 10 threads for the mandrel, reception and calculations. It is possible more ... it is possible less ... Pts. - nitrocaster
    • Not a lot of threads to send and a lot to receive - messages will lose order, then you will not rake. - rfq
    • The fact is that it seems to me that you will lose all the benefits of synchronization. I.e. If one stream of data was received by me, I processed it myself or gave it to someone and processed it and sent it. In your case, one stream accepted, then with a secure synchronization method it returned the packet. It was processed by another thread. Then again some kind of blocking and only then sending. - Jakeroid