rpc.Client struct needs to implement a close method for its own socket about solana-go

[gagliardetto]

gm @whymidnight

an RPC client (client := rpc.New(endpoint)) is meant to be only one and used many times, potentially by many different callers at the same time.

[gagliardetto]

what's your use-case that requires throw-away clients?

[whymidnight]

at one point in the past, i had baked in anchor events and spawned goroutines that contained some logic with many rpc calls upon receiving the message over the rpc websocket. i wasnt sure if this was threadsafe at the time so it seemed more elegant to instead instance a new rpc struct inside the callback so that each goroutine had its own rpc client. however this didnt scale because of the above issue.

additionally, this approach of passing an rpc.Client pointer to functions that require does not allow for go modules to contain their own rpc lifecycle like - for instance: i have a utilities module for sending transactions, parsing chain state, etc; another module for my chain program; and some arbitrary third module.

if i wanted to import these modules in a disparate codebase, would require to also declare rpc.New in the main module which could be alleviated if the above modules could instance rpc.New themselves. however these modules must close their sockets to prevent the main module from exceeding open sockets.

[gagliardetto]

and you're doing the same thing with websocket clients?

[whymidnight]

well i can foresee this applying to websocket clients as well like awaiting for signature confirmations via ws in a confined thread inside the main thread.

[gagliardetto]

the websocket client is also thread-safe and supports multiple concurrent subscriptions.

[whymidnight]

however the http client design means that disparate modules are dependent on the main thread passing a pointer which isn't as elegant when modules could manage their own lifecycle of it. however is actually probably bad design in the bigger scheme of things since this means >1 rpc.Client versus 1 global rpc.Client. as the issue of exceeding open sockets could still arise.

[gagliardetto]

the rpc client is made to be as efficient as possible (reusing TCP connections, enabling gzip compression, etc.)

if you don't want all of that, you'll waste time & resources reconnecting for each RPC call (maybe even having to make a DNS resolution).

[gagliardetto]

for instance: i have a utilities module for sending transactions, parsing chain state, etc; another module for my chain program; and some arbitrary third module.

great! use 3 rpc clients 😁

[whymidnight]

if you don't want all of that, you'll waste time & resources reconnecting for each RPC call (maybe even having to make a DNS resolution).

thats exactly what i needed to hear. it took a discussion to realise this lol. thank you! i'll close this issue now.

much love,
D.