Documentation
¶
Overview ¶
Package netlinker is the netlinker go routine of the xtcp package
Netlinker recieves netlink messages from the kernel and passes the discrete messages to the inetdiagers workers
Index ¶
Constants ¶
This section is empty.
Variables ¶
This section is empty.
Functions ¶
func CheckNetlinkMessageType ¶
func CheckNetlinkMessageType(id int, af *uint8, Type uint16) (netlinkMsgComplete bool, netlinkMsgDone bool, errorCount int)
CheckNetlinkMessageType checks for netlink message types NLMSG_NOOP, NLMSG_DONE, NLMSG_ERROR, NLMSG_OVERRUN
func Netlinker ¶
func Netlinker(id int, af *uint8, socketFileDescriptor int, out chan<- TimeSpecandInetDiagMessage, netlinkerRecievedDoneCh chan<- time.Time, wg *sync.WaitGroup, startTime time.Time, cliFlags cliflags.CliFlags, netlinkerStaterCh chan<- netlinkerstater.NetlinkerStatsWrapper)
Netlinker makes the syscall to read from the netlink socket Then we break the netlink messages up into their Inetdiag messages, and stream to the downstream workers over the channel.
TODO - Currently we're doing a single x1 inetdiag message on the channel at a time. profile.TraceProfile does show gaps between messages, so we should test batching. (Probably should add a slice capability with a configurable max length)
For the purposes to checking to see if it's better to close the pipeline workers down between netlink inet_diag dump requests, or not, I've added logic here to allow this worker to close or not We're basically trying to understand if respawning goroutines for this work is better/worse and holding them open the whole time. Obviously this is really going to depend on lots of factors, like polling frequency, etc.
The thing about the syscall.Recvfrom is that we can't do a "select" on this with a channel at the same time. Therefore, to avoid any race conditions, the syscall.Recvfrom has timeout, so the operating system will return every <netlinkSocketTimeout> seconds, which will allow us to close down this worker if configured to do so.
Specificlally, to allow the netlinker to be shutdown, or held open, I recently added the "for socketTimeoutCount" loop, so if shutdownWorkers is false, we'll just keep re-issuing the syscall.Recvfrom and blocking until the timeout.
Recommend not setting the timeout too low, or your just going to thrash with system calls. Similarly, probably don't run too many netlinker, workers. With x4 workers and 5 second timeout seems reasonable.
Types ¶
type TimeSpecandInetDiagMessage ¶
type TimeSpecandInetDiagMessage struct {
TimeSpec syscall.Timespec //https://golang.org/pkg/syscall/#Timespec
InetDiagMessage []byte
}
TimeSpecandInetDiagMessage struct is the message that is sent from the recvfrom to the NetLink Message workers This includes the timeSpec which is the time the netlink dump request was sent (or really just before that)
Source Files