No apologies, I wasn't aiming to be critical. It's just that the thinking process happens best by making working code and then improving it. If you have specific questions others can help. With larger architectural questions, you won't often get answers here.
On Mon, Jan 12, 2015 at 3:43 PM, Kenneth Adam Miller <kennethadammil...@gmail.com> wrote: > Oh I apologize. I was just asking if what I was thinking of was possible > with zeromq. > > On Mon, Jan 12, 2015 at 4:29 AM, Pieter Hintjens <p...@imatix.com> wrote: >> >> > In any case, does what I am thinking about work? >> >> It's usually a good idea to make small pieces, and grow your >> understanding of your problem and alternative solutions like that. >> No-one here can do that for you. >> >> On Mon, Jan 12, 2015 at 7:31 AM, Kenneth Adam Miller >> <kennethadammil...@gmail.com> wrote: >> > Instead of routing all information through the broker and requiring an >> > intermediary hop, I'd like to consider an approach where the address >> > information that the req socket parses out on the side that first sends >> > ready is used in order to manage a simple mutual connection facilitator >> > in >> > ZMQ... >> > >> > Just like with load balancing broker from the manual, I have two parties >> > that mutually require one another. But I want to do simply a request to >> > the >> > broker and receive the information I need in order to send directly to >> > the >> > other entity. >> > >> > With router sockets, I get the address in a empty delimited set of >> > message >> > sending convention. What I don't know is if I add a router socket to >> > each >> > mutually requiring party, and -even if party A is not connected even to >> > party B- use the address information attained from the broker to send on >> > party A's router socket to party B and vice versa. Is this the best way >> > to >> > do this? I don't want to manage a set of connected sockets. >> > >> > I realize that party A may have individual 1 and party B an individual 2 >> > where 1 & 2 repeatedly make connection over broker-I want to keep using >> > broker anyway, because broker allows each party to know when an >> > individual >> > is ready in each. So the 1& 2 scenario is coincidental. >> > >> > But what I don't think is a good design idea is having a socket that >> > makes >> > connect/close calls between each iteration to the broker or the idea of >> > having each endpoint know it's hostname or something (possibly I have >> > premature misgivings). >> > >> > In any case, does what I am thinking about work? Reading the target >> > address >> > information gained from a router object and feeding it to a completely >> > different router object (where individual 1 may not have ever had his >> > router >> > connected to individual 2 before)? >> > >> > _______________________________________________ >> > zeromq-dev mailing list >> > zeromq-dev@lists.zeromq.org >> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev >> > >> _______________________________________________ >> zeromq-dev mailing list >> zeromq-dev@lists.zeromq.org >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev > > > > _______________________________________________ > zeromq-dev mailing list > zeromq-dev@lists.zeromq.org > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > _______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
