-
Notifications
You must be signed in to change notification settings - Fork 669
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
Improve p2ptest.Client
#3437
base: master
Are you sure you want to change the base?
Improve p2ptest.Client
#3437
Conversation
Signed-off-by: Joshua Kim <[email protected]>
Signed-off-by: Joshua Kim <[email protected]>
Signed-off-by: Joshua Kim <[email protected]>
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.
One small nit
network/p2p/p2ptest/client.go
Outdated
NodeID ids.NodeID | ||
ServerNodeID ids.NodeID |
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.
nit: can we change to nodeID and peerNodeID or myNodeID and peerNodeID?
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.
NodeID
->MyNodeID
seems unnecessary becauseClient.NodeID
already disambiguates the nameServerNodeID
->PeerNodeID
I could get behind... but I wouldn't be sure what to nameClient
asClient
talking toServer
seems more natural thanClient
talking toPeer
. I guess we could call itSender
?
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.
Ya I think you're right client.NodeID
should be clear. I prefer PeerNodeID
since it's a p2p network rather than single server and updating Handler
to PeerHandler
or ServerHandler
would make it a little more clear.
network/p2p/p2ptest/client.go
Outdated
|
||
require.NoError(t, serverNetwork.AddHandler(0, handler)) | ||
return clientNetwork.NewClient(0) | ||
c.Handler.AppGossip(ctx, c.NodeID, appGossipBytes) |
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.
Why make AppGossip
send to ourselves?
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 doesn't, it sends it to the server handler with the sender as us. Maybe I can make this more clear by naming Handler
to ServerHandler
.
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.
Ah ya I think renaming would make that more clear
Signed-off-by: Joshua Kim <[email protected]>
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.
Minor nit on potential name change - then this LGTM
RangeProofClient p2p.ClientInterface | ||
ChangeProofClient p2p.ClientInterface |
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.
I wish there was a better name for this ClientInterface
just looks non-go-ie
// Client is a testing implementation of p2p.ClientInterface against a specified | ||
// server handler. The zero value of Client times out AppRequest and drops | ||
// outbound AppGossip messages. | ||
type Client struct { |
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.
What if you instead created a p2ptest.Sender
that wraps a p2p.Handler
and then use it in a real p2p.Client
? I'm not as familiar with this code as you all are, but this reminded me of the gRPC testing strategy of using a real stack while faking the network connection with bufconn.
type Sender struct {
Handler p2p.Handler
}
var _ common.AppSender = (*Sender)(nil)
func (s *Sender) SendAppRequest(ctx context.Context, nodeIDs set.Set[ids.NodeID], requestID uint32, appRequestBytes []byte) error {
// ...
s.Handler.AppRequest(ctx, nodeIDs.List()[0], time.Time{}, appRequestBytes)
// How would this plumb to the response / error methods to maintain the expected behaviour?
// ...
}
func (s *Sender) SendAppGossip(ctx context.Context, config common.SendConfig, appGossipBytes []byte) error {
// ...
s.Handler.AppGossip(ctx, config.NodeIDs.List()[0], appGossipBytes)
// ...
}
// ... response and error methods
Context: @StephenButtolph asked if I could think of a different name for ClientInterface
and my response was that I actually think it's a bit non-go-ie to have it defined alongside the *Client
.
clientNodeID, | ||
serverNodeID, | ||
) | ||
c := p2ptest.Client{ServerHandler: h} |
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.
(style) This is too far from its usage to just be called c
. I'd move the declaration to the end (as against renaming it) because I spent the whole time trying to understand where it's used. Some other variables (at least the handler) should also be addressed for the same reason.
Why this should be merged
p2ptest
Client
is now usefulHow this works
p2p.ClientInterface
How this was tested