13.04.2011, 06:47, "Brian Granger" <[email protected]>: > We have build a pretty complex distributed architecture with zeromq > and have simply added all of these using additional channels. This > has worked *extremely* well and keeps different concerns separated. > The design pattern that guides all of our zeromq development is this: > > one purpose = one zeromq socket >
Of course, but for me it means: one purpose for application, I mean don't create several sockets for presence, heartbeating and acks for every application-specific socket. > I am not saying that REP sockets shouldn't grow these capabilities, > but there will be a complexity/performance cost associated with this. > It is not clear to me that cost is any better than the costs of > multiple sockets. More sockets add configuration burden. Sometimes we also want to add a devices between two parts of application and more different sockets means more devices between them. > >> 2. REQ socket is also useless for most applications, because of: >> 1) unable to retry request >> 3. XREQ lacks support of routing request to a specific destination > > XREP does that just fine. > Yes, but it's not what XREP was made for. Actually XREP works almost anywhere where others don't. My proposition is something similar: if we have universal socket, lets document it apropriately and use it. >> 4. XREP is meant as a non-blocking replier socket, but incidentally used >> for everything other sockets can't do >> 5. Ineficient load-balancing for some applications > > I would like to see different load-balancing algorithms in zeromq. > However, we have found that it is quite easy to move some queues into > the application level and have the application do the scheduling. Our > experience is that if you want anything but simple load-balancing, you > really want this. > We have discussed that earlier and seems most people think that load-balancing must be application specific. My purpose is to give an obvious way to implement it. >> Push/Pull: >> 1. No routing to specific destination > > But it seems like this messaging pattern precludes this. > We want that for request-reply, why not for push/pull? Consider you have a sharded queue, and you want to queue task to a specific shard. >> 3. Ineficient load-balancing for some applications > > Yep, very true. > Ah, well, this is another task similar to routing to specific destination. I mean another task which need custom routing for push/pull (which also can be implemented with XREP :) >> Pub/Sub: >> 1. Weak reliability guarantees > > Isn't that part of what PUB/SUB implies though. > >> 2. Lack of a way to know when message stream was broken > > I have mixed feelings about this. I *really* like that zeromq is > connectionless, so I am hesitant to begin putting connection logic > into it. But, at the same time, it might be nice to know this > information at times. > I don't say it should have connection semantics. Just should mark the place where stream was broken. I feel it can be done without any significant overhead > >> If someone have something to add to summary, be my guest. >> >> So let's start with simplest things. There is nothing could be done with >> reliability of publish subscribe, and probably that's ok. For broken stream >> notification it can be done by proper transport shutdown of connections, >> which was discussed a bit. I don't want to repeat myself, just say that >> shutdown is implemented in every connection oriented network protocol. >> Including few ones with implicit connections (e.g. sctp and rxrpc). It's >> interesting that sctp has no half-closed state as I proposed, but has >> notification of undelivered message. All in all I think this should be >> discussed more. > > But in my mind, zeromq is connectionless... > Well, is SCTP connectionless? > > My main concerns are complexity and performance. If you can > accomplish the above while maintaining performance and limiting > complexity, then I think it is worth pursuing. But my feeling is that > the "just use multiple sockets" pattern is hard to beat. > Well heartbeat overhead is unavoidable with this pattern. Request reply overhead is similar. For push/pull seems we need some better routing anyway, so this overhead may be will be compensated by better load balancing. > One thing that would be nice, is to allow multiple zeromq socket to > run through a single TCP socket. that would really help the growth of > TCP connections in these architectures. > Well, this quite contradicts my point. I like to use different TCP ports even if zmq socket same. This helps monitor traffic better. And I've thought the only overhead of lots of TCP connections is connection initiation overhead, which zeromq doesn't do most of the time. What's your experience? -- Paul _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
