2014-08-29 15:53:50 UTC
The main concept principles are:
1Â°) Filters are created cointaining information of connections they should
be bound to (protocol, port), events that should trigger them and a
callback pointer to link with the event
2Â°) Based on those filters, the necessary sockets are created and each
socket is linked to a list of filters matching them
3Â°) For each filter, an event is created liking the callback to the socket
4Â°) Each filter is then able to read information from the socket and
possibly stack information to write that socket, registering a WRITE event
My concern here are concurrency (not really race condition since the app is
I) If multiple filters ask to be triggered on READ event on the same
socket, what will they see? Will they all be able to read the same message
which triggered the event and not another one (ie another message received
while processing the filter list)?
II) If multiple filters wanna write data to the socket, is it safe to have
each filter having its separate buffer and triggering its own WRITE event
Here is a use case summing up both previous inquiries:
Say a filter wrote data to a socket after parsing the content it read on
it, and that the peer reacted to that answer, what will subsequent filters,
for which the READ event has been triggered by the initial message, read?
a) Initial message?
b) Either initial message or answer (race, undecided)?
c) Nothing since the event has been canceled (not pending anymore), the
subsequent filters will only receive a new event for READ on reception of
I am thinking of using a dispatcher which would sequentially (and manually)
trigger the event of each of the filters. However that implies not linking
the filters event with the socket, thus forcing me to maintain a separate
buffer for each of the filter (with memory and processing overhead that
implies). Moreover, the problem reappears if another message is received on
the socket while the dispatching loop is at work... and the sequential work
makes the benefit of the event-based system disappear!
I do not know if the bufferevents would be useful to my case. Anyway, those
are not an option, since part of the traffic I am handling is UDP datagrams.
I am new to the library. Please enlighten me if I have missed some key
points in its design/handling.