The native C socket API returns on accept() a new socket descriptor, which is bound to a certain remote socket. That’s good because I can create a thread, pass the socket and establish a point-to-point, or better a thread-to-thread connection over the internet. And that’s exactly what I want: one thread from the client should be connected to a destined thread on the server. Hence I dont need a workerpool or loadbalancing not even async operation. The server threads save history. ZeroMQ seems great but as far as I understood it does not split up sockets on accept.
Is there a way to establish such an synchronous thread-to-thread connection with ZerMQ?
You’re asking how to replicate a particular solution (handing off a socket to a thread) to a broader problem (how to write scalable servers).
The ‘one thread per socket’ design only works in one pattern which is request-reply, e.g. HTTP. Whereas the really high volume use cases are for data distribution (publish-subscribe), or task distribution (pipeline). Neither fit a 1-to-1 model.
It is a common error when you learn a new tool to ask, “how does this tool do what my old tools do” but you won’t get good results like that. Instead, take the time to actually learn how the tool works, and then use that knowledge to re-think your problems and the best solutions for them.