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

Encapsulate Protocol Details in review-protocol (Server Side) #13

Open
47 tasks
msk opened this issue Jun 24, 2024 · 0 comments
Open
47 tasks

Encapsulate Protocol Details in review-protocol (Server Side) #13

msk opened this issue Jun 24, 2024 · 0 comments
Assignees

Comments

@msk
Copy link
Member

msk commented Jun 24, 2024

Currently, a server application using review-protocol has to rely on low-level functions from the oinq crate (e.g., frame::send_raw) to handle message exchanges. This requires manual designation of message kinds using enum RequestCode, which goes against our goal of encapsulating all protocol details within review-protocol.

This task aims to provide high-level functions in the server module of review-protocol that a server application can utilize to send specific types of messages. This will simplify the interaction between the server and its clients, ensuring that the server does not need to directly specify RequestCode or call oinq functions.

Objectives

  • Implement high-level functions in the server module of review-protocol for sending messages.
  • Ensure these functions abstract away the details of RequestCode.

Tasks

  1. Define High-Level Functions:

    • Identify the common types of messages a server needs to send.
    • Define corresponding high-level functions in the server module of review-protocol.
  2. Encapsulate Message Kind (RequestCode):

    • Within each high-level function, map the specific operation to the appropriate RequestCode.
    • Ensure that these mappings are not exposed in the public API.
  3. Integrate with oinq:

    • Use oinq internally within review-protocol to send messages.
    • Ensure that oinq functions are called with the correct parameters based on the high-level function calls.

Example

Instead of a server doing this:

let code = RequestCode::SpecificOperation;
let buf = // serialize a message with the code and parameters
oinq::send_raw(send, buf);

REview should be able to do this:

review_protocol::server::send_specific_operation_message(...);

Requests initiated by server

  • AllowList
  • BlockList
  • EchoRequest
  • GetConfig
  • InternalNetworkList
  • ProcessList
  • Reboot
  • ReloadFilterRule
  • ResourceUsage
  • SamplingPolicyList
  • SetConfig
  • Shutdown
  • TorExitNodeList
  • TrustedUserAgentList

Requests initiated by client

  • GetAllowList
  • GetBlockList
  • GetConfig
  • GetDataSource
  • GetIndicator
  • GetIndicatorList
  • GetInternalNetworkList
  • GetModel
  • GetModelNames
  • GetOutliers
  • GetPretrainedModel
  • GetTidbList
  • GetTidbPatterns
  • GetTorExitNodeList
  • GetTrustedDomainList
  • GetTrustedUserAgentList
  • InsertColumnStatistics
  • InsertDataSource
  • InsertEventLabels
  • InsertIndicator
  • InsertModel
  • InsertTidb
  • InsertTimeSeries
  • PasswordRecovery
  • RemoveIndicator
  • RemoveModel
  • RemoveTidb
  • RenewCertificate
  • Unknown
  • UpdateClusters
  • UpdateModel
  • UpdateOutliers
  • UpdateTidb
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

No branches or pull requests

1 participant