Skip to content

feat(ETH transport & heartbeats): various enhancements/features#2058

Merged
shamardy merged 55 commits intodevfrom
eth-ws-and-heartbeats
Feb 26, 2024
Merged

feat(ETH transport & heartbeats): various enhancements/features#2058
shamardy merged 55 commits intodevfrom
eth-ws-and-heartbeats

Conversation

@onur-ozkan
Copy link
Copy Markdown

@onur-ozkan onur-ozkan commented Jan 23, 2024

  • ETH websocket transport
    • komodo-defi-proxy signed messages implementation
    • lock & wait free request pipelines for response quickness
    • expirable hashmap implementation (so request contexts can be cleaned in REQUEST_TIMEOUT_AS_SEC)
  • Refactor web3 contexts, connection rotation and remove singular web3 field from ETH coin
  • [ ] Implementing and using fn with_socket for ETH COIN_BALANCE event (3c2313a)
  • Heartbeats implementation for streaming channels.
  • Refactored node rotation (moved from transport to protocol level, so it can be rotated across different transports)
  • RPC abstraction for ETH

@onur-ozkan onur-ozkan force-pushed the eth-ws-and-heartbeats branch from fbf0dad to 4663949 Compare January 23, 2024 20:07
@onur-ozkan onur-ozkan changed the title feat(transport, streaming channels): various features on ETH and streaming channels feat(ETH transport & heartbeats): various enhancements/features Jan 23, 2024
@onur-ozkan onur-ozkan force-pushed the eth-ws-and-heartbeats branch from 08c44d5 to e39bede Compare January 24, 2024 12:49
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Signed-off-by: onur-ozkan <work@onurozkan.dev>
@onur-ozkan onur-ozkan force-pushed the eth-ws-and-heartbeats branch from ba35834 to 6973845 Compare January 26, 2024 13:11
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Signed-off-by: onur-ozkan <work@onurozkan.dev>
@onur-ozkan onur-ozkan force-pushed the eth-ws-and-heartbeats branch from 59b78de to d770af9 Compare January 31, 2024 13:36
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Copy link
Copy Markdown
Collaborator

@mariocynicys mariocynicys left a comment

Choose a reason for hiding this comment

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

Thanks!

Q: To get my thoughts straight, the websocket_transport.rs implementation is thread safe because we get a new id (hashmap key) each time thus we will never access (read/write) the same key from two threads at the same time?

Web3Transport::Metamask(metamask) => metamask.execute(method, params.clone()),
};

match execute_fut.timeout(Duration::from_secs(15)).await {
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

Could you define this 15 literal as a const instead? Also, isn't 15 a very long time :o

Copy link
Copy Markdown
Author

@onur-ozkan onur-ozkan Feb 22, 2024

Choose a reason for hiding this comment

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

Made the Duration constant altogether and used in EthCoin::get_live_client and EthCoin::try_rpc_send.

let response_map = unsafe { &mut *self.responses.0 };
let _ = response_map.insert(request_id, res_bytes);

notifier.send(()).expect("receiver channel must be alive");
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

Won't this ever panic?

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

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

No. Caller is awaiting for the response through this channel. If it ever drop before that, we should panic as something def. going wrong.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

ahaa I was thinking this was a notifier for external communication (not us).

shamardy
shamardy previously approved these changes Feb 22, 2024
Copy link
Copy Markdown
Collaborator

@shamardy shamardy left a comment

Choose a reason for hiding this comment

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

🔥

Signed-off-by: onur-ozkan <work@onurozkan.dev>
@onur-ozkan
Copy link
Copy Markdown
Author

Q: To get my thoughts straight, the websocket_transport.rs implementation is thread safe because we get a new id (hashmap key) each time thus we will never access (read/write) the same key from two threads at the same time?

That's part of it. Each request utilizes an atomic ID and only makes modifications using that ID. Additionally, we are waiting for notification from another thread to read and remove the key, ensuring that we don't attempt to read and delete it while another thread is attempting to write to it. This sequential computing is ensured via the thread channel notification.

laruh
laruh previously approved these changes Feb 23, 2024
Copy link
Copy Markdown

@laruh laruh left a comment

Choose a reason for hiding this comment

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

LGTM!

Copy link
Copy Markdown
Collaborator

@mariocynicys mariocynicys left a comment

Choose a reason for hiding this comment

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

This sequential computing is ensured via the thread channel notification.

I get the point in that we process all the responses in a single worker thread, but don't we ever access the map from another thread (even with a different key)?

e.g. are we always sure ...

Signed-off-by: onur-ozkan <work@onurozkan.dev>
@onur-ozkan onur-ozkan linked an issue Feb 26, 2024 that may be closed by this pull request
mariocynicys
mariocynicys previously approved these changes Feb 26, 2024
Copy link
Copy Markdown
Collaborator

@mariocynicys mariocynicys left a comment

Choose a reason for hiding this comment

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

LGTM, Thanks!

Signed-off-by: onur-ozkan <work@onurozkan.dev>
@onur-ozkan onur-ozkan force-pushed the eth-ws-and-heartbeats branch from 8200379 to 537a020 Compare February 26, 2024 12:47
@shamardy shamardy merged commit 6aa5d66 into dev Feb 26, 2024
@shamardy shamardy deleted the eth-ws-and-heartbeats branch February 26, 2024 13:51
dimxy pushed a commit to dimxy/komodo-defi-framework that referenced this pull request Mar 13, 2024
* dev:
  feat(indexeddb): advanced cursor filtering impl (GLEECBTC#2066)
  update dockerhub destination repository (GLEECBTC#2082)
  feat(event streaming): configurable worker path, use SharedWorker (GLEECBTC#2080)
  fix(hd_tests): fix test_hd_utxo_tx_history unit test (GLEECBTC#2078)
  feat(network): improve efficiency of known peers handling (GLEECBTC#2074)
  feat(nft): enable eth with non fungible tokens (GLEECBTC#2049)
  feat(ETH transport & heartbeats): various enhancements/features (GLEECBTC#2058)
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

Successfully merging this pull request may close these issues.

heartbeats for event stream channels

5 participants