[zeromq-dev] 0MQ experimental OpenPGM support

[Steven McCoy]

2009/1/20 Pieter Hintjens <ph at imatix.com>:
> You're saying that on saturated networks, PGM will drop packets but
> continue working while TCP/IP will block.  And on unsaturated
> networks, PGM will be as good but obviously with the multicast
> advantages?

There are two different interpretations here, at the API level PGM
will not block when packets are being dropped, however at the protocol
layer the delivery of successful packets is blocked until the data is
re-sent similar to TCP.  The design of the PGM protocol is in reducing
the number of re-transmissions on the network, a PGM enabled router
will reduce all re-requests to only one upsteam.

If Forward Error Correction (FEC) is enabled it is possible for
non-blocking to occur at the protocol layer - dropped packets can be
recovered by receiving applications without any communication on the
back channel to the sending application.  The caveat is that the
application developer has to decide on a block size that recovery
operates on, e.g. 10 packets, this number means that 10 packets have
to be witnessed - received or noticed missing before error recovery
can occur.  This can affect recovery latency if blocks are not sent in
one shot, e.g. if an application sends 5 packets and waits, receiving
applications cannot recover if any of those packets are lost until 5
more are sent.

The PGM protocol defines an extension to support flushing of such a
partial block of packets, this has not yet been implemented in
OpenPGM.  The idea would be that zero MQ could send packets into
OpenPGM as data is waiting, when the data source indicates that it
would block the FEC block can be flushed allowing receivers to
initiate recovery on a partial block of packets.

As a workaround zero MQ could simply flush out the block by sending
NULL PGM data packets.

-- 
Steve-o