Hi Pieter, > Isn't the real issue here that connect is asynchronous? > > I've thought often that making connect synchronous (at the API level) > would solve a lot of 'surprising' aspects, without doing any harm. Of > course there needs to be the option of doing non-blocking connects, > since we sometimes want that. But it's a minority use case. This is > also how the normal TCP socket API works. Synchronous connects unless > you do extra work to make them non-blocking.
My understanding of the problem is that there are two types of applications with very different semantics. There are "core nodes" of the topology which, I believe, are addressed OK by current design: 1. Core nodes can be connected to more than one peer. 2. Core nodes can both bind and connect. 3. There are no connect/disconnect notifications. 4. All operations are fully async. On the other hand there are "leg" applications. What's special about them is they are endpoints on the edge of the topology. They have pretty different requirements: 1. Leg app can have only one peer. 2. It can't bind. It can only connect. 3. Disconnection is explicitly reported to the user. 4. All operations are fully sync. There are other requirements that differ, but you get the idea. It's what you would call server vs. client stack in traditional messaging. The "leg" implementations were theoretically discussed already very long time ago and are starting to pop-up now. We already have the "minimal 0MQ stack in bash" and "ZmqSocket.as" Hopefully, we'll have more of them in the future. Martin _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
