Re: [Blockchain-interop] Gatweay Crash Recovery Discussion #1

Hello Martin,
Yes - on the crash recovery protocol we ought to support recovery 
messages that allow establishing to all parties what is the current 
state of an asset transfer.

We can specify this in the "3.3 Recovery procedure" section.

Cheers,
Rafael

A 2020-12-02 14:00, Martin Hargreaves escreveu:
> Hi both,
> 
> In terms of protocol messaging, how should we support this?
> 
> It sounds like, on recovery, the recovered gateway scans its logs and
> finds a set of uncompleted transactions, then need to send some kind
> of "recovery message" to its counterparties - offers to continue
> processing, with a list of transactions and phases in each transaction
> to pick up from.
> 
> The gateways that previously saw it time out as it crashed can then
> evaluate these and respond as to whether they wish to proceed or back
> out (or indeed don't recognise) the transactions.
> 
> What do you think?
> 
> Thanks
> 
> Martin
> 
>> -----Original Message-----
>> From: Blockchain-interop <blockchain-interop-bounces@ietf.org> On 
>> Behalf
>> Of Rafael Belchior
>> Sent: Wednesday, December 2, 2020 1:07 PM
>> To: Thomas Hardjono <hardjono@mit.edu>
>> Cc: blockchain-interop@ietf.org
>> Subject: Re: [Blockchain-interop] Gatweay Crash Recovery Discussion #1
>> 
>> CAUTION: This email originated from outside of the organisation. Do 
>> not click
>> links or open attachments unless you recognise the sender and know the
>> content is safe.
>> 
>> 
>> Thomas,
>> Yes, those assumptions are reasonable; i) we can also consider the 
>> case
>> where a public-private key pair is lost, and thus a new pair needs to 
>> be
>> generated. ii) I think we can assume a new SSL connection is created. 
>> Do you
>> envision problems with this?
>> 
>> I think it makes sense for the gateway to resume operations from the 
>> last
>> message before the crash because this mode is blocking, in principle - 
>> we can
>> resume from the last event.
>> 
>> If anyone thinks this could be improved, please do not hesitate in 
>> providing
>> feedback :)
>> 
>> Cheers,
>> Rafael
>> 
>> 
>> A 2020-12-02 00:17, Thomas Hardjono escreveu:
>> > Thanks Rafael.
>> >
>> > Inline:
>> >
>> >>>> > -- Which mode (self-healing mode, or primary-backup mode) do you
>> >>>> >>> > recommend?  (Which one would be the simplest approach for
>> >>>> >>> > now, and
>> >>>> > what assumptions would we need to make).
>> >>>>
>> >>>> The self-healing mode is simpler, as the same machine eventually
>> >>>> recovers, continuing its operations since the latest log entry. It
>> >>>> does not require, in principle, to read from the log storage API.
>> >>>> However, we
>> >>>> are assuming it eventually recovers, and while this happens the
>> >>>> system is down, prejudicing availability.
>> >
>> > For this scenario, there may need to be some assumptions about the
>> > gateway node.
>> >
>> > For example, (i) the gateway recovers to 100% without any internal
>> > losses (e.g. loss of private-keys); (ii) that the SSL connection has a
>> > longer life-time than the duration of crash (unavailability); etc.
>> >
>> > For short-duration unavailabilities, would the gateway pick-up
>> > (restart) from the last message before crash, or does it start from
>> > the beginning of the Phase?
>> >
>> > Best
>> >
>> >
>> > -- thomas --
>> >
>> >
>> >
>> >
>> >> ________________________________________
>> >> From: Blockchain-interop [blockchain-interop-bounces@ietf.org] on
>> >> behalf of Rafael Belchior
>> >> [rafael.belchior=40tecnico.ulisboa.pt@dmarc.ietf.org]
>> >> Sent: Monday, November 30, 2020 11:49 AM
>> >> To: blockchain-interop@ietf.org
>> >> Subject: [Blockchain-interop] Gatweay Crash Recovery Discussion #1
>> >>
>> >> Dear All,
>> >> Attached, the slides of the first discussion on the crash recovery
>> >> mechanism for gateways, that took place during the last meeting.
>> >>
>> >>
>> >> Cheers,
>> >>
>> >> --
>> >> Rafael Belchior
>> >> Ph.D. student in Computer Science and Engineering, Blockchain -
>> >> Técnico Lisboa https://rafaelapb.github.io/
>> >> https://www.linkedin.com/in/rafaelpbelchior/
>> >
>> > --
>> > Rafael Belchior
>> > Ph.D. student in Computer Science and Engineering, Blockchain -
>> > Técnico Lisboa https://rafaelapb.github.io/
>> > https://www.linkedin.com/in/rafaelpbelchior/
>> 
>> --
>> Rafael Belchior
>> Ph.D. student in Computer Science and Engineering, Blockchain - 
>> Técnico
>> Lisboa https://rafaelapb.github.io/
>> https://www.linkedin.com/in/rafaelpbelchior/
>> 
>> --
>> Blockchain-interop mailing list
>> Blockchain-interop@ietf.org
>> https://www.ietf.org/mailman/listinfo/blockchain-interop
> This message is intended solely for the addressee and may contain
> privileged and confidential information. If you have received this
> message in error, please send it back to us, and immediately and
> permanently delete it. Do not use, copy or disclose the information
> contained in this message or in any attachment. Quant Network does not
> guarantee that this email has not been intercepted and amended or that
> it is virus free.

-- 
Rafael Belchior
Ph.D. student in Computer Science and Engineering, Blockchain - Técnico
Lisboa
https://rafaelapb.github.io/
https://www.linkedin.com/in/rafaelpbelchior/