Solana: port websocket api from web3.js

[mschneider]

onAccountChange onLogs onProgramAccountChange onRootChange onSignature onSignatureWithOptions onSlotChange onSlotUpdate removeAccountChangeListener removeOnLogsListener removeProgramAccountChangeListener removeRootChangeListener removeSignatureListener removeSlotChangeListener removeSlotUpdateListener

[pSN0W]

@mschneider willing to work on this issue.

[mschneider]

alright! please make sure you check the progress on issue #9 the connected PR is still unmerged

[pSN0W]

Hey, Sorry to bother you, but what's the update on the connected PR. It contain's AccountSubscriber which is useful for the functionalities I am trying to implement. How do you propose I move forward?

[mschneider]

use account subscriber and focus on issue 41 mango v3 functionality is not important at this point

[pSN0W]

Alright I will.

[pSN0W]

Hey, I am done with the code, before making a pull request I am just sharing the implementation detail for the same. The websocket works by creating two threads one thread is used for continuously reading from the websocket while other one is use to continuously writing to the socket. The implementation uses:

• a map to store the callbacks so that they can be called once notification for them is recieved.
• a queue for pending subscription to send to websocket.
• a queue for pending unsubscription to send to websocket.
• a boolean variable justSubscribed denoting that a subscription request is just sent to the websocket.
• a boolean variable justUnSubscribed denoting that an unsubscription request is just sent to the websocket.

In the write thread :

• if pendingSubscription is empty and pendingUnSubscription is also empty, thread is set to wait as there is nothing to write.
• else if justSubscribed is true or justUnsubscribed is true thread is set to wait as beast doesn't support calling two async_write at the same time.
• else if pendingSubscription is not empty. The front of the queue is accessed and subscription request is sent to websocket. justSubscribed is set to true.
• else front of the queue of pendingUnsubscription is accessed and unsubscription request is sent to websocket. justUnsubscribed is set to false.

In the read thread, it can read two types of response. One is the notification for the subscription and another is the response to the subscription or unsubscription request. The way this thread works is :

• if justSubscribed is true. then the response we read is response of subscription request. If the subscription was successful. We access the front of the pendingSubscription queue and get the callback from there and then put it in the callback map with the received subscription id as the key. pendingSubscription is popped and justSubscribed is set to false to continue writing.
• else if justUnSubscribed is true. then the response we read is response of unsubscription request. If the unsubscription was successful. We access the front of the pendingUnSubscription queue and get the subscription id to unsubscribe for the key value pair with this subscription id in the callback map is removed. pendingUnSubscription is popped. justUnsubscribed is set to false to continue writing.
• else it's an account notification so get the subscription id from the notification. Access the callback with this sub id from the callback map and call it.

I am also attaching a diagram explaining the same workflow. websocket_workflow.pdf

The advantage I see of this implementation is that we are limiting everything to two threads and to do more subscription only the subscriptions are required to be pushed to the pendingSubscription map. @aniketfuryrocks has volunteered to look at my code and point out the necessary optimisations.@mschneider and @godmodegalactus can you look at this implementation and suggest required changes so that I can move forward towards making a PR for the same.

[mschneider]

For a review of an architecture proposal it's easier to look at the interfaces / declaration, rather than the control flow logic. Header file and some pseudo code for tests to see the API in use would be perfect.

@aniketfuryrocks please focus on rust, @OmkarAcharekar should help with review from your end.

[godmodegalactus]

Yes I agree with @mschneider, Could you please create a PR to understand your progress on this subject.