-
Notifications
You must be signed in to change notification settings - Fork 14
2 - Broadcast - Datatypes #199
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
base: features/broadcast/logging
Are you sure you want to change the base?
Changes from all commits
6804a92
38a909a
45b93a3
f94e935
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,86 @@ | ||
| // Package dtos implements all data transfer objects used from outside the broadcast implementation context. | ||
| package dtos | ||
|
|
||
| import ( | ||
| "context" | ||
| "google.golang.org/protobuf/reflect/protoreflect" | ||
| "time" | ||
| ) | ||
|
|
||
| // Msg defines the message sent from a server to another server or client. The messages should be sent by the router. | ||
| type Msg interface { | ||
| GetBroadcastID() uint64 | ||
| GetMethod() string | ||
| String() string | ||
| } | ||
|
|
||
| // BroadcastMsg is a data transfer object of a message received by another server or client. | ||
| type BroadcastMsg struct { | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It would be quite useful with doc comments for structs, methods, fields etc. Especially, those fields that aren't common knowledge, such as |
||
| Ctx context.Context | ||
| Options BroadcastOptions | ||
| // The address of the client or server that originated the broadcast request | ||
| OriginAddr string | ||
| Info Info | ||
| } | ||
|
|
||
| func (msg *BroadcastMsg) GetBroadcastID() uint64 { | ||
| return msg.Info.BroadcastID | ||
| } | ||
|
|
||
| func (msg *BroadcastMsg) GetMethod() string { | ||
| return msg.Info.Method | ||
| } | ||
|
|
||
| func (msg *BroadcastMsg) String() string { | ||
| return "broadcast" | ||
| } | ||
|
|
||
| // ReplyMsg is similar to BroadcastMsg, but is strictly used for replying to a client. | ||
| type ReplyMsg struct { | ||
| Info Info | ||
| // The address of the client that originated the broadcast request | ||
| ClientAddr string | ||
| Err error | ||
| } | ||
|
|
||
| func (r *ReplyMsg) GetBroadcastID() uint64 { | ||
| return r.Info.BroadcastID | ||
| } | ||
|
|
||
| func (r *ReplyMsg) GetMethod() string { | ||
| return "reply" | ||
| } | ||
|
|
||
| func (r *ReplyMsg) String() string { | ||
| return "reply" | ||
| } | ||
|
|
||
| // Info contains data pertaining to the current message such as routing information, contents, and which server handler | ||
| // should receive the message. | ||
| type Info struct { | ||
| Message protoreflect.ProtoMessage | ||
| BroadcastID uint64 | ||
| Method string | ||
| Addr string | ||
| OriginMethod string | ||
| OriginDigest []byte | ||
| OriginSignature []byte | ||
| OriginPubKey string | ||
| } | ||
|
|
||
| // Client is a data structure used when sending a reply to a client. | ||
| type Client struct { | ||
| Addr string | ||
| SendMsg func(timeout time.Duration, dto *ReplyMsg) error | ||
| Close func() error | ||
| } | ||
|
|
||
| // BroadcastOptions is used to configure a particular broadcast, e.g. by only broadcasting to a subset of the servers in | ||
| // a view. | ||
| type BroadcastOptions struct { | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This question applies to the all types and fields in the PR: Is it intentional that all types and fields are exported? Are they needed outside the
Collaborator
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes, they are. I provided a longer explanation to one of the comments above. 👍 |
||
| ServerAddresses []string | ||
| AllowDuplication bool | ||
| SkipSelf bool | ||
| ProgressTo string | ||
| RelatedToReq uint64 | ||
| } | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,49 @@ | ||
| package errors | ||
|
|
||
| // IDErr should be used when a message with a BroadcastID is sent to a broadcast processor with another BroadcastID. This | ||
| // can happen if a user deliberately changes the BroadcastID of a message. | ||
| type IDErr struct{} | ||
|
|
||
| func (err IDErr) Error() string { | ||
| return "broadcast: wrong ID" | ||
| } | ||
|
|
||
| // MissingClientReqErr signifies that a server tries to reply to a client, but has not yet received the original request | ||
| // form the client. This is especially important when the message does not contain routing information, such as in QuorumCalls. | ||
| type MissingClientReqErr struct{} | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Would be nice to have doc comments on these errors too. |
||
|
|
||
| func (err MissingClientReqErr) Error() string { | ||
| return "broadcast: has not received client req yet" | ||
| } | ||
|
|
||
| // AlreadyProcessedErr is used when a message is received after the broadcast processor has stopped. This means that the | ||
| // server has sent a reply to the client and thus the incoming message needs not be processed. | ||
| type AlreadyProcessedErr struct{} | ||
|
|
||
| func (err AlreadyProcessedErr) Error() string { | ||
| return "broadcast: already processed request" | ||
| } | ||
|
|
||
| // ClientReqAlreadyReceivedErr should be used when a duplicate client request is received. | ||
| type ClientReqAlreadyReceivedErr struct{} | ||
|
|
||
| func (err ClientReqAlreadyReceivedErr) Error() string { | ||
| return "broadcast: client request already received (dropped)" | ||
| } | ||
|
|
||
| // OutOfOrderErr should be used when the preserve ordering configuration option is used and a message is received out of | ||
| // order. | ||
| type OutOfOrderErr struct{} | ||
|
|
||
| func (err OutOfOrderErr) Error() string { | ||
| return "broadcast: the message is out of order" | ||
| } | ||
|
|
||
| // InvalidAddrErr should be used when an invalid server/client address is provided. | ||
| type InvalidAddrErr struct { | ||
| Addr string | ||
| } | ||
|
|
||
| func (err InvalidAddrErr) Error() string { | ||
| return "broadcast: provided Addr is invalid. got: " + err.Addr | ||
| } | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We need a package doc comment for
dtosto explain what it is and provides.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe the package name could be more specific. I can't figure out what it means, so I can't think of something better.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's supposed to contain all dto's that are referenced outside of the broadcast package context (including subfolders). The main idea is to prevent cyclic imports and provide a common namespace for dto's pertaining to broadcast outside of the broadcast context. I.e. instead of referencing processor.RequestDto and router.Msg in gorums/server.go, I thought it would be easier to use dtos.RequestDto and dtos.Msg. Hoping this would reduce the cognitive load of developers working with higher level functionality such as nodes/channels, as both processor and router are implementation details specific to broadcasting.
Naming things are not my strong suit, so feel free to rename/change. If you think it is better, the dtos could also be moved to their respective packages (RequestDto -> processor, the rest -> router).