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

Change retransmittable to Ack-eliciting #1942

Closed
wants to merge 1 commit into from

Conversation

ianswett
Copy link
Contributor

Ack-eliciting is slightly shorter than retransmittable and seems as accurate as anything we have.

Fixes #1595

@martinthomson martinthomson added editorial An issue that does not affect the design of the protocol; does not require consensus. -recovery labels Nov 1, 2018
Copy link
Contributor

@marten-seemann marten-seemann left a comment

Choose a reason for hiding this comment

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

We considered ack-eliciting before. I'm still not a big fan of it, but I can't say anything against it other than retransmittable reads a bit better.

@mikkelfj
Copy link
Contributor

mikkelfj commented Nov 1, 2018

Yeah - retransmittable doesn’t mean it has to, only that it can be.

@ianswett
Copy link
Contributor Author

ianswett commented Nov 1, 2018

I'm not set on this being what we go with, but I think it reads reasonably well and I'm really unhappy with retransmittable, since I think it's just confusing. If there's another alternative you'd like to see me create a PR for, feel free to suggest it.

@dtikhonov
Copy link
Member

Does the English language have a suffix that means that something must be done ("ack$foo") rather than that can be done ("ackable")? What's $foo? 😖

@dtikhonov
Copy link
Member

Based on this list of English suffixes, I propose that we use ackent instead of ack-eliciting. The suffix ENT means "one who performs/causes."

Thus, instead of

Packets that contain ack-eliciting frames elicit an ACK from the receiver within the maximum ack delay and are called ack-eliciting packets.

we will have

Packets that contain ackent frames elicit an ACK from the receiver within the maximum ack delay and are called ackent packets.

@mikkelfj
Copy link
Contributor

mikkelfj commented Nov 2, 2018

resilient

Packets that contain resilient frames elicit an ACK from the receiver within the maximum ack delay and are called resilient packets.

unforgettable
https://www.youtube.com/watch?v=2HSt7LWsm-A

Packets that contain unforgettable frames elicit an ACK from the receiver within the maximum ack delay and are called unforgettable packets.

unmissable

Packets that contain unmissable frames elicit an ACK from the receiver within the maximum ack delay and are called unmissable packets.

robust

Packets that contain robust frames elicit an ACK from the receiver within the maximum ack delay and are called robust packets.

stateful

Packets that contain stateful frames elicit an ACK from the receiver within the maximum ack delay and are called stateful packets.

@dtikhonov
Copy link
Member

@mikkelfj, my suggestion was in earnest.

@mikkelfj
Copy link
Contributor

mikkelfj commented Nov 2, 2018

Mine was only half in jest. I kind of like resilient.

@janaiyengar janaiyengar mentioned this pull request Dec 7, 2018
@janaiyengar janaiyengar closed this Dec 7, 2018
@MikeBishop MikeBishop deleted the ianswett-ack-eliciting branch February 6, 2019 00:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
-recovery editorial An issue that does not affect the design of the protocol; does not require consensus.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants