On 11/26/12 22:15, Michel Pelletier wrote: > How would your pool proposal provide the same guarantee? It sounds like > you should just PUSH your posts on down the pipeline as soon as they > arrive, and let a downstream consumer deal with accumulating them into a > single multi-part message.
You forget a hairy detail: you cannot break up multi-part messages in ZeroMQ. Hence the start of Post A followed by the start of Post B at the same socket will go very bad... right? Every SND_MORE applied to a message part is effectively the n-th message in a row on the socket. The problem is that interleaving mesages is not possible. A socket pool would facilitate that a certain number of sockets of the defined type are available and shall directly used, without the cost of building the connection. The pool should maintain the minimum number of connections, and when more free connections are given back than the minimum, the remaining connection should be closed. Opposed to manually opening a socket each time when a message is to be send, this remove the TIME_WAIT status the closed socket will and up in. On a very high number of request the system will break under resource starvation. STefan _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
