On 24 Feb, 17:06, Dave S <[email protected]> wrote: > I want to clarify some confusion here. > > Use of TCP will only help to prevent the loss of a packet once it is > sent over the network. > It does not prevent any loss of data the agent hasn't sent. That's a > separate issue.
Not so true. > > UDP is used because the agent sends data at random times to the > server, and the cost of setting up a TCP link for each event becomes > too high. > Same reason syslog uses UDP. However, to gain that performance, we > lose the ability to confirm delivery of the packet (at least at the > network layer), so it would be possible that events could be lost in- > transit to the server. > > What Stefano is asking about, in my opinion, is what does the agent do > when it wants to send an event, but knows it cannot because the > server's offline? > In this case, the agent will not send a packet because it knows it > will not be received, so the UDP/TCP choice is irrelevant. So the > question is, how does the agent handle this situation? > Ok, but transport layer is important for assure delivery. Tcpdump shows me that ossec manager doesn't send a ACK packet and agent. In this configuration the agent can't fell the manager's fault and no retransmission will be performed. If we want to keep UDP layer and we want assure data delivery, the only way is to create a feedback system or an hearthbeat at sufficient small period. It's impossible to keep a single TCP session for all the time? Again trasport layer is important. > Daniel's explanation is a little unclear (Sorry dcid). I understand > the agent doesn't hold those events in memory, and I understand an > agent reboot would lose those events. But I'm unclear if the agent > actually catches up when the server comes back online. It's also > unclear with things such as Windows events, where the agent is not > looking at a file, but instead uses an API. Does it catch up with > these as well? Tricky question...
