search

golemfactory / concent

Repository for Concent Service sources
8 stars 7 forks source link

[Blueprint] Concent timing #165

Open cameel opened 6 years ago

cameel commented 6 years ago

Time limits in communication with requestor and provider

Settings/constants

These values are meant to be adjustable in Concent settings.

Relations between time window lengths

Relations between message timestamps

Any message that does not satisfy any of these conditions must be rejected as invalid:

Communication windows

concent-timing

Note: the diagram above shows the biggest possible set of use cases one subtask could go through. It's not the only possible one though since all use cases are optional. Also keep in mind that the diagram only shows one subtask but the PAYMENT use case can receive more than one in a single message. In that case the time window starts when acceptances of all those subtasks are older than PDT.

  1. REPORT

    • Submission of ForceReportComputedTask by the provider:
      • start: ReportComputedTask.timestamp
      • end: TaskToCompute.deadline
    • Submission of AckReportComputedTask or RejectReportComputedTask by the requestor:
      • start: ForceReportComputedTask.timestamp
      • end: TaskToCompute.deadline + CMT

  2. RESULT TRANSFER

    • Submission of ForceGetTaskResult by the requestor:
      • start: ReportComputedTask.timestamp
      • end: TaskToCompute.deadline + 2 CMT + MDT
    • Upload of task results to the storage cluster by the provider:
      • start: ForceGetTaskResult.timestamp
      • end: TaskToCompute.deadline + 3 CMT + 2 MDT
        • (this should be the value used in FileTransferToken.deadline returned in ForceGetTaskResultUpload)
    • Download of task results from the storage cluster by the requestor:
      • start: FileTransferToken.timestamp
      • end: TaskToCompute.deadline + SVT
        • (this should be the value used in FileTransferToken.deadline returned in ForceGetTaskResultDownload)

  3. ACCEPTANCE

    • Submission of ForceSubtaskResults by the provider:
      • start: TaskToCompute.deadline + SVT
      • end: TaskToCompute.deadline + SVT + FAT
    • Submission of ForceSubtaskResultsResponse the requestor:
      • start: ForceSubtaskResults.timestamp
      • end: TaskToCompute.deadline + SVT + FAT + CMT

  4. ADDITIONAL VERIFICATION

    • Submission of SubtaskResultsVerify by the provider:
      • start: SubtaskResultsRejected.timestamp
      • end: SubtaskResultsRejected.timestamp + AVCT
    • Upload of task source files and results to the storage cluster by the provider:
      • start: SubtaskResultsVerify.timestamp
      • end: SubtaskResultsRejected.timestamp + AVCT

  5. PAYMENT

    • Submission of ForcePayment by the provider:
      • start: SubtaskResultsAccepted.timestamp + PDT (maximum of all values included inside ForcePayment)
      • end: no limit
Jakub89 commented 6 years ago

@cameel in 2. RESULT TRANSFER it is written that submission of ForceReportComputedTask by the provider ends on TaskToCompute.deadline. But on the picture it looks more like it should be TaskToCompute.deadline + 2CMT + MDT. Right now in our code it's TaskToCompute.deadline + FAT. Which one is correct?

cameel commented 6 years ago

You're mixing 1 and 2 here.

in 2. RESULT TRANSFER it is written that submission of ForceReportComputedTask by the provider ends on TaskToCompute.deadline.

Yes, ForceReportComputedTask must be submitted no later than at TaskToCompute.deadline. But it's not in 2. RESULT TRANSFER. It's in 1. REPORT.

But on the picture it looks more like it should be TaskToCompute.deadline + 2CMT + MDT.

This is the time for ForceGetTaskResult in 2. RESULT TRANSFER. Not for ReportComputedTask in 1. REPORT.

Right now in our code it's TaskToCompute.deadline + FAT. Which one is correct?

The code is wrong. The current code is a mix of my old blueprint for "force get task result" use case (@12) and information gleaned from Łukasz's docs. Refer to the current blueprint only - it's now consistent with Łukasz's docs as far as I can tell.

Jakub89 commented 6 years ago

Ups, I copied it wrong. I meant ForceGetTaskResult instead ForceReportComputedTask

cameel commented 6 years ago

Oh, I see it now. You're right. There was an error.

I have changed the end time in 2. RESULT TRANSFER from TaskToCompute.deadline to TaskToCompute.deadline + 2 CMT + MDT

cameel commented 6 years ago

Another error fixed:

Changed the start time in 5. PAYMENT from SubtaskResultsAccepted.timestamp to SubtaskResultsAccepted.timestamp + PDT

Jakub89 commented 6 years ago

@rwrzesien Could You look at last part of this task 5.PAYMENT, and check if it really should change form SubtaskResultsAccepted.payment_ts to SubtaskResultsAccepted.timestamp? I'm referring to Your blueprint #116

rwrzesien commented 6 years ago

@Jakub89 It looks for me like this is the missing part of the use case, not a bug. As far as I remember we didn't wanted to implement time window check when we were implementing the use case. However, I don't remember what was the reason for it.

You can see that in @cameel comment here https://github.com/golemfactory/concent/issues/116#issuecomment-365939321 he mentions 2C, but quoting a part from 2B, which at the quote time was 2C. I think that this check was in 2B, and got removed, that is why 2C became 2B.

I suggest asking @lukasz-glen if maybe he remembers why this check was dropped at that point.

cameel commented 6 years ago

Description and diagram updated according to discussion with @lukasz-glen on Rocket. Use SubtaskResultsAccepted.payment_ts and ignore the timestamp.

cameel commented 6 years ago

Update: I have clarified that the diagram shows only a single subtask in the PAYMENT use case.

cameel commented 6 years ago

Update: diagram updated with changes from #431:

dybi commented 5 years ago

@cameel, please update FORCE PAYMENT:

start: SubtaskResultsAccepted.timestamp + PDT (maximum of all values included inside ForcePayment)

to indicate that payment_ts is now used instead of timestamp