Question:
The C ++ client application transmits data to the HTTP server – client ID (to indicate presence), webcam frames (on request), desktop screenshots (on request). If it would be possible to broadcast either a camera or a display, then the question would not be raised, but according to the assignment, it should be possible to simultaneously broadcast.
Through the client socket, the client broadcasts its ID with information about whether it can use the camera (not everyone has it). When the server responds with a request to broadcast a camera, desktop, or all together, the client creates a separate stream for the camera and a separate one for the desktop, since the frame transmission intervals are different (if a 6 kb camera can send a frame 20-25 times per second, then 300 kb display no more than 2, so as not to overload the network).
And here I am at a creative deadlock due to a possible incomplete understanding of the work of sockets: Is it possible to use one socket for these threads? The amount of data is decent, will they not interfere with each other on the same socket with Content-Transfer-Encoding: binary ?
Answer:
I didn't quite understand what I mean by separate streams on the client, if a stream is a separate connection to the server, then you actually should have a socket per connection / stream, but if all data goes through one channel, then you need 1 socket , that is, you need to build on the client architecture, and there is no other choice. In any case, you will have one master socket waiting for connection, which will create new slave sockets for each connection. If it is possible to create on a socket on a "stream", then it is better to do so, select / epoll, etc. to help. The average PC is able to work with tens of thousands of sockets at the same time, quietly reading / sending gigabits / s.
sitev_ru – something you did not understand at all, how many simultaneous requests a "site" can send depends on the browser, by default in modern browsers it is 6-8 simultaneous requests with HTTP /1.1.