This page holds ideas for ØMQ projects that you might like to try working on.
IPv6 transport
Important for using ØMQ in WAN environment. The pool of IPv4 addresses have almost dried up so we are to expect increasingly more IPv6 addresses in the network.
IOCP
Using IOCP (completion ports) polling mechanism on Windows platforms would allow for using OS communication mechanisms with no POSIX APIs. For example, IPC on Windows is done via NamedPipes which are not POSIX compliant. Additionally, using IOCP would also speed up ØMQ on Windows platform. Alternatively, implementing IPC transport using anonymous shared memory is quite possible and would be a nice contained project.
TCP "subports"
ØMQ uses different TCP ports to distinguish different message feeds. This may become a problem where there is a limited number of ports available. Specifically, you may want to use a single open port to pass all the traffic through corporate firewall. "subports" would be a mechanism to partition a single TCP port into lot of independent
channels that could be used by 0MQ to pass different message feeds.
SCTP
SCTP is widely implemented L4 protocol which has some considerable advantages over TCP (native heartbeat support, for example). It would be good to have SCTP as one of the transports supported by ØMQ.
UDP
Pure UDP with optional congestion control via DCCP as a new ØMQ transport mechanism. Possible configurable semantics such as weak ordering by only accepting new packets.
UDT
A transport mechanism implementing congestion control suitable for intercontinental sockets.
Point to point opportunistic encryption
By following the protocol as set out in the documentation and maybe source of TCP crypt (see http://tcpcrypt.org) implement opportunistic encryption support in an ØMQ transport to allow for basic point to point encryption at the transport level (for that transport only). This wouldn't affect other points using other transports or messaging patterns and create a building block for a secure WAN network implementation over time (akin to the IPv6 support).
Scheduling with priorities
Currently the ØMQ load-balancer uses simple scheduling where all the connections are considered being equal. Specific use cases require the echeduler to be able to cope with hard priorities (strict precedence) and/or weighted priorities (partitioning the traffic based on weights assigned to individual connections). The scheduler should have O(1) complexity. In addition to load-balancing, the scheduler can be used to customise fair-queueing algorithm for inbound messages.
HTTP tunneling
ØMQ is great for the intranet but through firewalls or over the Internet it might be preferable to tunnel inside a HTTP transport. Different architectures and optimisations exist such as POST for transmit and GET for receive for uni-directional connections, HTTP transactions per ØMQ message, streaming HTTP or multi-part HTTP, fast open sockets, etc.
Advanced ØMQ devices
Providing devices (brokers) with interesting functionality: SNMP or JMX for management, fine-grained config files, merging many devices into a single executable etc.
Uni-directional multicast transport
Update the PGM transport to support a no-back-channel scheme utilizing forward error correction (FEC) to prevent data loss.
Improving language bindings
Many language bindings are feature-complete and actively maintained. However, some are still lacking in terms of functionality. Provided a full-blown language binding would be a nice self-contained project. The bindings projects can be found here.
