/ 
IPC-MicroSocket-0.02
River stage zero No dependents
/ IPC::MicroSocket

NAME

IPC::MicroSocket - minimal request/response or pub/sub mechanism

DESCRIPTION

This distribution provides two main modules for implementing servers or clients that communicate over a local UNIX socket, to exchange messages. Each client connects to one server, and a server supports multiple connected clients.

MESSAGES

There are two supported kinds of message flows:

Request/Response

A client sends a request message to the server, which consists of a command name and a list of arguments. The server eventually sends a response to it, which contains a list of values. Responses are not necessarily delivered in the requested order; servers are permitted to respond asynchronously. Requests may also fail, sending a different kind of failure response to the client instead.

Publish/Subscribe

A client subscribes to a given topic string on the server. The server can emit messages to all the clients that subscribe to a particular topic.

DATA ENCODING

All transmitted strings are purely bytes. If you need to transmit Unicode text, you must encode/decode it. If you need to send data structures that are not plain byte strings, you must serialise/deserialise them.

FAQs

Why not ZeroMQ?

I found ZeroMQ to be a lot of effort to use from Perl, and most critically it does not appear to support both request/response and publish/subscribe message flows to share the same UNIX socket. To support that in ZeroMQ it would appear to be necessary to create two separate endpoints, one for each kind of message flow.

Why not JSON/YAML/your-favourite-serialisation?

I mostly built this for a few very-small use-cases involving simple byte strings or plain ASCII text, for which the overhead of JSON, YAML, or other kinds of serialisation would be unnecessary. As the presented message semantics are just opaque byte buffers, you are free to layer on top whatever kind of message serialisation you wish.

Why not IO::Async/Mojo/your-favourite-event-system?

I wanted to use this distribution as an exercise in writing "pure" Future-driven event logic, as an experiment to test out Future::Selector and other related design shapes.

TODO

There are a number of additional features that this module could support. Each will be considered if a use-case arises. Each would add extra code and possible dependencies, and take away from the "micro" nature of the module, so each would have to be considered on individual merit.

  • Configurations for encoding and serialisation of arguments.

  • Unsubscribe from individual topics by request.

  • Helper methods for other socket types, such as TCP sockets.

  • Flexible matching of subscription topics; such as string prefixes or delimited component paths.

  • Other kinds of message flows, such as server-buffered streams with atomic catchup-and-subscribe semantics ensuring clients receive all the buffer.

AUTHOR

Paul Evans <leonerd@leonerd.org.uk>