Tx client submission paralellism

[xdzurman]

Hello, how does the typescript tx client work regarding transaction submissions - are incoming transactions submitted without having to wait for the last one to resolve, or do they have to wait in case of, let's say, network congestion?

[KtorZ]

(I'll move that issue as a Github Discussion if you don't mind)

Regarding the transaction submission, the TypeScript clients gives you a promise-like interface via the TxSubmissionClient and the submitTx method. In principle, you can send multiple requests in "parallel" (although there's no real parallelism in with browser or node.js runtimes) and wait on each promise independently.

Behind the scene, a single TxSubmissionClient will use a single InteractionContext and therefore, a single connection. Ogmios is single-threaded in regards to each connection, which means that while a submitTx is being processed, any concurrent requests is queued and only processed afterwards.

However, an Ogmios server is connected to a local node which has its own local mempool and, from a mini-protocol standpoint, submitting a transaction is really about validating it and adding it to the mempool which takes only few milliseconds. Incidentally, the local tx submission protocol is a blocking protocol and thus when the mempool is full (~128KB in capacity), then any submission will be blocked and apply back-pressure onto clients. Internally, Ogmios doesn't use bounded queues when it comes to WebSocket messages and thus, a client could keep on submitting transaction messages which would start to queue and increase the process heap until exhaustion of your system resources 😬

It may be a good idea to start using bounded queue here with a configurable sizes and sensible defaults 🤔 ... Although, for the transaction submission, a queue of size 1 is probably what makes the most sense... If the local mempool is already full then there's not much value in adding an extra buffer in the front; it won't get transaction faster into the network and simply defer a bit the need for the client application to handle that back-pressure.

[leobel]

Hi @KtorZ, would you mind to explain. a little bit further on this?

Incidentally, the local tx submission protocol is a blocking protocol and thus when the mempool is full (~128KB in capacity), then any submission will be blocked and apply back-pressure onto clients

How clients notice about the back-pressure here? submitTx doesn't have any timeout parameter either returns indicating the mempool is fully in any way?.

So, if a submitTx is performed and the mempool is full, what feedback the client will get?