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 <[email protected]> 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 <[email protected]> > 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 > > [email protected] > > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev >
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
