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

[Martin Hargreaves <[e-mail]>]

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 <[e-mail]> On Behalf
> Of Rafael Belchior
> Sent: Wednesday, December 2, 2020 1:07 PM
> To: Thomas Hardjono <[e-mail]>
> Cc: [e-mail]
> 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 [[e-mail]] on
> >> behalf of Rafael Belchior
> >> [rafael.belchior=[e-mail]]
> >> Sent: Monday, November 30, 2020 11:49 AM
> >> To: [e-mail]
> >> 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
> [e-mail]
> 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.