Sonic is a Go library for network and I/O programming that provides developers with a consistent asynchronous model, with a focus on achieving the lowest possible latency and jitter in Go.
MIT License
676
stars
16
forks
source link
Dynamically change a udp multicast peer's read buffer #99
Consider the following scenario: (showcased in the test)
exchange sends data on two multicast groups A and B
we have 2 udp peers, one for A and one for B which are scheduled to read data
these 2 udp peers must share the same read buffers. Initially they are both scheduled to read into b1.
If peer A reads something in b1, peer B must not overwrite what has been read by peer A. Instead, peer B must complete its read into whatever buffer peer A now reads into, say b2. That means peer A must change the buffer peer B reads into in its read callback. To summarize:
peer A and B schedule an async read into b1
peer A reads and processes what is in b1 (in its async callback)
peer B did not read yet. It must not read into b1
peer A schedules itself to read into b2 and also changes peer B to read into b2 through B.SetAsyncReadBuffer (in peer A's read callback)
by the end of peer A's read, both peer A and peer B will be scheduled to read into b2.
More concretely, for edxm historical feed b1, b2 etc are chunks obtained from a bip buffer.
Consider the following scenario: (showcased in the test)
b1.If peer A reads something in
b1, peer B must not overwrite what has been read by peer A. Instead, peer B must complete its read into whatever buffer peer A now reads into, sayb2. That means peer A must change the buffer peer B reads into in its read callback. To summarize:b1b1(in its async callback)b1b2and also changes peer B to read intob2throughB.SetAsyncReadBuffer(in peer A's read callback)b2.More concretely, for edxm historical feed
b1,b2etc are chunks obtained from a bip buffer.