Re: [zeromq-dev] Multiplexing a TCP endpoint

2016-02-15 Thread Pieter Hintjens
..@lists.zeromq.org] On Behalf Of Alex Bligh > Sent: 11 February 2016 12:22 > To: ZeroMQ development list <zeromq-dev@lists.zeromq.org> > Cc: Alex Bligh <a...@alex.org.uk> > Subject: Re: [zeromq-dev] Multiplexing a TCP endpoint > > > On 10 Feb 2016, at 19:11, Tom Quare

Re: [zeromq-dev] Multiplexing a TCP endpoint

2016-02-15 Thread Tom Quarendon
mq-dev-boun...@lists.zeromq.org] On Behalf Of Alex Bligh Sent: 11 February 2016 12:22 To: ZeroMQ development list <zeromq-dev@lists.zeromq.org> Cc: Alex Bligh <a...@alex.org.uk> Subject: Re: [zeromq-dev] Multiplexing a TCP endpoint On 10 Feb 2016, at 19:11, Tom Quarendon <tom.quaren

Re: [zeromq-dev] Multiplexing a TCP endpoint

2016-02-11 Thread Alex Bligh
On 10 Feb 2016, at 19:11, Tom Quarendon wrote: > This is what "resources" in ZMTP 3.1 were designed for. No implementation yet > though (see other discussion on his list) :-) Thanks. That is pretty much exactly what I was looking for (other than the 'no

Re: [zeromq-dev] Multiplexing a TCP endpoint

2016-02-10 Thread Tom Quarendon
This is what "resources" in ZMTP 3.1 were designed for. No implementation yet though (see other discussion on his list) :-) You would have to write the proxy loop yourself. So do a select on the external socket and all the internal sockets and know that when you pull a message from the

Re: [zeromq-dev] Multiplexing a TCP endpoint

2016-02-10 Thread Michal Vyskocil
Hi, In case you want to play even more, there is malamute broker. It can listen in tcp socket and you can filter incoming messages per stream or subject. The disadvantage is you must use mlm client API to make it work. However sounds like right tool for your use case. Dne 10. 2. 2016 8:12 PM

Re: [zeromq-dev] Multiplexing a TCP endpoint

2016-02-10 Thread ozamiatin
Hi, Alex 10.02.16 19:23, Alex Bligh пишет: > I am investigating building a zeromq-based application which runs over TCP. > It will run many separate services over zeromq, mostly REP/REQ (via proxies), > but also PUB/SUB. > > The normal way to do this as far as I can tell is to use one TCP port