[zeromq-dev] Important: backward incompatible changes for 0MQ/3.0!

[Martin Lucina]

sustrik at 250bpm.com said:
> On 03/22/2011 10:40 PM, Martin Lucina wrote:
> 
> >> 10. I would like to remove ZMQ_PAIR pattern altogether, however, Pieter
> >> uses it in the guide, so he proposes to instead limit it to inproc
> >> transport which is the only use case there. Please, if you are using
> >> PAIR, whether over inproc or tcp or whatever, scream now!
> >
> > The alternative I presume is to fix PAIR sockets? I.e. implement
> > auto-reconnect and all the other missing bits?
> 
> Well, if people do want PAIR to remain in the library, I'll leave it 
> there. I am not interested in fixing it myself though. Others are free 
> to patch it, of course.

How much work is there remaining to actually fix it? We're not talking
weeks, more like days, right? What is actually missing apart from
auto-reconnect?

> 
> > I would like to add at least one feature discussed before (AFAIK the IPython
> > people are using this heavily and are emulating it with a hack, I've also
> > done this for clients), namely to allow "bind to random port".
> >
> > This requires an API change (getting the resulting endpoint back from the
> > bind call), I'm not yet sure what that API should look like but I'll make
> > the note here and on the Wiki page so that we don't forget about it.
> 
> Ah. I forgot about that one. I am not sure about it though. How would it 
> work with non-TCP transports? 

It'd work for those transports where the underlying transport supports it.
At first thought this includes TCP and UDP (if we had such a transport).

> Are we actually speaking of automatic 
> endpoint generation? If so, how can we avoid auto-assigned endpoints 
> clashing with user-defined endpoints etc. The whole thing seems rather 
> complex and messy.

No, I think you're confusing the issue. I'm talking about (it's been a
while since I did this, so I may have it wrong) the case where you:

1) pass a sockaddr_in.port of 0 to a bind() call for a TCP or UDP socket.
2) call getsockname() to retrieve the actual port number the system
assigned.

So the free port is assigned by the OS, not "generated" by 0MQ.

I need to check when I'm in the office (Thursday) that that's the way it's
actually done... If so then maybe we can do it with a getsockopt()?

-mato