3

I want to load balance commands to my nodes. But not all nodes are equally fast. Some commands do not need a node that is completely up to date to finish successfully, like attachToTangle. Therefore I want to make sure that the slower nodes only get commands where it is not so important to be up to date.

What are these commands? Can someone provide a list of them (without the adminstrative commands related to node info and neighbors) and a short explanation why they can/cannot/should not be processed by a delayed node?

For example: what about storeTransactions and broadcastTransactions?

Bonus question: are there some commands that build on one another? With that I mean that it is important that the same node processes the next command from the same client.

Improve this question
8
  • Quick response to the bonus question : no (it's a rest API... so it is stateless)
    – ben75
    Jul 24, 2018 at 11:45
  • I do not think that it is stateless as every node might have different data. For example if node A provides tips, node B does not necessarily know them (yet?).
    – mio
    Jul 24, 2018 at 13:07
  • Indeed, but it is not a problem. A node don't need to know branch and trunk to broadcast a transaction.
    – ben75
    Jul 24, 2018 at 13:32
  • @SaintHill for examply by comparing the latestMilestoneIndex of several nodes. Usually the slower nodes are only off by one from my experience.
    – mio
    Jul 25, 2018 at 6:29
  • @SaintHill I do not provide proofs. The method I use is to query all the milestones of the load balanced nodes and compare them. Another possibility would be to query public nodes. Certainty is only relative as it is related to the view of the nodes you choose. Afaik there is no way to query the milestone from the coo directly.
    – mio
    Jul 26, 2018 at 10:43

1 Answer 1

Reset to default
3

Here is the list of all API calls (except nodeInfo and neighbors related calls), with a brief description of what it does. Hope it helps.

(don't hesitate to edit, or leave a comment is something is wrong)

storeMessage

Only for testnet

attachToTangle

Run the pow. Safe to run on an non sync node. It make sense to dispatch those calls to the machine with highest computing power.

broadcastTransactions

Broadcast transactions to direct neighbors, can run safely on a desynchronised node

findTransactions

Search for transactions. Results will be more accurate on synced node

getBalances

Get balances on adresses. Results will be more accurate on sync node (this call is probably used by some wallet implementation as pre-check of the validity of the transaction)

getInclusionStates

Check if transactions are referenced by another set of transactions. (typical use case is to check if a particular transaction is validated by a milestone) It make more sense on a fully sync node.

getTips

Return the tips in a specific IRI instance Make sense on any node, mainly for monitoring IMO

An IRI instance keep an in memory cache of transactions that don't have any approvers yet (i.e. tips). This call returns the content of this cache. In other words, this call is just a way to be informed of the internal state of the IRI and I don't think it can be useful from a purely functional perspective. (i.e. picking tips from here to attach a transaction don't make sense because the consistency check is not done)

getTransactionsToApprove

This trigger the random walk, therefore it's very important to execute this on a fully-sync node.

getTrytes

Return transactions trytes. Results will be more accurate on sync node.

interruptAttachingToTangle

Shouldn't be remotely accessible (see Why is anyone with API access allowed to cancel the 'attachToTangle' operation of another user?)

storeTransactions

It simply store a batch of transactions in the local tangle (don't broadcast). I don't see a use case for this one. Can be useful for maintenance maybe ? IMO, this shouldn't be remotely accessible. This call is used by spammers. Don't requires a fully sync node.

It appears that spammers use it generaly in conjuction with broadcast transactions. In this case if you "storeTransactions" on node A, and just after that "broadcastTransaction" on node B : this won't broadcast anything.

It don't change the fact that those calls are stateless, it's just that the current usage by spammers make the fair assumption that 2 successive calls to store, then broadcast will be executed on the same instance (but nothing in the protocol offer that guarantee).

getMissingTransactions

Return the transactions known only by their hash. (details of the transaction aren't yet in the local tangle) Make sense on any node, mainly for monitoring.

When a node receive a transaction, this transaction contains the hash of the branch and trunk transactions. If one of them(or both) is(are) not in the local tangle, then the hash(es) is(are) added to a queue of "missing transactions". This call return that queue. The size of the queue is an interesting indicator to evaluate the "sync state" of the node.

checkConsistency

Check consistency of a set of transactions. It make more sense to run it on fully sync node.

wereAddressesSpentFrom

This call is use to prevent address re-use. Results will be more accurate on sync node (this call is used by some wallet implementations)

all others

Invocation of IXI module (probably better to run of fully sync node)

Improve this answer
7
  • @SaintHill because I don't see any use case for it.
    – ben75
    Jul 25, 2018 at 5:34
  • 1
    From my log files I saw that many spammers use storeTransactions in combination with broadcastTransactions. Does broadcastTransactions store the transactions, too? Does storeTransactions need to know referenced transactions?
    – mio
    Jul 25, 2018 at 6:28
  • storeTransactions don't need to know the trunk and branch. broadcastTransactions don't store them: it just check the validity (not the consistency) and send to neighbors.
    – ben75
    Jul 25, 2018 at 7:06
  • Thank you, that contains most of the information I needed. You helped me a lot. Just for reference: still not clear to me is (a) what getTips is for. I assume it makes sense to request this from a recent node otherwise the tips are old and maybe not tips anymore, (b) I assume that it makes sense to store transactions at the node the client is using currently so that they are available there, (c) no idea what getMissingTransactions is for.
    – mio
    Jul 25, 2018 at 10:00
  • @mio I edited my answer with some more details.
    – ben75
    Jul 25, 2018 at 11:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.