For further clarification, the end goal would be to: 1) Support the use of NORM as alternative for unicast wherever TCP can currently be used 2) Support the connection-oriented NORM "socket" hub and spoke multicast publish with subscribers having a unicast connection back to the published 3) Eventually broaden/refine the NORM protocol configuration options available via ZMQ APIs
#2 enables the NORM publisher to be more explicitly aware of the subscriber list, their status, and (I think) their topic(s) of interest. This also allows for NORM explicit ack-based flow control to be used in conjunction with congestion control and allow for more assured delivery than the default purely NACK-based paradigm of NORM (Enabling/disabling that ACK-based flow control is one of the configuration options we will want to make available) On 3/28/22, 8:59 AM, "Bowers, Caleb Z CIV USN NRL (5522) Washington DC (USA)" <[email protected]> wrote: Yeah, zmq would provide the sockets to use, so I can use zmq messaging primitives/patterns. NORM would be the underlying transport protocol. I have used NORM in ZMQ for basic multicast all-to-all comms: https://ieeexplore.ieee.org/document/9653084 I want to expand on this to add in some of the additional components of NORM for more structured communication patterns. NORM has modes that allow client/server like connections with multicast transmit channels and unicast feedback channels. Essentially the tcp listener/connecters do this for tcp, but of course, all unicast. On 3/25/22, 8:00 AM, "zeromq-dev on behalf of [email protected]" <[email protected] on behalf of [email protected]> wrote: Send zeromq-dev mailing list submissions to [email protected] To subscribe or unsubscribe via the World Wide Web, visit https://lists.zeromq.org/mailman/listinfo/zeromq-dev or, via email, send a message with subject or body 'help' to [email protected] You can reach the person managing the list at [email protected] When replying, please edit your Subject line so it is more specific than "Re: Contents of zeromq-dev digest..." Today's Topics: 1. Re: Imitating TCP Listener/Connecter for NORM (Arnaud Loonstra) ---------------------------------------------------------------------- Message: 1 Date: Fri, 25 Mar 2022 11:16:05 +0100 From: Arnaud Loonstra <[email protected]> To: [email protected] Subject: Re: [zeromq-dev] Imitating TCP Listener/Connecter for NORM Message-ID: <[email protected]> Content-Type: text/plain; charset=UTF-8; format=flowed On 23-03-2022 19:09, Bowers, Caleb Z CIV USN NRL (5522) Washington DC (USA) via zeromq-dev wrote: > I am interested in imitating the TCP listener/connecter setup for the multicast protocol NORM. There is a mode of NORM that enables multicast out and unicast backchannels. E.g., a hub and spoke topology where the hub multicasts to the nodes and those nodes can unicast back to the hub along the spokes. > > This being the case, I think there is reasonable chance of implementing something similar to the TCP/IPC, etc listener/connecter patterns. > > The code for these is not particularly well documented and I am not sure where/if an API is located. Are there any references I can consult in undertaking this? > > Thanks, > > Caleb Bowers I'm not sure I follow you on this. Do you want to build this hub-spoke topology using zeromq sockets or do you want to build this using a NORM implementation, aka a new or enhanced transport? Rg, Arnaud ------------------------------ Subject: Digest Footer _______________________________________________ zeromq-dev mailing list [email protected] https://lists.zeromq.org/mailman/listinfo/zeromq-dev ------------------------------ End of zeromq-dev Digest, Vol 70, Issue 8 *****************************************
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ zeromq-dev mailing list [email protected] https://lists.zeromq.org/mailman/listinfo/zeromq-dev
