Do nodes reject a spam of zero-value transactions from a single node if it's getting too much?

Question

What is considered "too much"?

How could one circumvent this?

Answer 1

I may miss something but when looking at IRI source code, I can't find specific code to reject transactions from a particular neighbour or wallet.

The question isn't clear regarding your use-case, so this answer explain what's going on in the IRI when data is received from a neighbour and from a light client (typically a wallet).

---

Here are the checks that are done when a transaction is received from a neighbour:

When a node receive some data the following checks are done :

• check if the received data is a syntactically valid transaction or just garbage.
• check if the transaction wasn't already received "recently" (i.e. there is a cache of "recently received transactions")
• check that the data comes from one of it's known neighbors
• check that the tx timestamp is in an acceptable range, check that the value isn't more that the total amount of existing iotas, check that POW was done, (for value tx: check that the address don't ends with a zero trit... I don't know why).

If all those checks conclude that it is an acceptable piece of data, then the transaction is inserted in an ordered queue of transactions to process (to process mainly means to store in the database and rebroadcast to neighbors). This queue is ordered according MWM of the transaction. If this queue is full : the last element of the queue is dropped.

---

Here are the checks that are done when some data is received from a wallet (or any client using the broadcastTransactions api):

• check if the received data is a syntactically valid (set of) transaction(s) or just garbage.
• check that the tx timestamp is in an acceptable range, check that the value isn't more that the total amount of existing iotas, check that POW was done, (for value tx: check that the address don't ends with a zero trit).

If all those checks conclude that it is an acceptable piece of data, then the transaction is inserted in an ordered queue of transactions to broadcast. This queue is ordered according MWM of the transaction. If this queue is full : the last element of the queue is dropped.

It's interesting to note that a transaction coming from a wallet is not immediately stored in the local database, but simply broadcasted to neighbors.