user132147: What is the frequency of the addr messages in bitcoin?
And are the contents of the addr messages from the new or the tried table or both?

user47827: From the Bitcoin wiki:

The getaddr message sends a request to a node asking for information about known active peers to help with finding potential nodes in the network. The response to receiving this message is to transmit one or more addr messages with one or more peers from a database of known active peers. The typical presumption is that a node is likely to be active if it has been sending a message within the last three hours.

In the Bitcoin Core implementation AddrMan (Address Manager, .cpp file) manages a node's known addresses. As the correction below in the comments says the response to a getaddr request will return both tried and untried (new) addresses.

user13866: 
What is the frequency of the addr messages in bitcoin?

I believe they are sent in response to a getaddr message. So the frequency at which your node receives addr messages depends on the frequency your node issues getaddr messages.

are the contents of the addr messages from the new or the tried table or both?

The network protocol specification doesn't specify the source in that way. It says
getaddr

The getaddr message sends a request to a node asking for information about known active peers to help with finding potential nodes in the network. The response to receiving this message is to transmit one or more addr messages with one or more peers from a database of known active peers. The typical presumption is that a node is likely to be active if it has been sending a message within the last three hours.

addr:

Provide information on known nodes of the network. Non-advertised nodes should be forgotten after typically 3 hours

To me this suggests each implementer chooses exactly how to source, categorise, store and maintain the data it uses in the response. If in doubt the implementer presumably consults the source code of whatever implementation they regard as the reference implementation.
I guess it would be prudent not to make any assumptions about the sending node's selection of entries in it's addr response. The sending node may be hostile or faulty.

132147: <p>What is the frequency of the addr messages in bitcoin?
And are the contents of the addr messages from the new or the tried table or both?</p>
 47827: <p>From the <a href="https://en.bitcoin.it/wiki/Protocol_documentation#getaddr" rel="nofollow noreferrer">Bitcoin wiki</a>:</p>
<blockquote>
<p>The <code>getaddr</code> message sends a request to a node asking for information about known active peers to help with finding potential nodes in the network. The response to receiving this message is to transmit one or more addr messages with one or more peers from a database of known active peers. The typical presumption is that a node is likely to be active if it has been sending a message within the last three hours.</p>
</blockquote>
<p>In the Bitcoin Core implementation <code>AddrMan</code> (Address Manager, <a href="https://github.com/bitcoin/bitcoin/blob/master/src/addrman.cpp" rel="nofollow noreferrer">.cpp file</a>) manages a node's known addresses. As the correction below in the comments says the response to a <code>getaddr</code> request will return <strong>both</strong> tried and untried (new) addresses.</p>
 13866: <blockquote>
<p>What is the frequency of the addr messages in bitcoin?</p>
</blockquote>
<p>I believe they are sent in response to a <code>getaddr</code> message. So the frequency at which your node receives <code>addr</code> messages depends on the frequency your node issues <code>getaddr</code> messages.</p>
<blockquote>
<p>are the contents of the addr messages from the new or the tried table or both?</p>
</blockquote>
<p>The network protocol specification doesn't specify the source in that way. It says</p>
<p><strong><a href="https://en.bitcoin.it/wiki/Protocol_documentation#getaddr" rel="nofollow noreferrer">getaddr</a></strong></p>
<blockquote>
<p>The getaddr message sends a request to a node asking for information about known active peers to help with finding potential nodes in the network. The response to receiving this message is to transmit one or more addr messages with one or more peers from a database of known active peers. The typical presumption is that a node is likely to be active if it has been sending a message within the last three hours.</p>
</blockquote>
<p><strong><a href="https://en.bitcoin.it/wiki/Protocol_documentation#addr" rel="nofollow noreferrer">addr</a></strong>:</p>
<blockquote>
<p>Provide information on known nodes of the network. Non-advertised nodes should be forgotten after typically 3 hours</p>
</blockquote>
<p>To me this suggests each implementer chooses exactly how to source, categorise, store and maintain the data it uses in the response. If in doubt the implementer presumably consults the source code of whatever implementation they regard as the reference implementation.</p>
<p>I guess it would be prudent not to make any assumptions about the sending node's selection of entries in it's <code>addr</code> response. The sending node may be hostile or faulty.</p>
