In order to bring ParrotTalk-3.6 support, alongside historical 3.5 support, the frame header stays the same and the processing of the ProtocolOffered would select "ParrotTalk-3.6" to use the compact protocol of
- ProtocolOffered { offered, preferred }
- ProtocolAccepted { accepted }
- IWant|GiveInfo|ReplyInfo { vatId, domain, publicKey, cryptoProtocols, dataEncoders }
- IAm|ReplyInfo { vatId, domain, publicKey, cryptoProtocol, dataEncoder, dhParam }
- Go { cryptoProtocol, dataEncoder, dhParam, signature }
- GoToo { signature }
Using eLinda :
Above the FrameBuffer, below the SessionOperations for each version of the protocol, an ELindaSession could be inserted. This session think would have the stacks for each protocol version SessionOperation registered by protocol in a Tuple,
for eventual callback. When the ProtocolOffered comes in we publish the tuple frame, with set selected version, to route to the correct SessionOperation to support each version of the protocol.
With a non-specific vatId required, anonymous connections would be supported.
- HH
Hi henry thanks for this announce. Can you tell where such protocols are used? Stef On Tue, Oct 24, 2017 at 6:33 PM, henry
wrote: > Hi all, > > I am happy to announce the release of version 3.5 of ParrotTalk, for Squeak > and Pharo, found here: > > http://www.squeaksource.com/Cryptography/ParrotTalk-zzz.2.mcz > > It follows this
specification: > https://github.com/ZiroZimbarra/callistohouse/blob/master/docs/ParrotTalkFrameDesign-3.5.pdf > > One item of note, in version 3.5, the system connecting to a server, sending > the IWant msg, must know
the vatId of the system being connected to. I am > considering changing this to version 3.6 by removing one round-trip in > messaging. Therefore, these messages would be combined: IWant/GiveInfo, > IAm/ReplyInfo. I will
keep ProtocolOffered and ProtocolAccepted to allow > eLindaSession to support both versions: 3.5 and 3.6. > > Thoughts please? > > - HH