[Bro-Dev] [JIRA] (BIT-1260) topic/jsiwek/improve_comm_loop

[Jon Siwek (JIRA)]

    [ https://bro-tracker.atlassian.net/browse/BIT-1260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18213#comment-18213 ] 

Jon Siwek commented on BIT-1260:
--------------------------------

{quote}
the pipe operations in the Flare methods worry me: shouldn't unexpected errors lead to abort, rather than potential endless loops?
{quote}

Sure adding extra safety precaution shouldn't hurt much, I'll do that -- in this case the unexpected errors would really, truly be unexpected, but I guess we'll see what we get :)

{quote}
I'm confused about the precise semantics ExtraReadFDs(): it says Read, but ChunkedIOFD also adds the write flare, but ChunkedIOSSL doesn't?
{quote}

The signaling mechanism of a flare is to make sure something can be *read* from its pipe for as long as one wants the signal to be active, so that's where ExtraReadFDs() came from -- e.g. "integrate these in to the read fd set of your select call to check if there's work (either input or output) to be done".

For ChunkedIOFD, it has two queues.  One that fills up with input that it "over-read", but failed to process in one go and another for output that's waiting to be written.  At the cost of using a couple extra file descriptors, it was easiest to just use two independent flares to track whether we still have read-work versus write-work to do.  Could probably be written to use a general "work flare", but maybe trickier to get that right.

For ChunkedIOSSL, it has the queue for output that's waiting to be written, but it never "over-reads" -- the read-readiness is always covered by the SSL wrapped file descriptor which extracts exactly one record at a time.  That's why it has just the extra write-flare while the original FD is sufficient to cover checking for input.

Let me know if that doesn't sound right.

{quote}
API suggestion: can we give ChunkedIO just a single method FDs() that combines Fd() and ExtraReadFDs()?
{quote}

Wasn't sure if it would ever be important for one to distinguish what the "real" FD (e.g. socket, etc.) is versus other internal ones for prioritization reasons.  Maybe overthinking, but also probably this API isn't going to be travelled often anyway so I can see either way being fine?

> topic/jsiwek/improve_comm_loop
> ------------------------------
>
>                 Key: BIT-1260
>                 URL: https://bro-tracker.atlassian.net/browse/BIT-1260
>             Project: Bro Issue Tracker
>          Issue Type: Improvement
>          Components: Bro
>            Reporter: Jon Siwek
>             Fix For: 2.4
>
>
> This branch removes timeouts from the remote communication loop and so reduces cpu usage during the times it's supposed to be idle.



--
This message was sent by Atlassian JIRA
(v6.4-OD-05-009#64003)