[zeromq-dev] Ideas for GSoC

Steven McCoy steven.mccoy at miru.hk
Thu Feb 3 18:43:47 CET 2011

On 3 February 2011 08:38, Martin Sustrik <sustrik at 250bpm.com> wrote:

> TCP "subports"
> --------------

Or just call it ØMQ ports?

HTTP transport

Ø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.

SPDY transport

Extend the HTTP transport to support the more efficient SPDY protocol.

WebSockets transport

Extend the HTTP transport to negotiate over to WebSockets for more efficient


Add location transparency and hence remove single points of failure with
multicast based REQ/REP sockets.

Certified sockets

Implement a delivery mechanism that can withstand restarts of both the
sender and receiver.

Transactional sockets

Implement a delivery mechanism that can guarantees once-only delivery and
can withstand complete hardware failure of sender and receiver.  Suggested
to implement XA semantics to hook into Oracle, Sybase, and IBM WebSphere

Atomic multicast

Implement a scheme so that delivery to a group of receivers only completes
once every receiver has confirmed receipt.

High latency sockets

A socket implementing congestion control suitable for intercontinental
sockets.  Primary example being UDT.

Unreliable unordered sockets

Pure UDP with optional congestion control via DCCP.  Possible configurable
semantics such as weak ordering by only accepting new packets.  Unreliable
ordered sockets are available in PGM.

Synchronous low-overhead sockets

Implement a UDPCP transport, per Linux 2.6.35.  More interesting would be to
also add a compatible solution for non-Linux platforms.

ØMQ management extensions

Bring the semantics of SNMP and JMX to ØMQ transports.

Multicast subject subscriptions

Using multicast eventual consistency semantics can be more scalable than
unicast, consider failure scenario when hundreds of clients crash each with
thousands of open subscriptions.

ØMQ memcached

Implement a last value cache using the ØMQ transport.

Uni-directional multicast transport

Update the PGM transport to support a no-back-channel scheme utilizing FEC
to prevent data loss.

ØMQ bus transport

Add semantics to ØMQ in order to support a bus based topology which a socket
can send and receive to multiple peers.

Improved ØMQ logging

Update and extend the ØMQ based logging system to all transport errors and

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20110203/71039875/attachment.htm>

More information about the zeromq-dev mailing list