Reputation: 23
My purpose is to create dynamically some ZeroMQ sockets (peer-peer) in C.
I have one listen socket in my server and when a client sends a message I attribute a new port and create a connection with this new port and I return on my listen socket.
Ex:
What type of ZeroMQ function should I use?
I was thinking about FD and select but maybe not compatible with ZeroMQ or of zmq_poll()
, but it's confused in my mind.
Upvotes: 2
Views: 696
Reputation: 1
Well, the scenario above will definitely use many functions for achieving that, yet the approach will depend on which native API version do you decide to use, which depends on what population of remote-agents would you like to let-in, let's assume a minimum level of 2.1+.
Server side will most probably use all of these:
- version self-check: zmq_version()
- context instantiation: zmq_init()
- context parametrisation: not present in all native API versions, check API docs
- socket instantiation: zmq_socket()
- socket setup: zmq_setsockopt()
- socket transport-class lock-in on an infrastructure element zmq_bind( { inproc://...| ipc://...| tcp://...:# | pgm://...:# | epgm://...:# | vmci://... } )
vmci://
transport-class not being present in all native API-versions
- message resources and state-management operations [ zmq_msg_init(), zmq_msg_copy(), ..., zmq_msg_close() ]
- socket "reading", best non-blocking, with a pre-"sniffing" poll zmq_recv()
+ zmq_poll()
- socket "sending", best non-blocking zmq_send()
- local "event"-loop with checking also zmq_errno()
for a presence of error(s) and zmq_strerror()
to make it a bit more human-readable
- socket resources release: zmq_close()
- context resources release: zmq_term()
Client side will most probably use all of these:
- version self-check: zmq_version()
- context instantiation: zmq_init()
- context parametrisation: not present in all native API versions, check API docs
- socket instantiation: zmq_socket()
- socket setup: zmq_setsockopt()
- socket transport-class attempt to zmq_connect()
local side to an exposed remote infrastructure element's Access Point using respective transport-class matching parameters { inproc://...| ipc://...| tcp://...:# | pgm://...:# | epgm://...:# | vmci://... } )
vmci://
transport-class not being present in all native API-versions
- message resources and state-management operations [ zmq_msg_init(), zmq_msg_copy(), ..., zmq_msg_close() ]
- socket "reading", best non-blocking, with a pre-"sniffing" poll zmq_recv()
+ zmq_poll()
- socket "sending", best non-blocking zmq_send()
- local "event"-loop with checking also zmq_errno()
for a presence of error(s) and zmq_strerror()
to make it a bit more human-readable
- socket resources release: zmq_close()
- context resources release: zmq_term()
The best place to start - if indeed willing to dive into the professional distributed-system's design is to understand a Zen-of-Zero, as lovely presented in Pieter HINTJENS' book "Code Connected, Volume 1". Not an easy read, but worth time and efforts to start with.
Upvotes: 1