Hi Paul.I *really* want to keep user interface and administrative interface separated. As seen with ZeroMQ, if you publish monitoring data about connections via user API, users will immediately start using it to find out about internal connects/disconnects and implement their own, not well though out, reliability logic.
I believe the monitoring should be done via IPC. The library would connect to a well knows IPC address (/tmp/nn-monitor.ipc or similar) and send the state there.
Martin On 13/09/13 22:05, Paul Colomiets wrote:
Hi, Let's try another API for statistics: uint64_t stat[NN_STAT_NUM]; nn_getsockopt(sock, NN_SOL_SOCKET, NN_STATISTICS, &stat, sizeof(stat)); printf("stat: %d\n", stat[NN_STAT_MSGCOUNTER]); Note: we have nn_symbol to iterate over symbols, that may be used to enumerate NN_STAT_* constants. To be able to find out a reason for asynchronous errors, we should provide an option similar to SO_ERROR in posix: int err; nn_getsockopt(sock, NN_SOL_SOCKET, NN_ERROR, &err, sizeof(err)); Pros: 1. Keping nanomsg simpler 2. No need to agree on socket names, it's left up to the application Cons: 1. More work to integrate in each app 2. Everybody will use it's own version 3. Statistics may be accessed from separate thread, so options should be lock-free (shouldn't be a problem looking at the code). (Note: first two cons may be addressed by reference implementation outside of nanomsg itself) Thoughts?