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

Client RPC migration #509

Merged
merged 38 commits into from
Mar 24, 2023
Merged

Client RPC migration #509

merged 38 commits into from
Mar 24, 2023

Conversation

tegefaulkes
Copy link
Contributor

@tegefaulkes tegefaulkes commented Feb 27, 2023

Description

This PR deals with migrating the clientRPC handlers and code to using the new Agnostic RPC system.

It consists of taking the existing handler code within client/services and transplanting it into the new RPC system from #249 .

pagination

Any handlers that stream data need to support the pagination parameters and propagate them. The required parameters are seek: id, number: number, order: 'asc'|'desc'. Most code that streams an output with a generator already support pagination. But in some cases where it is not already supported it needs to be updated. As for the handler parameters, the message should include the following

type paginationMessage = {
id: string,
order: 'asc' | 'desc',
number: number,
}
Binary data

Currently there are two cases where sending binary data is applicable. The IDs such as NodeID, or VaultId. These are converted to an encoded string form just for readability of the message. Using the NodeIdEncoded and VaultIdEncoded for of the Ids.

The 2nd case is file contents. Currently these are converted to a binary string when provided within a message using Buffer.toString('binary'). This is pretty limiting to small amounts of data so it is subject to change. If we need to send larger files we need to stream it using a raw handler to implement it as a raw binary stream. This has complications such it not supporting any middleware so we need to implement authentication logic withing the raw handler.

Standard message structure

To standardise the message structure and types across all messages we are leveraging the typescripts type system. Since it's pretty powerful we can compose messages and message types together effectively.

For example we have basic type messages that can be composed to make more complex messages

type NodeIdMessage = {  
  nodeIdEncoded: NodeIdEncoded;  
};

export type AddressMessage = {
  host: string;
  port: number;
};

type NodeAddressMessage = NodeIdMessage & AddressMessage;

type NodesAddMessage = NodeAddressMessage & {  
  force?: boolean;  
  ping?: boolean;  
};

Issues Fixed

Tasks

  1. Migrate handlers.
    1. agent
    2. gestalts
    3. identities
    4. keys
    5. nodes
    6. notifications
    7. vaults
  2. Migrate tests.
    1. agent
    2. gestalts
    3. identities
    4. keys
    5. nodes
    6. notifications
    7. vaults
  3. Update BIN code to use new RPC system.
  4. Remove old client GRPC code and tests.

Final checklist

  • Domain specific tests
  • Full tests
  • Updated inline-comment documentation
  • Lint fixed
  • Squash and rebased
  • Sanity check the final build

@tegefaulkes tegefaulkes self-assigned this Feb 27, 2023
@ghost
Copy link

ghost commented Feb 27, 2023

👇 Click on the image for a new way to code review

Review these changes using an interactive CodeSee Map

Legend

CodeSee Map legend

@tegefaulkes tegefaulkes force-pushed the feature-client_migration branch from ecf309c to b734d2d Compare February 28, 2023 08:12
@tegefaulkes tegefaulkes changed the base branch from feature-websocket_client to staging March 1, 2023 00:04
@tegefaulkes tegefaulkes force-pushed the feature-client_migration branch from b734d2d to 9258456 Compare March 1, 2023 00:07
@tegefaulkes
Copy link
Contributor Author

tegefaulkes commented Mar 1, 2023

Re-based on staging after #506 merged. Staging is now the base branch for this PR.

@tegefaulkes
Copy link
Contributor Author

Only two handlers have been converted to server streams so far.

  • Nodes get all
  • Notifications read

@CMCDragonkai
Copy link
Member

Only two handlers have been converted to server streams so far.

  • Nodes get all
  • Notifications read

Should go into the task list so it's clearer.

@tegefaulkes
Copy link
Contributor Author

tegefaulkes commented Mar 7, 2023

While migrating tests I notices that the vaults clone, pull and scan handlers don't have tests. I'll need to create some for them.

@CMCDragonkai
Copy link
Member

Those 2 are particularly tricky due to the GRPC hacks we had to do to allow things like git pull to work.

With the new RPC system, they have to simulate a stream for the git operations to run over.

Did you manage to simplify the whole architecture? That is a duplex stream that "switches" over to binary data, and then passes Git's HTTP protocol transparently over it?

There was also random hacks for getting exceptions out of isogit so that it would turn into GRPC exceptions, this should also be considered too.

@CMCDragonkai
Copy link
Member

BTW the above is probably more related to the agent service, and not so much client service.

BUT the performance of vault cloning/sync was so bad previously. Please look into benchmarking this so we can have fast cloning and sync, and it should be much faster now without so many layers of abstraction once QUIC and our new RPC is fully integrated.

@CMCDragonkai
Copy link
Member

All the fixmes are going to addressed in this PR?

@CMCDragonkai
Copy link
Member

Hey @tegefaulkes remember address my comments above too. If there needs to be an issue for the agent migration and git tunneling, please remember to create it too.

@tegefaulkes
Copy link
Contributor Author

I've created two new issues.
#512
#511

@tegefaulkes
Copy link
Contributor Author

As for the FIXME's, there are two that are relevant this PR. one will be addressed and the 2nd one is addressed by #511 now so i'll remove it.

@tegefaulkes
Copy link
Contributor Author

The ErrorPolykeyRemote expects to have some metadata about the connection. This includes nodeId, host port and method name. The problem is we don't have this information in the scope where this error is created.

So I have two options, I make this data optional so I don't have to fill it in. Or I add some way to provide this information to the RPCClient. for each call.

We should have the information available but it doesn't feel right that the RPCClient should have this information since it's an abstraction above any networking. If I had to add it in then the streamPairCreateCallback should be the thing providing it.

@tegefaulkes
Copy link
Contributor Author

Just a note, when generating test data that needs to be stringified and parsed as JSON. Any values that are -0 become 0 and anything undefined will be removed. This has the effect of a round trip of stringify and parsing a JSON object will sometimes not be equal. This can result in random test failures.

@CMCDragonkai
Copy link
Member

CMCDragonkai commented Mar 13, 2023 via email

@tegefaulkes
Copy link
Contributor Author

I think I'll leave removing the GRPC code for the agent migration. It's much easier to remove the whole GRPC and network domain at that stage. It does mean we have some failing GRPC tests hanging about.

Otherwise this should be good to merge after some clean up.

- created agent handlers and tests
- adding gestalts handlers
- migrating gestalts handlers
- migrating identities handlers
- adding identities handlers
- adding identities handlers
- adding keys handlers
- migrating nodes handlers
- migrating notifications handlers
- migrating vaults handlers
- migrating vaults handlers

[ci skip]
- migrating keys tests
- migrating nodes tests
- migrating notifications tests
- migrating notifications tests
- migrating vaults tests

[ci skip]
- removing client GRPC and using agnostic RPC
- updating agent bin code
- updating identities bin code
- updating keys bin code
- updating nodes bin code
- migrating secrets bin code
- migrating vaults bin code

[ci skip]
@tegefaulkes tegefaulkes force-pushed the feature-client_migration branch from 9b9b0b2 to cccc5c5 Compare March 13, 2023 06:29
@tegefaulkes
Copy link
Contributor Author

Cleaned up commit history

@tegefaulkes
Copy link
Contributor Author

This should be good to merge now.

@tegefaulkes
Copy link
Contributor Author

I think #510 is the next thing for me to work on. That is assuming @CMCDragonkai is still working on the Quic stuff otherwise I can start on that. I can make a start on #512 but I can't test it works without Quic working. #511 is low priority, things still work without it. We just miss out on some expected behaviour with key changes.

@CMCDragonkai
Copy link
Member

I won't be getting to QUIC anytime soon. So you can start on #510.

@tegefaulkes
Copy link
Contributor Author

Cleaning up history now. Almost ready for merge.

tegefaulkes and others added 18 commits March 24, 2023 13:35
… injected into the `PolykeyAgent`.

[ci skip]
Previously the `clientManifest` depended on the whole code base due to the handlers. This has now been seperated out, so it only depends on types.

[ci skip]
… `detail` property, made `RPCServer` extend `EventTarget`
…il reconstruction via transform stream, and reverse pair propagation of cancellation event
@tegefaulkes tegefaulkes force-pushed the feature-client_migration branch from 73b162f to 043066d Compare March 24, 2023 02:35
@tegefaulkes
Copy link
Contributor Author

This is ready to merge. All that is left to do is house keeping.

@CMCDragonkai
Copy link
Member

What housekeeping?

@tegefaulkes tegefaulkes force-pushed the feature-client_migration branch from 043066d to 60e3d13 Compare March 24, 2023 03:34
@tegefaulkes
Copy link
Contributor Author

I just had to update or create issues before I could resolve the last review comment. it's done now.

I checked and there is no docs changes commited.

I've re-enabled CI so this should be good to merge any time now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

fix: node discovery warning message spam
2 participants