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

Protocol 2.0 #842

Closed
wants to merge 70 commits into from
Closed

Protocol 2.0 #842

wants to merge 70 commits into from

Conversation

qsdigor
Copy link
Contributor

@qsdigor qsdigor commented Sep 26, 2022

No description provided.

QSD_igor and others added 8 commits September 21, 2022 14:47
Update tests for version check
Make msgSerial public in ConnectionManager
Add ConnectionRecoveryKey class for generating key json
Add channelSerial in RealtimeChannelBase for generating recovery key
Fix tests implementation for new recovery key spec
Implement channelSerial to attach message by spec RTL4c1
@qsdigor qsdigor self-assigned this Sep 26, 2022
@qsdigor qsdigor changed the title Integration/protocol 2.0 Protocol 2.0 Sep 26, 2022
Copy link
Contributor

@KacperKluka KacperKluka left a comment

Choose a reason for hiding this comment

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

LGTM 👍 But I don't have enough knowledge about the protocol 2.0 implementation details so this is just a "Comment" instead of an "Approve" 😉

@KacperKluka KacperKluka self-requested a review November 8, 2022 08:29
Copy link
Contributor

@KacperKluka KacperKluka left a comment

Choose a reason for hiding this comment

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

LGTM 👍

Copy link
Contributor

@KacperKluka KacperKluka left a comment

Choose a reason for hiding this comment

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

Even though I said that I don't feel confident in leaving an approval I have to do it because Github ignores my "Comment" and shows my review as "Request changes" 😅 Therefore, in order to not block this PR I'm leaving an approval 👍

PresenceMessage member = entry.getValue();
member.action = PresenceMessage.Action.enter;
try {
updatePresence(member, null);
Copy link
Member

Choose a reason for hiding this comment

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

  1. Could you elaborate on why you replaced
PresenceMessage itemToSend = new PresenceMessage();
itemToSend.clientId = item.clientId;
itemToSend.data = item.data;
itemToSend.action = PresenceMessage.Action.enter;

with

PresenceMessage member = entry.getValue();
member.action = PresenceMessage.Action.enter;

It's not obvious that that change is correct (won't it have a possibly-stale connectionId?)

  1. Why did you remove the completionListener that was previously being passed to updatePresence? Is there some magic that will turn an async failure into an exception if a completionListener isn't passed that I'm missing?

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 guess I misinterpreted RTP17g.
Is this a good implementation 28531da?

@SimonWoolf SimonWoolf self-requested a review November 10, 2022 18:32
QSD_igor added 3 commits November 11, 2022 11:30
# Conflicts:
#	android/src/main/java/io/ably/lib/push/LocalDevice.java
#	core/src/main/java/io/ably/lib/realtime/Connection.java
#	core/src/main/java/io/ably/lib/rest/DeviceDetails.java
#	core/src/main/java/io/ably/lib/types/ChannelProperties.java
#	core/src/main/java/io/ably/lib/types/PresenceMessage.java
@QuintinWillison
Copy link
Contributor

I'm moving this pull request back to Draft state because it's currently based on top of the wrong branch (integration/version-2) due to the fact that we are very likely to need the protocol version 2 change to be rolled out sooner than our Java/Android SDK version 2 work can be completed, therefore we need this pull request to target the main (default) branch of this repository so that it can be released in a Java/Android SDK version 1.2 patch (per guidance).

Additionally we can't upgrade this SDK to utilise protocol version 2 until #859 has also been completed (because this SDK has been recently reverted to protocol version 1.0 rather than 1.2 because of a regression).

@SimonWoolf
Copy link
Member

Additionally we can't upgrade this SDK to utilise protocol version 2 until #859 has also been completed

Given that protocol v2 completely changes the presence-auto-re-enter behaviour anyway, and also that we're going to be releasing protocol v2 as a patch to the current version, I'd argue that it doesn't make sense to do #859 first, we should just focus on protocol v2

ikbalkaya added a commit that referenced this pull request Jan 13, 2023
This is the first commit that addresses connection resumption issues by picking and adapting some changes from #842

This change only apply channel reattachment and overrides the previous behaviour where pending messages were suspended if a new connection was established with a non-fatal error. Building library in my local I observed this particular commit will increase the number of passed tests by one (previously 11 was passing out of 18, now 12)
ikbalkaya added a commit that referenced this pull request Jan 16, 2023
This commit adds remaining changes (excluding tests from #842

Changes are received as is and only some name refactorings were made. You should check the linked PR to see individual commits. Tests will be added in subsequent PRs
if (pendingMessages.queue != null && !pendingMessages.queue.isEmpty()) {
for (final QueuedMessage queuedMessage : pendingMessages.queue) {
try {
send(queuedMessage.msg, false, null);
Copy link
Contributor

Choose a reason for hiding this comment

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

Completion listener is ignored here

ikbalkaya added a commit that referenced this pull request Jan 24, 2023
This is the first commit that addresses connection resumption issues by picking and adapting some changes from #842

This change only apply channel reattachment and overrides the previous behaviour where pending messages were suspended if a new connection was established with a non-fatal error.
@sacOO7
Copy link
Collaborator

sacOO7 commented Mar 11, 2024

Closing in favor of #842

@sacOO7 sacOO7 closed this Mar 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

DeviceSecret key is required by protocol v2.0 [ably-java] Implement no-connection-serial
7 participants