[zeromq-dev] First draft for PPPP rfc (paranoid pirate publish protocol)

André Caron andre.l.caron at gmail.com
Thu Aug 28 12:40:10 CEST 2014


Interesting spec :-)

The one thing I might be concerned about is the high volume of bandwidth
required by ACK messages.  The're a section in the guide that does a quick
computation of the bandwith requirements for heartbeating and the
conclusion is to treat any message from a peer as a heartbeat because it's
as effective and isn't as prohibitive (indeed, that's what your spec
recommends for heartbeats).  It might be worth coming up with a quick
bandwith estimate using the same type of formula for ACK messages.

If I may, I'd recommend storing the last ACK-ed sequence number in all
messages sent to a peer.  This assumes your application cannot process
messages out of order, but it completely eliminates the need for ACK
messages: you will automatically encode the ACK into the next
message/reply/error reply you send or in the next hearbeat.

Any thoughts on this?

Cheers,

André


On Mon, Aug 25, 2014 at 2:46 PM, Pieter Hintjens <ph at imatix.com> wrote:

> Nice... would you like to add it to the RFC project (usual pull
> request model, with simultaneous update to the wiki, not automated).
>
> On Mon, Aug 25, 2014 at 5:13 PM, Goswin von Brederlow <goswin-v-b at web.de>
> wrote:
> > Hi,
> >
> > I've written up a first draft for my PPPP protocol:
> >
> > PPPP implements a reliable two-way dialog between peers. PPPP covers
> > presence, heartbeating, request-reply processing and ACKing of
> > messages. It was based loosly on the Paranoid Pirate Protocol.
> >
> > The goals of PPPP are to:
> >
> > * Allow peers to detect disconnection of the other peer, through the use
> of
> >   heartbeating.
> > * Allow peers to detect out-of-order messages by adding sequence numbers.
> > * Allow peers to detect message loss when peers reconnect and resend (or
> >   rerequest) messages.
> > * Allow peers to acknowledge receiving a message or not-acknowledge lost
> >   messages for fast resent.
> > * Allow peers to associate replies with requests.
> > * Allow peers to publish messages without disrupting the ability of
> peers to
> >   associate replies with requests.
> >
> > For the full specs see:
> >
> > https://github.com/Q-Leap-Networks/rfc/blob/pull-pppp/spec_40.txt
> >
> > The RFC defines the on-wire protocol and behaviour for 2 protocol
> > devices. One device for clients talking to a single server and one for
> > servers talking to many clients. The devices will handle all the
> > tidious protocol handling, acks, resends and timeouts and so on. The
> > applications can then simply send-and-forget messages. RFCs for the
> > devices to follow.
> >
> > Comments welcome.
> >
> > MfG
> >         Goswin
> > _______________________________________________
> > zeromq-dev mailing list
> > zeromq-dev at lists.zeromq.org
> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20140828/94b36d50/attachment.html>


More information about the zeromq-dev mailing list