|
| 1 | +// Package messagequeue implements a queue of want messages to send to peers. |
| 2 | +// |
| 3 | +// There is a MessageQueue for each peer. The MessageQueue does not enqueue |
| 4 | +// individual outgoing messages, but accumulates information to put into the |
| 5 | +// next message. Each MessageQueue keeps want lists and CIDs to cancel: |
| 6 | +// |
| 7 | +// - sent/pending peer wants + sent times |
| 8 | +// - sent/pending broadcast wants + sent times |
| 9 | +// - cancel CIDs |
| 10 | +// |
| 11 | +// As messages are added, existing wantlist items may be changed or removed. |
| 12 | +// For example, adding a cancel to the queue for some CIDs also removes any |
| 13 | +// pending wants for those same CIDs. Adding a want will remove a cancel for |
| 14 | +// that CID. If a want already exists then only the type and priority may be |
| 15 | +// adjusted for that same want, so that duplicate messages are not sent. |
| 16 | +// |
| 17 | +// When enough message updates have accumulated or it has been long enough |
| 18 | +// since the previous message was sent, then send the current message. The |
| 19 | +// message contains wants and cancels up to a limited size, and is sent to the |
| 20 | +// peer. The time that the message was sent is recorded. |
| 21 | +// |
| 22 | +// If a want has been sent with no response received, for longer than the |
| 23 | +// rebroadcast interval, then the want is moved back to the pending list to be |
| 24 | +// resent to the peer. |
| 25 | +// |
| 26 | +// When a response is received, the earliest request time is used to calculate |
| 27 | +// the longest latency for updating the message timeout time. The sent times |
| 28 | +// are cleared for CIDs in the response. |
| 29 | +package messagequeue |
0 commit comments