[zeromq-dev] First draft for PPPP rfc (paranoid pirate publish protocol)
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?
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>
> > 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
> > 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the zeromq-dev