Portability | non-portable |
---|---|
Stability | experimental |
Maintainer | toralf.wittner@gmail.com |
0MQ haskell binding. The API closely follows the C-API of 0MQ with the main difference that sockets are typed. The documentation of the individual socket types and socket options is copied from 0MQ's man pages authored by Martin Sustrik.
- type Size = Word
- data Context
- data Socket a
- data Flag = NoBlock
- data SocketOption
- data Poll
- data PollEvent
- data P2P = P2P
- data Pub = Pub
- data Sub = Sub
- data Req = Req
- data Rep = Rep
- data XReq = Xreq
- data XRep = Xrep
- data Up = Up
- data Down = Down
- init :: Size -> Size -> Bool -> IO Context
- term :: Context -> IO ()
- socket :: SType a => Context -> a -> IO (Socket a)
- close :: Socket a -> IO ()
- setOption :: Socket a -> SocketOption -> IO ()
- subscribe :: SubsType a => Socket a -> String -> IO ()
- unsubscribe :: SubsType a => Socket a -> String -> IO ()
- bind :: Socket a -> String -> IO ()
- connect :: Socket a -> String -> IO ()
- send :: Socket a -> ByteString -> [Flag] -> IO ()
- send' :: Socket a -> ByteString -> [Flag] -> IO ()
- receive :: Socket a -> [Flag] -> IO ByteString
- poll :: [Poll] -> Timeout -> IO [Poll]
Documentation
Flags to apply on send operations (cf. man zmq_send)
NoBlock
- Send operation should be performed in non-blocking mode. If it cannot be performed immediatley an error will be thrown (errno is set to EAGAIN).
NoBlock | ZMQ_NOBLOCK |
data SocketOption Source
The option to set on 0MQ sockets (descriptions reproduced here from zmq_setsockopt(3) (cf. man zmq_setsockopt for further details)).
HighWM
- High watermark for the message pipes associated with the socket. The water mark cannot be exceeded. If the messages don't fit into the pipe emergency mechanisms of the particular socket type are used (block, drop etc.) If HWM is set to zero, there are no limits for the content of the pipe. Default: 0
LowWM
- Low watermark makes sense only if high watermark is defined (i.e. is non-zero). When the emergency state is reached when messages overflow the pipe, the emergency lasts at most till the size of the pipe decreases to low watermark. Normal state is resumed at that point. Default: 0
Swap
- Swap allows the pipe to exceed high watermark. However, the data are written to the disk rather than held in the memory. Until high watermark is exceeded there is no disk activity involved though. The value of the option defines maximal size of the swap file. Default: 0
Affinity
- Affinity defines which threads in the thread pool will be used to handle newly created sockets. This way you can dedicate some of the threads (CPUs) to a specific work. Value of 0 means no affinity. Work is distributed fairly among the threads in the thread pool. For non-zero values, the lowest bit corresponds to the thread 1, second lowest bit to the thread 2 etc. Thus, value of 3 means that from now on newly created sockets will handle I/O activity exclusively using threads no. 1 and 2. Default: 0
Identity
- Identity of the socket. Identity is important when restarting applications. If the socket has no identity, each run of the application is completely separated from other runs. However, with identity application reconnects to existing infrastructure left by the previous run. Thus it may receive messages that were sent in the meantime, it shares pipe limits with the previous run etc. Default: NULL
Rate
- This option applies only to sending side of multicast transports (pgm & udp). It specifies maximal outgoing data rate that an individual sender socket can send. Default: 100
RecoveryIVL
- This option applies only to multicast transports (pgm & udp). It specifies how long can the receiver socket survive when the sender is inaccessible. Keep in mind that large recovery intervals at high data rates result in very large recovery buffers, meaning that you can easily overload your box by setting say 1 minute recovery interval at 1Gb/s rate (requires 7GB in-memory buffer). Default: 10
McastLoop
- This option applies only to multicast transports (pgm & udp). Value of 1 means that the mutlicast packets can be received on the box they were sent from. Setting the value to 0 disables the loopback functionality which can have negative impact on the performance. If possible, disable the loopback in production environments. Default: 1
SendBuf
- Sets the underlying kernel transmit buffer size to the specified size. See SO_SNDBUF POSIX socket option. Value of zero means leaving the OS default unchanged. Default: 0
ReceiveBuf
- Sets the underlying kernel receive buffer size to the specified size. See SO_RCVBUF POSIX socket option. Value of zero means leaving the OS default unchanged. Default: 0
Type representing a descriptor, poll is waiting for (either a 0MQ socket or a file descriptor) plus the type of event of wait for.
The events to wait for in poll (cf. man zmq_poll)
Socket to communicate with a single peer. Allows for only a
single connect or a single bind. There's no message routing
or message filtering involved. Compatible peer sockets: P2P
.
SType P2P |
Socket to distribute data. receive
function is not
implemented for this socket type. Messages are distributed in
fanout fashion to all the peers. Compatible peer sockets: Sub
.
SType Pub |
Socket to send requests and receive replies. Requests are
load-balanced among all the peers. This socket type allows only an
alternated sequence of send's and recv's.
Compatible peer sockets: Rep
, Xrep
.
SType Req |
Socket to receive requests and send replies. This socket type
allows only an alternated sequence of receive's and send's. Each
send is routed to the peer that issued the last received request.
Compatible peer sockets: Req
, XReq
.
SType Rep |
Special socket type to be used in request/reply middleboxes
such as zmq_queue(7). Requests forwarded using this socket type
should be tagged by a proper prefix identifying the original requester.
Replies received by this socket are tagged with a proper postfix
that can be use to route the reply back to the original requester.
Compatible peer sockets: Rep
, Xrep
.
SType XReq |
Special socket type to be used in request/reply middleboxes
such as zmq_queue(7). Requests received using this socket are already
properly tagged with prefix identifying the original requester. When
sending a reply via XREP socket the message should be tagged with a
prefix from a corresponding request.
Compatible peer sockets: Req
, Xreq
.
SType XRep |
Socket to receive messages from up the stream. Messages are
fair-queued from among all the connected peers. Send function is not
implemented for this socket type. Compatible peer sockets: Down
.
SType Up |
Socket to send messages down stream. Messages are load-balanced
among all the connected peers. Send function is not implemented for
this socket type. Compatible peer sockets: Up
.
SType Down |
init :: Size -> Size -> Bool -> IO ContextSource
Initialize a 0MQ context (cf. zmq_init for details).
socket :: SType a => Context -> a -> IO (Socket a)Source
Create a new 0MQ socket within the given context.
setOption :: Socket a -> SocketOption -> IO ()Source
Set the given option on the socket. Please note that there are certain combatibility constraints w.r.t the socket type (cf. man zmq_setsockopt).
Please note that subscribe/unsubscribe is handled with separate functions.
unsubscribe :: SubsType a => Socket a -> String -> IO ()Source
Unsubscribe Socket from given subscription.
send :: Socket a -> ByteString -> [Flag] -> IO ()Source
Send the given ByteString
over the socket (zmq_send).
send' :: Socket a -> ByteString -> [Flag] -> IO ()Source
Send the given ByteString
over the socket (zmq_send).
This is operationally identical to send socket (Strict.concat
(Lazy.toChunks lbs)) flags
but may be more efficient.