na2ni: add ZeroMQ output

[lars18th]

Hi,

The current implementation of the tool na2ni lacks the ZeroMQ output.
So, in order to have the option to interchange the tools (na2ni with edi2eti) will be desirable to support also this other output.

Example: usage: ./na2ni [--no-fec] [-i <inputfile>] [-o <outputfile|zeromq-uri>]

It has sense? You agree?

[piratfm]

Yep, that makes sense. ZeroMQ will be in server mode, so few modulators/players can connect to it and play that stream.

[lars18th]

Hi @piratfm ,

Yep, that makes sense.

Great to hear it! 😄

ZeroMQ will be in server mode

However, why only "server" mode? I feel it be more beneficial to have "client" and "server" options:

• In server mode different clients can connect.
• In client mode it can push (like now does edi2eti) to any modulator/player.

So, I suggest to first replicate the same functionality already implemented in edi2eti, and then expand it to the "server mode" (in both tools). You agree?

[piratfm]

In client mode it can push

It can't.

[lars18th]

Hi @piratfm ,

In client mode it can push

It can't.

Jus to know it... why not? It's not doing in this way the edi2eti tool? What's the difference?

Note: I don't say to use ZMQ_PUSH. I know it's ZMQ_PUB all the time. My sense it's about to use "connecting" mode instead of "bind" mode. I feel the current implementation of edi2eti uses "connecting" mode plus ZMQ_PUB. Right? ¡NO!

Note 2: Oh, yes! I see it now! http://github.com/piratfm/eti-tools/blob/master/edi2eti.c#L272. This tools uses "bind" mode, not "connect" mode (aka "zmq_connect()"). So, why not support both modes? The tool ni2http uses "connect" to send the bitstream to an ODR-DabMUX server. So, it will be desirable to use too edi2eti and na2ni to do same. I'm right?

[piratfm]

ni2http uses connect method because it's connecting to ODR-DabMux (which uses bind mode) and can stream single station to Your own multiplexor, so it's re-multiplexing feature.

The ODR-DabMUX - uses bind mode fo both input and outputs, because it's some kind of central unit for producing ETI signal.
So all connection to MUX must work in client mode. edi2eti emulating ODR-DabMUX, as well as na2ni may do that (so they will be server's). But adding unneeded features, like choosing what to use, client or server - is against KISS policy. So If You want to make more complicated things, You can make Your fork with all features needed in Your environment.

[lars18th]

Hi @piratfm ,

But adding unneeded features is against KISS policy.

I don't like to propose unneeded features. Your "eti-tools" are useful for a lot of projects. My proposal is only related to support both "connect" and "bind" modes because this has a lot flexibility about the other end.

However, I don't want to produce any interference in your work. Please, implement what you prefer.
I hope only that you will appreciate my suggestions.

[piratfm]

BTW, new eti2zmq can add this functionality as part of pipeline.