Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use Query Protocol in storage deal negotiation #297

Merged
merged 20 commits into from Jun 30, 2020

Conversation

ingar
Copy link
Contributor

@ingar ingar commented Jun 25, 2020

Problem

Holding stream connections open is not sustainable, and doesn't help with resuming interrupted deals.

Solution

Use the query protocol in the Client/Provider FSMs, close the deal stream once we get a response.

Resolves #82

@ingar ingar force-pushed the feat/use-query-protocol-in-client-fsm branch from 0d61358 to 6d30007 Compare June 25, 2020 02:33
@codecov-commenter
Copy link

codecov-commenter commented Jun 25, 2020

Codecov Report

Merging #297 into master will increase coverage by 2.01%.
The diff coverage is 67.00%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master     #297      +/-   ##
==========================================
+ Coverage   61.22%   63.23%   +2.01%     
==========================================
  Files          41       41              
  Lines        2519     2537      +18     
==========================================
+ Hits         1542     1604      +62     
+ Misses        854      811      -43     
+ Partials      123      122       -1     
Impacted Files Coverage Δ
storagemarket/impl/provider.go 4.46% <ø> (+0.22%) ⬆️
storagemarket/types.go 0.00% <ø> (ø)
storagemarket/impl/client.go 3.28% <24.25%> (+3.28%) ⬆️
...oragemarket/impl/providerstates/provider_states.go 86.04% <80.96%> (+1.30%) ⬆️
storagemarket/impl/clientstates/client_states.go 89.66% <90.00%> (+3.52%) ⬆️
storagemarket/impl/clientstates/client_fsm.go 100.00% <100.00%> (ø)
storagemarket/impl/providerstates/provider_fsm.go 93.85% <100.00%> (-0.09%) ⬇️
retrievalmarket/impl/blockio/traverser.go 68.89% <0.00%> (-3.33%) ⬇️
piecestore/piecestore.go 82.76% <0.00%> (+2.76%) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 4921f8b...ff37da8. Read the comment docs.

@ingar ingar requested a review from hannahhoward June 25, 2020 04:00
@ingar ingar changed the title Feat/use query protocol in client fsm Use Query Protocol in storage deal negotiation Jun 25, 2020
Copy link
Collaborator

@hannahhoward hannahhoward left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, I wrote a bunch of comments, but there are two blocking issues:

  • API signature for GetProviderDealState
  • We need to make sure connections are being closed properly and ConnectionClosed state is set properly. One alternative is to refactor more aggressively to get rid of holding connections open entirely:
    Refactor: Don't keep any protocol connections open #296

storagemarket/client.go Outdated Show resolved Hide resolved
storagemarket/README.md Show resolved Hide resolved
if err != nil {
return ctx.Trigger(storagemarket.ClientEventReadResponseFailed, err)
log.Warnf("error when querying provider deal state: %w", err) // TODO: at what point do we fail the deal?
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm thinking the proper thing here would be to have a maximum fail count.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

here's a suggestion:
make waitAgain take an error value -> pass on to ClientEventWaitForDealState
in the FSM code, for if ClientEventWaitForDealState, if err != nil, also increment another value -- say "PollErrorCount".

in this code, add a check for deal.PollErrorCount > some constant (maybe 10? -- miner offline for 5 minutes seems bad) and if so, instead of waiting again, trigger ClientEventReadResponseFailed like before and add back in CheckForAcceptance as an acceptable transition state.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder about this; the Miner can be totally unresponsive to queries, but can still fulfill their side of the storage deal. In that case, if we fail the deal on the Client but the Miner finishes sealing and publishing...

storagemarket/integration_test.go Show resolved Hide resolved
@ingar ingar requested a review from hannahhoward June 26, 2020 21:37
Copy link
Collaborator

@hannahhoward hannahhoward left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mostly LGTM -- but we have to figure out how rejections get sent -- that's not functionality we can break.

storagemarket/impl/client.go Outdated Show resolved Hide resolved
storagemarket/impl/clientstates/client_fsm.go Show resolved Hide resolved
storagemarket/impl/client.go Outdated Show resolved Hide resolved
storagemarket/testnodes/testnodes.go Outdated Show resolved Hide resolved
@ingar ingar force-pushed the feat/use-query-protocol-in-client-fsm branch from eded9c7 to ca3da7e Compare June 30, 2020 21:44
@ingar ingar requested a review from hannahhoward June 30, 2020 21:53
@ingar ingar force-pushed the feat/use-query-protocol-in-client-fsm branch from f1fe4f6 to ff37da8 Compare June 30, 2020 22:13
@ingar ingar merged commit ec028f3 into master Jun 30, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Storage Market should not block reading protocol responses
3 participants