Transaction Relay and trickling in Bitcoin If a node has 100 connections to other nodes and receives a new transaction using a getData request, it sends an inv message to it's 100 connecting peers correct?

Does it also send the inv message to the peer that it just received the transaction from as it is still one of it's connecting peers? 

'Messages, in general, are flushed periodically about every
100 ms. However, transaction relaying takes place by “trickling” messages out. Bitcoin randomly selects with a probability
of 1/4 the transactions for an inv message and stalls the remaining transactions. Every neighbor gets a different set of randomly
chosen transactions, each about 1/4 of the currently available
set. Only the randomly selected “trickling node” (cf. addr
message relaying) gets all transactions immediately. The other
neighbors either get it later or already got it from another neighbor. Trickling reduces the overhead and at the same time makes
traffic analysis more difficult, in a similar manner as mixes do
in mix networks.'

I'm having a bit of difficulty understanding how trickling works in terms of transactions. I believed that the process was when a transaction occurs, the node responsible for the transaction would send INV messages to its peers and send the tx if the peers respond with getData.
If a node has 100 connections to other nodes and receives a new transaction using a getData request, it sends an inv message to it's 100 connecting peers correct?


No. It depends on what nodes have sent an inv stating that they have that transaction. When an inv is received, the node will remember what has been inv'd to them by that node so that it does not attempt to send it something it already has. At most, there will be 99 inv messages sent. Since we already know that the peer that sent us the transaction already has it, we don't send them an inv. At minimum, there will be no inv messages sent because all nodes could have already sent us an inv for the same transaction.


  Does it also send the inv message to the peer that it just received the transaction from as it is still one of it's connecting peers? 


As stated above, it does not. While there is no rule the explicitly prevents this, it is sensible to not send an inv to someone who has already sent an inv to you for the same thing. This saves bandwidth costs.


  I'm having a bit of difficulty understanding how trickling works in terms of transactions.


For each peer, the node keeps a list of transactions that it is going to inv to it. It sends inv's for transactions periodically with a random delay between each inv. Transactions are selected to go into the inv message somewhat randomly and according to some metrics involving fee rate. It selects a limited number of transactions to inv.


  I believed that the process was when a transaction occurs, the node responsible for the transaction would send INV messages to its peers and send the tx if the peers respond with getData.


The node the creates a transaction treats that transaction like any other it received over the network. For every peer that node is connected to, it adds that transaction to the list of transactions that it will send to that node eventually. Then everything else is as usual. At the next time it is to send an inv message for a particular peer, it chooses transactions to inv, and the transaction it created may or may not be one of those. Once the inv is sent, the other node will respond with a getdata for the things it wants, which may or may not include the transaction it created. Then your node responds to the getdata with the transactions themselves.