[zeromq-dev] Can't bind same ZMQ_UP/DOWNSTREAM multiple times.

[Matt Weinstein]

I shouldn't be throwing more work over the transom, since everyone is  
110% occupied, so this is more food for thought...

It's beginning to look like a formal requirements doc, with phases,  
would be worth bandying about.

That way we can prioritize, and push the very difficult problems back.

In particular we're hearing from various Stakeholders with requests  
for everything from stream recovery to persistence to ...

What's the best way to capture the requirements?

BTW, I usually use a medium- or lite- methodology for this (precursor  
to Rational, relative of Crystal...):

	Project Inception Doc (Framework) > Stakeholder Analysis
	> CRC Analysis > Architecture Doc
	> Phased Project Plan > Implementation

This just looks like it needs something :-)


RSVP,

Best,

Matt

On Aug 19, 2010, at 8:19 AM, Martin Sustrik wrote:

> Oliver,
>
>> Problem is, someone has to bind the address for anyone to be able to
>> talk to it.
>>
>> See the attached diagram (sorry for slopping drawing, no mouse :-)
>>
>> Circles = endpoints, oblongs = workers.
>>
>> Right now, to implement the "mid" endpoint, you either need a  
>> device or
>> a device-like concentrator (a worker that binds an address and allows
>> the workers on the right to connect to it, and then forwards messages
>> from the left to the right).
>>
>> Which is, essentially, duplicating lots of work.
>
> Binding several sockets to a TCP port to get a multicast delivery is
> something TCP doesn't support. You'll either have to do with a  
> device in
> the middle or use IP multicast (via PGM) which effectively turns your
> switch into the device. Using IP multicast has its own set of problems
> though.
>
> Martom
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev