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

Remove gRPC code previously used for the xpring SDK & enable gRPC on localhost by default #4272

Closed
wants to merge 3 commits into from

Conversation

cjcobb23
Copy link
Contributor

There was a lot of gRPC code in rippled that has long been deprecated. It was used for the xpring sdk, which has been abandoned. Some of the gRPC code is used for reporting mode and clio however. This PR removes the code that is no longer needed, and only retains the gRPC code needed for clio and reporting mode.

@nbougalis
Copy link
Contributor

HALLELUJAH!

Copy link
Contributor

@natenichols natenichols left a comment

Choose a reason for hiding this comment

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

After a first pass I have a couple of questions

#port = 50051
#ip = 0.0.0.0
#secure_gateway = 127.0.0.1
[port_grpc]
Copy link
Contributor

Choose a reason for hiding this comment

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

Why are we uncommenting this in the rippled-example.cfg. Do we want gRPC to be enabled by default?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

We talked about this in the huddle. I asked if we could uncomment this by default, and the agreement was yes if the xpring sdk code was removed.

@@ -25,16 +25,6 @@ message LedgerSpecifier
}
}

// Next field: 3
message LedgerRange
Copy link
Contributor

Choose a reason for hiding this comment

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

Do we use this in Clio or reporting mode, or only get the LedgerRange from the ledger subscription stream?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

We don't use this in clio or reporting mode


/////////////////////////////////////////////////////////////////////////////
// The below methods do not mimic the JSON API exactly, and are mostly binary

// Get a specific ledger, optionally including transactions and any modified,
// added or deleted ledger objects
rpc GetLedger(GetLedgerRequest) returns (GetLedgerResponse);
Copy link
Contributor

Choose a reason for hiding this comment

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

Can we also remove GetLedgerDiff() and GetLedgerEntry? AFAIK, Clio only uses GetLedgerRequest and GetLedgerDataRequest

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Those RPCs are not part of the xpring sdk, and I actually think they could be useful. If we want to remove them, we should discuss and do it as part of a separate PR.

}
return {response, status};
}

Json::Value
populateJsonResponse(
Copy link
Contributor

Choose a reason for hiding this comment

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

I don't actually know what this looked like before we added these gRPC methods, so take what I say next with a grain of salt.

Should we leave doTxHelp and populateJsonResponse as their own functions, or move it into doTx(). It occurs to me that we may have split this out to enable code reuse between the gRPC and JSON-RPC endpoints.

Is it worth leaving doTxHelp as a helper function?

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 thought about this. We could move it, but I think since we already went through the work of breaking up this function, we should keep the helper function as is. What if we want to add a different response interface in the future? The helper function would be useful. I don't see it causing a problem as is.

@@ -773,25 +773,6 @@ class ReportingETL_test : public beast::unit_test::suite
testNeedCurrentOrClosed()
{
testcase("NeedCurrentOrClosed");
{
org::xrpl::rpc::v1::GetAccountInfoRequest request;
Copy link
Contributor

Choose a reason for hiding this comment

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

Why are we removing this test? Flagging this because it's in ReportingETL_test.cpp

Copy link
Contributor Author

Choose a reason for hiding this comment

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

GetAccountInfoRequest is removed. This won't compile if we leave it.

Copy link
Collaborator

@scottschurr scottschurr left a comment

Choose a reason for hiding this comment

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

Thanks so much for taking care to this @cjcobb23! It's great to see so much of this code gone. I left a couple of comments that may be relevant. But other than those this looks to me like it is good to go. 👍

Comment on lines 1632 to 1635
[port_grpc]
port = 50051
ip = 0.0.0.0
secure_gateway = 127.0.0.1
Copy link
Collaborator

Choose a reason for hiding this comment

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

Surprised to see this stanza un-commented as part of this pull request. There should be very few circumstances where this is useful, no? I could imagine it left commented out or even removed?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This is just to make it easier for people to run clio, since clio uses this port to talk to rippled. Though now that I'm thinking about it, it might be best to change the IP to 127.0.0.1, so that way the port will only listen locally by default. If someone is running clio remotely, they'll need to modify their config anyways.

@@ -23,9 +23,6 @@
#include <ripple/protocol/LedgerFormats.h>
#include <ripple/protocol/TxFormats.h>

#include "org/xrpl/rpc/v1/ledger_objects.pb.h"
Copy link
Collaborator

Choose a reason for hiding this comment

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

Seems like this entire file should be removed? Hallelujah!

Copy link
Collaborator

@scottschurr scottschurr left a comment

Choose a reason for hiding this comment

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

Thanks for the update @cjcobb23. I think there are a couple more things that need to be tuned.

  1. The RippledCore.cmake file needs to have the KnownFormatToGRPC_test.cpp file removed.
  2. The ordering.txt file needs to be tweaked so the levelization CI test passes.

If it's helpful, here's a commit that makes those changes: scottschurr@f5d9f05

Once those changes are made I think this pull request is good to go.

Copy link
Collaborator

@scottschurr scottschurr left a comment

Choose a reason for hiding this comment

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

👍 Looks great! Thanks.

@seelabs seelabs added the Passed Passed code review & PR owner thinks it's ready to merge. Perf sign-off may still be required. label Oct 12, 2022
@manojsdoshi manojsdoshi mentioned this pull request Oct 13, 2022
@intelliot intelliot changed the title Remove gRPC code previously used for the xpring SDK Remove gRPC code previously used for the xpring SDK & enable gRPC on localhost by default Feb 22, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Passed Passed code review & PR owner thinks it's ready to merge. Perf sign-off may still be required.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants