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

Update index.md | Fixing typo that reverses the meaning. #33625

Merged
merged 1 commit into from
May 20, 2024

Conversation

rajatsharma16
Copy link
Contributor

@rajatsharma16 rajatsharma16 commented May 15, 2024

Description

I think there is a typo here. It is the polite peer who will let go if its offer and become the callee instead of the caller.

Motivation

To either help content become accurate or learn what I might be missing.

Additional details

Related issues and pull requests

I think there is a typo here. It is the polite peer who will let go if its offer and become the callee instead of the caller.
@rajatsharma16 rajatsharma16 requested a review from a team as a code owner May 15, 2024 10:23
@rajatsharma16 rajatsharma16 requested review from wbamberg and removed request for a team May 15, 2024 10:23
@github-actions github-actions bot added Content:WebAPI Web API docs size/xs 0-5 LoC changed labels May 15, 2024
Copy link
Contributor

@@ -296,7 +296,7 @@ Since rollback works by postponing changes until the next negotiation (which wil

The code checks to see if the message is an offer, and if so, if the local signaling state isn't `stable`. If it's not stable, _and_ the local peer is the polite one, we need to trigger rollback so we can replace the outgoing offer with the new incoming one. And these must both be completed before we can proceed with handling the received offer.

Since there isn't a single "roll back and use this offer instead", performing this change on the polite peer requires two steps, executed in the context of [`Promise.all()`](/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise/all), which is used to ensure that both statements execute completely before continuing to handle the received offer. The first statement triggers rollback and the second sets the remote description to the received one, thus completing the process of replacing the previously _sent_ offer with the newly _received_ offer. The impolite peer has now become the callee instead of the caller.
Since there isn't a single "roll back and use this offer instead", performing this change on the polite peer requires two steps, executed in the context of [`Promise.all()`](/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise/all), which is used to ensure that both statements execute completely before continuing to handle the received offer. The first statement triggers rollback and the second sets the remote description to the received one, thus completing the process of replacing the previously _sent_ offer with the newly _received_ offer. The polite peer has now become the callee instead of the caller.
Copy link
Collaborator

Choose a reason for hiding this comment

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

Thanks @rajatsharma16 . I think you are right, but this is so confusing I am not certain.

Above it says:

An important thing to keep in mind is this: the roles of caller and callee can switch during perfect negotiation. If the polite peer is the caller and it sends an offer but there's a collision with the impolite peer, the polite peer drops its offer and instead replies to the offer it has received from the impolite peer. By doing so, the polite peer has switched from being the caller to the callee!

So

  1. if the caller was initially the polite peer, then yes, this is consistent. It isn't "stated" what happens if the impolite peer was the caller, or whether it was the caller in this case.
  2. This definition of caller/callee is confusing to me. In English I would assume the caller is the peer that initiated a call. The way this reads it is the peer that sends the offer that is accepted "becomes" the caller. If that is the definition the docs should say so much earlier.
  3. If that definition is correct then doesn't that mean the impolite server will always be the caller if there is a collision.

@wbamberg I'm not taking this over - really just wanted @rajatsharma16 to know we're not ignoring this. Do you have enough knowledge to answer this?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes I think this is explained from the polite peer's perspective. If we look at the preceding line:

The first statement triggers rollback and the second sets the remote description to the received one, thus completing the process of replacing the previously sent offer with the newly received offer.

It is the polite peer that is having to do all this. The impolite one simply returns upon detecting a collision (It knows it will "win").

if (!polite) {
          return;
        }

Then the next line continues to talk about the polite peer:

The impolite peer has now become the callee instead of the caller.

This is where I feel the word impolite should be replaced by the word polite. Because the polite peer- which was the original caller [initiator] of the negotiation- has now become the callee, by discarding its offer and accepting the impolite peer's one.

Another way to say the same thing can be:
The impolite peer has now become the caller instead of the callee.

It just depends on whose perspective do we want to keep at the center while describing this.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Coming to your points:

if the caller was initially the polite peer, then yes, this is consistent. It isn't "stated" what happens if the impolite peer was the caller, or whether it was the caller in this case.

The impolite peer returns upon detecting a collision. The code is common for both peers [this abstraction is the very essence of implementing the perfect negotiation pattern] .

This definition of caller/callee is confusing to me. In English I would assume the caller is the peer that initiated a call. The way this reads it is the peer that sends the offer that is accepted "becomes" the caller. If that is the definition the docs should say so much earlier.

For this discussion, we can assume that "caller" is the peer who sent out the offer first. Technically, at one point both peers have become "temporary callers" by sending out offers to each other (hence the collision). Once the deadlock resolves, one of them [in our case the polite one] will have thrown/ rollbacked its offer and instead prepared [and sent] answer for the incoming offer. We can say that if you answer you become the callee, which the polite peer has done in this case.

If that definition is correct then doesn't that mean the impolite server will always be the caller if there is a collision.

Yes it seems so. The impolite peer will "eventually" always become the caller.

Copy link
Collaborator

@wbamberg wbamberg left a comment

Choose a reason for hiding this comment

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

@wbamberg I'm not taking this over - really just wanted @rajatsharma16 to know we're not ignoring this. Do you have enough knowledge to answer this?

I'm not at all an expert on this but my reading is the same as both of yours. Thanks for the fix, @rajatsharma16 !

@wbamberg wbamberg merged commit 0b2db5a into mdn:main May 20, 2024
7 checks passed
@rajatsharma16 rajatsharma16 deleted the patch-2 branch May 21, 2024 08:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Content:WebAPI Web API docs size/xs 0-5 LoC changed
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants