Package org.zeromq

Enum SocketType

  • All Implemented Interfaces:
    java.io.Serializable, java.lang.Comparable<SocketType>

    public enum SocketType
    extends java.lang.Enum<SocketType>
    Socket Type enumeration
    • Enum Constant Summary

      Enum Constants 
      Enum Constant Description
      CHANNEL
      Flag to specify CHANNEL socket.
      CLIENT
      Flag to specify CLIENT socket.
      DEALER
      Flag to specify a DEALER socket (aka XREQ).
      DISH
      Flag to specify DISH socket.
      GATHER
      Flag to specify GATHER socket.
      PAIR
      Flag to specify a exclusive pair of sockets.
      PEER
      Flag to specify PEER socket.
      PUB
      Flag to specify a PUB socket, receiving side must be a SUB or XSUB.
      PULL
      Flag to specify the receiving part of a PUSH socket.
      PUSH
      Flag to specify a PUSH socket, receiving side must be a PULL.
      RADIO
      Flag to specify RADIO socket.
      RAW
      Flag to specify RAW socket.
      REP
      Flag to specify the receiving part of a REQ or DEALER socket.
      REQ
      Flag to specify a REQ socket, receiving side must be a REP or ROUTER.
      ROUTER
      Flag to specify ROUTER socket (aka XREP).
      SCATTER
      Flag to specify SCATTER socket.
      SERVER
      Flag to specify SERVER socket.
      STREAM
      Flag to specify a STREAM socket.
      SUB
      Flag to specify the receiving part of the PUB or XPUB socket.
      XPUB
      Flag to specify a XPUB socket, receiving side must be a SUB or XSUB.
      XSUB
      Flag to specify the receiving part of the PUB or XPUB socket.
    • Field Summary

      Fields 
      Modifier and Type Field Description
      int type  
    • Constructor Summary

      Constructors 
      Modifier Constructor Description
      private SocketType​(int socketType)  
    • Method Summary

      All Methods Static Methods Instance Methods Concrete Methods 
      Modifier and Type Method Description
      int type()  
      static SocketType type​(int baseType)  
      static SocketType valueOf​(java.lang.String name)
      Returns the enum constant of this type with the specified name.
      static SocketType[] values()
      Returns an array containing the constants of this enum type, in the order they are declared.
      • Methods inherited from class java.lang.Enum

        clone, compareTo, equals, finalize, getDeclaringClass, hashCode, name, ordinal, toString, valueOf
      • Methods inherited from class java.lang.Object

        getClass, notify, notifyAll, wait, wait, wait
    • Enum Constant Detail

      • PAIR

        public static final SocketType PAIR

        Flag to specify a exclusive pair of sockets.

        A socket of type PAIR can only be connected to a single peer at any one time.
        No message routing or filtering is performed on messages sent over a PAIR socket.
        When a PAIR socket enters the mute state due to having reached the high water mark for the connected peer, or if no peer is connected, then any send() operations on the socket shall block until the peer becomes available for sending; messages are not discarded.

        Summary of socket characteristics
        Compatible peer socketsPAIR
        DirectionBidirectional
        Send/receive patternUnrestricted
        Incoming routing strategyN/A
        Outgoing routing strategyN/A
        Action in mute stateBlock

        PAIR sockets are designed for inter-thread communication across the inproc transport and do not implement functionality such as auto-reconnection. PAIR sockets are considered experimental and may have other missing or broken aspects.

      • PUB

        public static final SocketType PUB

        Flag to specify a PUB socket, receiving side must be a SUB or XSUB.

        A socket of type PUB is used by a publisher to distribute data.
        Messages sent are distributed in a fan out fashion to all connected peers.
        The ZMQ.Socket.recv() function is not implemented for this socket type.
        When a PUB socket enters the mute state due to having reached the high water mark for a subscriber, then any messages that would be sent to the subscriber in question shall instead be dropped until the mute state ends.
        The send methods shall never block for this socket type.

        Summary of socket characteristics
        Compatible peer socketsZMQ.SUB, ZMQ.XSUB
        DirectionUnidirectional
        Send/receive patternSend only
        Incoming routing strategyN/A
        Outgoing routing strategyFan out
        Action in mute stateDrop
      • SUB

        public static final SocketType SUB

        Flag to specify the receiving part of the PUB or XPUB socket.

        A socket of type SUB is used by a subscriber to subscribe to data distributed by a publisher.
        Initially a SUB socket is not subscribed to any messages, use the ZMQ.Socket.subscribe(byte[]) option to specify which messages to subscribe to.
        The send methods are not implemented for this socket type.

        Summary of socket characteristics
        Compatible peer socketsZMQ.PUB, ZMQ.XPUB
        DirectionUnidirectional
        Send/receive patternReceive only
        Incoming routing strategyFair-queued
        Outgoing routing strategyN/A
      • REQ

        public static final SocketType REQ

        Flag to specify a REQ socket, receiving side must be a REP or ROUTER.

        A socket of type REQ is used by a client to send requests to and receive replies from a service.
        This socket type allows only an alternating sequence of send(request) and subsequent recv(reply) calls.
        Each request sent is round-robined among all services, and each reply received is matched with the last issued request.
        If no services are available, then any send operation on the socket shall block until at least one service becomes available.
        The REQ socket shall not discard messages.

        Summary of socket characteristics
        Compatible peer socketsZMQ.REP, ZMQ.ROUTER
        DirectionBidirectional
        Send/receive patternSend, Receive, Send, Receive, ...
        Incoming routing strategyLast peer
        Outgoing routing strategyRound-robin
        Action in mute stateBlock
      • REP

        public static final SocketType REP

        Flag to specify the receiving part of a REQ or DEALER socket.

        A socket of type REP is used by a service to receive requests from and send replies to a client.
        This socket type allows only an alternating sequence of recv(request) and subsequent send(reply) calls.
        Each request received is fair-queued from among all clients, and each reply sent is routed to the client that issued the last request.
        If the original requester does not exist any more the reply is silently discarded.

        Summary of socket characteristics
        Compatible peer socketsZMQ.REQ, ZMQ.DEALER
        DirectionBidirectional
        Send/receive patternReceive, Send, Receive, Send, ...
        Incoming routing strategyFair-queued
        Outgoing routing strategyLast peer
      • DEALER

        public static final SocketType DEALER

        Flag to specify a DEALER socket (aka XREQ).

        DEALER is really a combined ventilator / sink that does load-balancing on output and fair-queuing on input with no other semantics. It is the only socket type that lets you shuffle messages out to N nodes and shuffle the replies back, in a raw bidirectional asynch pattern.
        A socket of type DEALER is an advanced pattern used for extending request/reply sockets.
        Each message sent is round-robined among all connected peers, and each message received is fair-queued from all connected peers.
        When a DEALER socket enters the mute state due to having reached the high water mark for all peers, or if there are no peers at all, then any send() operations on the socket shall block until the mute state ends or at least one peer becomes available for sending; messages are not discarded.
        When a DEALER socket is connected to a ZMQ.REP socket each message sent must consist of an empty message part, the delimiter, followed by one or more body parts.

        Summary of socket characteristics
        Compatible peer socketsZMQ.ROUTER, ZMQ.REP, ZMQ.DEALER
        DirectionBidirectional
        Send/receive patternUnrestricted
        Incoming routing strategyFair-queued
        Outgoing routing strategyRound-robin
        Action in mute stateBlock
      • ROUTER

        public static final SocketType ROUTER

        Flag to specify ROUTER socket (aka XREP).

        ROUTER is the socket that creates and consumes request-reply routing envelopes. It is the only socket type that lets you route messages to specific connections if you know their identities.
        A socket of type ROUTER is an advanced socket type used for extending request/reply sockets.
        When receiving messages a ROUTER socket shall prepend a message part containing the identity 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 messages a ROUTER socket shall remove the first part of the message and use it to determine the identity of the peer the message shall be routed to. If the peer does not exist anymore the message shall be silently discarded by default, unless ZMQ.Socket.setRouterMandatory(boolean) socket option is set to true.
        When a ROUTER socket enters the mute state due to having reached the high water mark for all peers, then any messages sent to the socket shall be dropped until the mute state ends.
        Likewise, any messages routed to a peer for which the individual high water mark has been reached shall also be dropped, unless ZMQ.Socket.setRouterMandatory(boolean) socket option is set to true.
        When a ZMQ.REQ socket is connected to a ROUTER socket, in addition to the identity of the originating peer each message received shall contain an empty delimiter message part.
        Hence, the entire structure of each received message as seen by the application becomes: one or more identity parts, delimiter part, one or more body parts.
        When sending replies to a REQ socket the application must include the delimiter part.

        Summary of socket characteristics
        Compatible peer socketsZMQ.DEALER, ZMQ.REQ, ZMQ.ROUTER
        DirectionBidirectional
        Send/receive patternUnrestricted
        Incoming routing strategyFair-queued
        Outgoing routing strategySee text
        Action in mute stateDrop (See text)
      • PULL

        public static final SocketType PULL

        Flag to specify the receiving part of a PUSH socket.

        A socket of type ZMQ_PULL is used by a pipeline node to receive messages from upstream pipeline nodes.
        Messages are fair-queued from among all connected upstream nodes.
        The send() function is not implemented for this socket type.

        Summary of socket characteristics
        Compatible peer socketsZMQ.PUSH
        DirectionUnidirectional
        Send/receive patternReceive only
        Incoming routing strategyFair-queued
        Outgoing routing strategyN/A
        Action in mute stateBlock
      • PUSH

        public static final SocketType PUSH

        Flag to specify a PUSH socket, receiving side must be a PULL.

        A socket of type PUSH is used by a pipeline node to send messages to downstream pipeline nodes.
        Messages are round-robined to all connected downstream nodes.
        The recv() function is not implemented for this socket type.
        When a PUSH socket enters the mute state due to having reached the high water mark for all downstream nodes, or if there are no downstream nodes at all, then any send() operations on the socket shall block until the mute state ends or at least one downstream node becomes available for sending; messages are not discarded.

        Summary of socket characteristics
        Compatible peer socketsZMQ.PULL
        DirectionUnidirectional
        Send/receive patternSend only
        Incoming routing strategyN/A
        Outgoing routing strategyRound-robin
        Action in mute stateBlock
      • XPUB

        public static final SocketType XPUB

        Flag to specify a XPUB socket, receiving side must be a SUB or XSUB.

        Subscriptions can be received as a message. Subscriptions start with a '1' byte. Unsubscriptions start with a '0' byte.
        Same as ZMQ.PUB except that you can receive subscriptions from the peers in form of incoming messages.
        Subscription message is a byte '1' (for subscriptions) or byte '0' (for unsubscriptions) followed by the subscription body.
        Messages without a sub/unsub prefix are also received, but have no effect on subscription status.

        Summary of socket characteristics
        Compatible peer socketsZMQ.SUB, ZMQ.XSUB
        DirectionUnidirectional
        Send/receive patternSend messages, receive subscriptions
        Incoming routing strategyN/A
        Outgoing routing strategyFan out
        Action in mute stateDrop
      • XSUB

        public static final SocketType XSUB

        Flag to specify the receiving part of the PUB or XPUB socket.

        Same as ZMQ.SUB except that you subscribe by sending subscription messages to the socket.
        Subscription message is a byte '1' (for subscriptions) or byte '0' (for unsubscriptions) followed by the subscription body.
        Messages without a sub/unsub prefix may also be sent, but have no effect on subscription status.

        Summary of socket characteristics
        Compatible peer socketsZMQ.PUB, ZMQ.XPUB
        DirectionUnidirectional
        Send/receive patternReceive messages, send subscriptions
        Incoming routing strategyFair-queued
        Outgoing routing strategyN/A
        Action in mute stateDrop
      • STREAM

        public static final SocketType STREAM

        Flag to specify a STREAM socket.

        A socket of type STREAM is used to send and receive TCP data from a non-ØMQ peer, when using the tcp:// transport. A STREAM socket can act as client and/or server, sending and/or receiving TCP data asynchronously.
        When receiving TCP data, a STREAM socket shall prepend a message part containing the identity 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 STREAM socket shall remove the first part of the message and use it to determine the identity 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.Socket.connect(String) call, and then fetch the socket identity using the ZMQ.Socket.getIdentity() call. To close a specific connection, send the identity 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. The ZMQ.SNDMORE flag is ignored on data frames. You must send one identity frame followed by one data frame.
        Also, please note that omitting the SNDMORE flag will prevent sending further data (from any client) on the same socket.

        Summary of socket characteristics
        Compatible peer socketsnone
        DirectionBidirectional
        Send/receive patternUnrestricted
        Incoming routing strategyFair-queued
        Outgoing routing strategySee text
        Action in mute stateEAGAIN
      • CLIENT

        public static final SocketType CLIENT

        Flag to specify CLIENT socket.

        The CLIENT socket type talks to one or more SERVER peers. If connected to multiple peers, it scatters sent messages among these peers in a round-robin fashion. On reading, it reads fairly, from each peer in turn. It is reliable, insofar as it does not drop messages in normal cases.

        If the CLIENT socket has established a connection, send operations will accept messages, queue them, and send them as rapidly as the network allows. The outgoing buffer limit is defined by the high water mark for the socket. If the outgoing buffer is full, or if there is no connected peer, send operations will block, by default. The CLIENT socket will not drop messages.

        CLIENT sockets are threadsafe. They do not accept the ZMQ_SNDMORE option on sends not ZMQ_RCVMORE on receives. This limits them to single part data. The intention is to extend the API to allow scatter/gather of multi-part data.

        Summary of socket characteristics
        Compatible peer socketsSERVER
        DirectionBidirectional
        Send/receive patternUnrestricted
        Outgoing routing strategyRound Robin
        Incoming routing strategyFair-queued
        Action in mute stateBlock
      • SERVER

        public static final SocketType SERVER

        Flag to specify SERVER socket.

        The SERVER socket type talks to zero or more CLIENT peers. Each outgoing message is sent to a specific peer CLIENT. A SERVER socket can only reply to an incoming message: the CLIENT peer must always initiate a conversation.

        Each received message has a routing_id that is a 32-bit unsigned integer. To send a message to a given CLIENT peer the application must set the peer’s routing_id on the message.

        SERVER sockets are threadsafe. They do not accept the ZMQ_SNDMORE option on sends not ZMQ_RCVMORE on receives. This limits them to single part data. The intention is to extend the API to allow scatter/gather of multi-part data.

        Summary of socket characteristics
        Compatible peer socketsCLIENT
        DirectionBidirectional
        Send/receive patternUnrestricted
        Outgoing routing strategySee text
        Incoming routing strategyFair-queued
        Action in mute stateFail
      • RADIO

        public static final SocketType RADIO

        Flag to specify RADIO socket.

        The radio-dish pattern is used for one-to-many distribution of data from a single publisher to multiple subscribers in a fan out fashion. Radio-dish is using groups (vs Pub-sub topics), Dish sockets can join a group and each message sent by Radio sockets belong to a group.

        Groups are strings limited to 16 chars length (including null). The intention is to increase the length to 40 chars (including null). The encoding of groups shall be UTF8. Groups are matched using exact matching (vs prefix matching of PubSub).

        A socket of type RADIO is used by a publisher to distribute data. Each message belong to a group, a group is specified with ZFrame.setGroup(String). Messages are distributed to all members of a group. The ZMQ.Socket.recv(int) function is not implemented for this socket type.

        When a RADIO socket enters the mute state due to having reached the high water mark for a subscriber, then any messages that would be sent to the subscriber in question shall instead be dropped until the mute state ends. The ZMQ.Socket.send(byte[], int) function shall never block for this socket type.

        NOTE: RADIO sockets are threadsafe. They do not accept the ZMQ_SNDMORE option on sends. This limits them to single part data.

        Summary of socket characteristics
        Compatible peer socketsDISH
        DirectionUnidirectional
        Send/receive patternSend only
        Outgoing routing strategyFan out
        Incoming routing strategyN/A
        Action in mute stateDrop

        NOTE: RADIO is still in draft phase.

      • DISH

        public static final SocketType DISH

        Flag to specify DISH socket.

        The radio-dish pattern is used for one-to-many distribution of data from a single publisher to multiple subscribers in a fan out fashion. Radio-dish is using groups (vs Pub-sub topics), Dish sockets can join a group and each message sent by Radio sockets belong to a group.

        Groups are strings limited to 16 chars length (including null). The intention is to increase the length to 40 chars (including null). The encoding of groups shall be UTF8. Groups are matched using exact matching (vs prefix matching of PubSub).

        A socket of type DISH is used by a subscriber to subscribe to groups distributed by a radio. Initially a DISH socket is not subscribed to any groups, use ZMQ.Socket.join(String) to join a group. To get the group the message belong, call ZFrame.getGroup(). The ZMQ.Socket.send(byte[], int) function is not implemented for this socket type.

        NOTE: DISH sockets are threadsafe. They do not accept ZMQ_RCVMORE on receives. This limits them to single part data.

        Summary of socket characteristics
        Compatible peer socketsRADIO
        DirectionUnidirectional
        Send/receive patternReceive only
        Outgoing routing strategyN/A
        Incoming routing strategyFair-queued
        NOTE: DISH is still in draft phase.
      • CHANNEL

        public static final SocketType CHANNEL

        Flag to specify CHANNEL socket.

        The channel pattern is the thread-safe version of the exclusive pair pattern. The channel pattern is used to connect a peer to precisely one other peer. This pattern is used for inter-thread communication across the inproc transport.

        A socket of type 'CHANNEL' can only be connected to a single peer at any one time. No message routing or filtering is performed on messages sent over a 'CHANNEL' socket.

        When a 'CHANNEL' socket enters the 'mute' state due to having reached the high water mark for the connected peer, or, for connection-oriented transports, if the ZMQ_IMMEDIATE option is set and there is no connected peer, then any ZMQ.Socket.send(byte[], int) operations on the socket shall block until the peer becomes available for sending; messages are not discarded.

        While 'CHANNEL' sockets can be used over transports other than 'inproc', their inability to auto-reconnect coupled with the fact new incoming connections will be terminated while any previous connections (including ones in a closing state) exist makes them unsuitable for TCP in most cases.

        NOTE: 'CHANNEL' sockets are designed for inter-thread communication across the 'inproc' transport and do not implement functionality such as auto-reconnection.

        NOTE: 'CHANNEL' sockets are threadsafe. They do not accept ZMQ_RCVMORE on receives. This limits them to single part data.

        Summary of socket characteristics
        Compatible peer socketsCHANNEL
        DirectionBidirectional
        Send/receive patternUnrestricted
        Outgoing routing strategyN/A
        Incoming routing strategyN/A
        Action in mute stateBlock

        NOTE: CHANNEL is still in draft phase.

      • PEER

        public static final SocketType PEER

        Flag to specify PEER socket.

        A 'PEER' socket talks to a set of 'PEER' sockets.

        To connect and fetch the 'routing_id' of the peer use ZMQ.Socket.connectPeer(String).

        Each received message has a 'routing_id' that is a 32-bit unsigned integer. The application can fetch this with ZFrame.getRoutingId().

        To send a message to a given 'PEER' peer the application must set the peer's 'routing_id' on the message, using ZFrame.setRoutingId(int).

        If the 'routing_id' is not specified, or does not refer to a connected client peer, the send call will fail with EHOSTUNREACH. If the outgoing buffer for the peer is full, the send call shall block, unless ZMQ_DONTWAIT is used in the send, in which case it shall fail with EAGAIN. The 'PEER' socket shall not drop messages in any case.

        NOTE: 'PEER' sockets are threadsafe. They do not accept the ZMQ_SNDMORE option on sends not ZMQ_RCVMORE on receives. This limits them to single part data.

        Summary of socket characteristics
        Compatible peer socketsPEER
        DirectionBidirectional
        Send/receive patternUnrestricted
        Outgoing routing strategySee text
        Incoming routing strategyFair-queued
        Action in mute stateReturn EAGAIN
        NOTE: PEER is still in draft phase.
      • RAW

        public static final SocketType RAW

        Flag to specify RAW socket.

      • SCATTER

        public static final SocketType SCATTER

        Flag to specify SCATTER socket.

        The scatter-gather pattern is the thread-safe version of the pipeline pattern. The scatter-gather pattern is used for distributing data to nodes arranged in a pipeline. Data always flows down the pipeline, and each stage of the pipeline is connected to at least one node. When a pipeline stage is connected to multiple nodes data is round-robined among all connected nodes.

        When a 'SCATTER' socket enters the 'mute' state due to having reached the high water mark for all downstream nodes, or, for connection-oriented transports, if the ZMQ_IMMEDIATE option is set and there are no downstream nodes at all, then any ZMQ.Socket.send(byte[], int) operations on the socket shall block until the mute state ends or at least one downstream node becomes available for sending; messages are not discarded.

        NOTE: 'SCATTER' sockets are threadsafe. They do not accept ZMQ_RCVMORE on receives. This limits them to single part data.

        Summary of socket characteristics
        Compatible peer socketsGATHER
        DirectionUnidirectional
        Send/receive patternSend only
        Outgoing routing strategyRound-robin
        Incoming routing strategyN/A
        Action in mute stateBlock
        NOTE: SCATTER is still in draft phase.
      • GATHER

        public static final SocketType GATHER

        Flag to specify GATHER socket.

        The scatter-gather pattern is the thread-safe version of the pipeline pattern. The scatter-gather pattern is used for distributing data to nodes arranged in a pipeline. Data always flows down the pipeline, and each stage of the pipeline is connected to at least one node. When a pipeline stage is connected to multiple nodes data is round-robined among all connected nodes.

        A socket of type 'GATHER' is used by a scatter-gather node to receive messages from upstream scatter-gather nodes. Messages are fair-queued from among all connected upstream nodes. The ZMQ.Socket.send(byte[], int) function is not implemented for this socket type.

        NOTE: 'GATHER' sockets are threadsafe. They do not accept ZMQ_RCVMORE on receives. This limits them to single part data.

        Summary of socket characteristics
        Compatible peer socketsSCATTER
        DirectionUnidirectional
        Send/receive patternReceive only
        Outgoing routing strategyN/A
        Incoming routing strategyFair-queued
        Action in mute stateBlock
        NOTE: SCATTER is still in draft phase.
    • Field Detail

      • type

        public final int type
    • Constructor Detail

      • SocketType

        private SocketType​(int socketType)
    • Method Detail

      • values

        public static SocketType[] values()
        Returns an array containing the constants of this enum type, in the order they are declared. This method may be used to iterate over the constants as follows:
        for (SocketType c : SocketType.values())
            System.out.println(c);
        
        Returns:
        an array containing the constants of this enum type, in the order they are declared
      • valueOf

        public static SocketType valueOf​(java.lang.String name)
        Returns the enum constant of this type with the specified name. The string must match exactly an identifier used to declare an enum constant in this type. (Extraneous whitespace characters are not permitted.)
        Parameters:
        name - the name of the enum constant to be returned.
        Returns:
        the enum constant with the specified name
        Throws:
        java.lang.IllegalArgumentException - if this enum type has no constant with the specified name
        java.lang.NullPointerException - if the argument is null
      • type

        public static SocketType type​(int baseType)
      • type

        public int type()