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

ping: return a stream of results #626

Merged
merged 2 commits into from
May 8, 2019
Merged

ping: return a stream of results #626

merged 2 commits into from
May 8, 2019

Conversation

Stebalien
Copy link
Member

@Stebalien Stebalien commented May 7, 2019

Otherwise, we can't return errors. This is a breaking change but unlikely to have a large impact on anyone but go-ipfs.

This also ensures canceling ping actually aborts the ping without waiting.

Part of ipfs/kubo#6298.

Otherwise, we can't return errors. This is a breaking change but unlikely to
have a large impact on anyone but go-ipfs.

Part of ipfs/kubo#6298
@ghost ghost assigned Stebalien May 7, 2019
@ghost ghost added the status/in-progress In progress label May 7, 2019
@Stebalien Stebalien requested review from vyzo and raulk May 7, 2019 22:49
@Stebalien
Copy link
Member Author

Going to leave this open for a day to collect feedback.

Copy link
Member

@raulk raulk left a comment

Choose a reason for hiding this comment

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

LGTM; just some non-blocking thoughts.

func (ps *PingService) Ping(ctx context.Context, p peer.ID) (<-chan time.Duration, error) {
// Result is a result of a ping attempt, either an RTT or an error.
type Result struct {
RTT time.Duration
Copy link
Member

Choose a reason for hiding this comment

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

We might want to return a time.Time representing the time the reading took place. The problem as I see it is that we perform pings eagerly, then wait reader to consume it off the channel. Time could've passed in between, and there's no deterministic way of telling the delta.

Alternatively we could wait for a reader to appear and send a thunk over the channel that will compute the ping, but that may be more complicated.

Copy link
Member Author

Choose a reason for hiding this comment

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

Does the time matter?


for ctx.Err() == nil {
var res Result
res.RTT, res.Error = ping(s)
Copy link
Member

@raulk raulk May 8, 2019

Choose a reason for hiding this comment

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

ping is untouched, but we should really set a read and write deadlines there. We could configure the ping service with a grace period, e.g. default 5 seconds, after which the ping will fail.

For inspiration, BSD ping uses 10 seconds:

https://github.com/freebsd/freebsd/blob/8e3d519198175982d2dce37113e9143885b2784b/sbin/ping/ping.c#L110

Copy link
Member Author

Choose a reason for hiding this comment

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

I agree. I'll handle that in a followup patch.

Copy link
Member Author

Choose a reason for hiding this comment

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

Actually, I'm not sure how we should handle that. I'm starting to think we should call NewStream as needed, every time ping fails.

Copy link
Member

Choose a reason for hiding this comment

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

Yeah, I would reuse the stream unless an error occurs, in which case I’d try to regenerate it, resetting the old one in a goroutine, while we call NewStream synchronously.

@Stebalien Stebalien merged commit 95cc0be into master May 8, 2019
@Stebalien Stebalien deleted the fix/ping branch May 8, 2019 21:01
@ghost ghost removed the status/in-progress In progress label May 8, 2019
@marten-seemann
Copy link
Contributor

If writing to a stream fails, there’s something wrong with the underlying connection. In that case, I don’t think we want to open more streams. Returning the error seems to be the better solution.

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.

4 participants