[zeromq-dev] identity bug

[Martin Sustrik]

Serge,

>> Currently the complain is realised using the assertion above. However,
>> it should be made more user-friendly. Presumably, client should drop the
>> connection, write a warning to the system log and try reconnecting
>> again, just in case the XYZ gets online again.
>>
> 
> At least it would be a much more consistent behavior with the exception 
> of writing a warning to a system log.
> 
> I don't think it's currently possible, but I'll ask anyway - in the 
> absence of callbacks, is there any way for 0MQ socket to receive 
> out-of-band error events?

No. There's no way. The point is that when you start annoying user with 
single-connection-specific events the whole abstraction model of 0MQ 
breaks down. Eventually, you would end with what would equal to raw BSD 
sockets.

> Since 0MQ is a library, creating side effects such as writing something 
> to a log is not a very good idea - it's much better to provide some form 
> of control to the upper layer in terms of error handling.

Same with me. However, I haven't thought of any sane alternative so far.

Maybe a context-provided inproc PUB endpoint you can be subscribe to and 
receive error messages that way?

> P.S. BTW, you mentioned that you wrote something on callbacks to the 
> mailing list, could you point me to that email?  I couldn't find 
> anything meaningful when searched for 
> http://search.gmane.org/?query=callback&group=gmane.network.zeromq.devel

I cannot find it myself...

Anyway:

1. The API should be agnostic about how the underlying implementation 
looks like. What if we choose to move it to kernel space? No callbacks 
from kernel threads to user space I am afraid.

2. There's no thread to execute the callbacks. There are I/O threads 
that do their work and shouldn't be blocked by calling back 
user-supplied functions. Then there are application threads which are 
under users control and thus unavailable for 0MQ to invoke callbacks.

3. The ultimate goal is to integrate 0MQ API with POSIX socket API. 
There are no callbacks nin POSIX socket API.

4. Invoking callbacks from worker threads re-introduces the very thing 
0MQ tries to avoid -- inter-thread synchronisation. Have a look at 
"multithreading magic" blog entry on zeromq.org.

5. Real men prefer to be in control rather than being controlled. 
Therefore they don't like callbacks. For quiche-eaters it's easy to 
create a wrapper that would translate received messages into callbacks.

Martin