kakyo
kakyo

Reputation: 11590

Can I mix a ZeroMQ TCP/UDP server with a regular BSD TCP/UDP socket client?

Can I start a ZeroMQ TCP/UDP server and communicate with it using a regular BSD TCP/UDP socket client?

I have a few machines talking to each other, some depending on libraries with low-level socket clients that are otherwise hard to migrate to ZMQ.

Upvotes: 0

Views: 973

Answers (2)

Arnaud Loonstra
Arnaud Loonstra

Reputation: 139

Nowadays ZeroMQ also supports DGRAM. See here: zmq_udp.txt. So besides regular TCP there's also regular UDP.

Upvotes: 0

user3666197
user3666197

Reputation: 1

Q : "Can I start a ZeroMQ TCP/UDP server and communicate with it using a regular BSD TCP/UDP socket client?"

A : Yes, but...

Well, there is nothing like a "TCP/UDP server" in ZeroMQ. ZeroMQ uses high-level behaviour archetypes { PUSH/PULL | PUB/SUB | REQ/REP | ... | PAIR/PAIR }, for which one may choose one or more ( yes, a PUB sender may get delivered messages to all of vmci:// and ipc:// and pgm:// and tcp:// SUB-agents at the same "socket"-archetype at once ) transport-classes, right due to the fact, that the abstracted transport-class data-pumps are the hidden but "specialised" component that handle all the hidden, low-level details - each one a bit different, for serving each particular transport-class as needed with individual data-pumps' transport-class-specific details :
{ inproc:// | ipc:// | tipc:// | tcp:// | pgm:// | epgm:// | norm:// | vmci:// }.


Yet, there is a "special" Socket-archetype that may "talk" to non-ZeroMQ counterparties, thus can serve the needs right for you:

ZMQ_STREAM

A socket of type ZMQ_STREAM is used to send and receive TCP data from a non-ØMQ peer, when using the tcp:// transport. A ZMQ_STREAM socket can act as client and/or server, sending and/or receiving TCP data asynchronously.

When receiving TCP data, a ZMQ_STREAM socket shall prepend a message part containing the routing id of the originating peer to the message before passing it to the application. Messages received are fair-queued from among all connected peers.

When sending TCP data, a ZMQ_STREAM socket shall remove the first part of the message and use it to determine the routing id of the peer the message shall be routed to, and unroutable messages shall cause an EHOSTUNREACH or EAGAIN error.

To open a connection to a server, use the zmq_connect call, and then fetch the socket routing id using the zmq_getsockopt() call with the ZMQ_ROUTING_ID option.

To close a specific connection, send the routing id frame followed by a zero-length message.

When a connection is made, a zero-length message will be received by the application. Similarly, when the peer disconnects (or the connection is lost), a zero-length message will be received by the application.

You must send one routing id frame followed by one data frame. The ZMQ_SNDMORE flag is required for routing id frames but is ignored on data frames.

Just be aware of the fair-queue handling of all the ZMQ_STREAM connected peers on incoming direction.

Upvotes: 1

Related Questions