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

[Martin Sustrik]

On 03/22/2011 11:20 PM, Martin Lucina wrote:
> 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?

See following issues: 3, 4, 19, 26.

>> 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()?

My point was that 0MQ API is transport agnostic. Ie. it allows you to 
switch from one transport to another by simply changing the connection 
string with no additional changes to the codebase. To keep this feature 
we should think about what would happen to the code using auto-assigned 
ports if you switch it to e.g. inproc, etc.

Martin