By using `tcp_loop.dispatch` to schedule the initial search for a
channel, we are placing the callback into the same work queue that is
used by e.g. `MonitorBuilder::exec` to schedule the call to
`Channel::build`. In situations where lots of channels are being
created simultaneously this can result in lots of single channel search
requests being sent because the work queue alternates between calls to
build a channel and the initial search.
In this commit we instead use a dedicated `evevent` to schedule the
initial search to allow the `initialSearchBucket` to be filled before we
send the initial search request. We delay the initial search by 10 ms to
give more time for the bucket to be filled. See
github.com/mdavidsaver/pvxs/pull/39 for a discussion of how this delay
was chosen.
When creating a large number of Channels at once, we can end up calling
`ContextImpl::poke(true)` many times in quick succession. This results
in a flood of UDP broadcasts where we are searching for channels that we
only just sent out the initial search request for.
This can easily lead to packets getting lost and us not receiving a
reply for some Channels. Moreover, as we keep resending search requests
for Channels, we reschedule them further and further in the future (as
`nSearch` is increased). After the dust settles and we stop poking,
this can result in a wait of several seconds before a Channel which we
have not found is searched for again.
In this commit we avoid this issue by using a separate bucket to hold
channels waiting for their initial search request. Rather than poking
`tickSearch` to do the initial search and also resend requests for
outstanding channels, we schedule a call to new call `tickSearch` which
will only send the initial search requests. As such, we will avoid
rebroadcasting search requests for channels we have only just searched
for.
We have prompted the `discover` bool to an enum to distinguish between
the now three different situations `tickSearch` can be called in.
Use recvmsg() and control messages IP_PKTINFO (Linux, OSX, Windows)
or IP_ORIGDSTADDR and IP_RECVIF (RTEMS w/ libbsd) to find the
index of the logical interface through which a UDP packet was received,
and the destination address from the IPv4 header.
Also, clear IP_MULTICAST_ALL on Linux to disable non-compliant legacy brokenness
and receive only those multicasts we are interested in.
Bypass the broadcast search phase and directly connect
to a specific server and issue CMD_CREATE_CHANNEL.
Note, due to pvAccessCPP buggyness, this can only be relied
upon to connect with the unadvertised magic 'server' PV.
On Linux, use SO_RXQ_OVFL to snoop on the OS dropped packet
counter for our socket buffer. Does not detect drops on
ingress, or internal to, to OS IP stack.
Michael Davidsaver