🔮[RFC #0001]: Large pressure measurement scheme

[BanTanger]

[RFC #0000] Large pressure measurement scheme

Meta

• Name: (Large pressure measurement scheme)
• Start Date: (2023-7-20)
• Author(s): (@BanTanger )
• Status: Draft
• RFC Pull Request: (leave blank)
• OpenIMSDK Pull Request: (leave blank)
• OpenIMSDK Issue: (leave blank)
• Supersedes: (put "N/A" unless this replaces an existing RFC, then link to that RFC)

📇Topics

• [RFC #0000] OpenIMSDK proposal template
  • Meta
  • 📇Topics
  • Summary
  • Definitions
  • Motivation
  • What it is
  • How it Works
  • Migration
  • Drawbacks
  • Alternatives
  • Prior Art
  • Unresolved Questions
  • Spec. Changes (OPTIONAL)
  • History

Summary

One paragraph explanation of the feature.

A few directions

1. Millions of users register

2. How to support DAU 100W and 10W online at the same time

3. Test 1 second and 1W message can be sent normally under the situation of 100,000 users online.

4. View resource occupation ratio, delay, message reliability

Definitions

Make a list of the definitions that may be useful for those reviewing. Include phrases and words that OpenIMSDK authors or other interested parties may not be familiar with.

Motivation

• Why should we do this?
• What use cases does it support?
• What is the expected outcome?

What it is

This provides a high level overview of the feature.

• Define any new terminology.
• Define the target persona: OpenIMSDK author, OpenIMSDK user, platform operator, platform implementor, and/or project contributor.
• Explaining the feature largely in terms of examples.
• If applicable, provide sample error messages, deprecation warnings, or migration guidance.
• If applicable, describe the differences between teaching this to existing users and new users.

How it Works

What needs to be discussed is how to achieve 10W online users on a machine, the largest TCP connection number of a machine is 6W, and the currently recorded users in the SDK to initialize various listeners, callbacks, and news local libraries.For storage, for the pressure measurement angle, the use of these users is only a message. They do not need to receive the message, and the content does not need to be stored locally

The current proposal is:

1. The long connection of SDK users log in to open, the server side does statistics, whether there will be a lack of or the user's disconnection.

2. SDK sends messages to Server, and view the seq number of the server side to detect whether the message from the client to the server is lost

3. SDK synchronization message: Make differences through the largest local seq and Server's maximum seq, pull data, check the synchronization time consumption

4. Users with a backlog of 100,000 messages to log in, check the synchronous time consumption, and enter the session to draw historical news if it will cause various functions to stuck

Migration

This section should document breaks to public API and breaks in compatibility due to this RFC's proposed changes. In addition, it should document the proposed steps that one would need to take to work through these changes. Care should be give to include all applicable personas, such as platform developers, OpenIMSDK developers, OpenIMSDK users and consumers of OpenIMSDK images.

Drawbacks

Why should we not do this?

Alternatives

• What other designs have been considered?
• Why is this proposal the best?
• What is the impact of not doing this?

Prior Art

Discuss prior art, both the good and bad.

Unresolved Questions

• What parts of the design do you expect to be resolved before this gets merged?
• What parts of the design do you expect to be resolved through implementation of the feature?
• What related issues do you consider out of scope for this RFC that could be addressed in the future independently of the solution that comes out of this RFC?

Spec. Changes (OPTIONAL)

Does this RFC entail any proposed changes to the core specifications or extensions? If so, please document changes here. Examples of a spec. change might be new lifecycle flags, new OpenIMSDK.toml fields, new fields in the OpenIMSDKage label, etc. This section is not intended to be binding, but as discussion of an RFC unfolds, if spec changes are necessary, they should be documented here.

History