Discussion:
Design struggle
(too old to reply)
B.R.
2014-08-29 15:53:50 UTC
Permalink
Raw Message
I am trying to implement a modular filter plug-in system on top of libevent.

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
file descriptor
4°) Each filter is then able to read information from the socket and
possibly stack information to write that socket, registering a WRITE event
on it

My concern here are concurrency (not really race condition since the app is
single-threaded) :
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
on it?

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
the answer

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.
---
*B. R.*
Azat Khuzhin
2014-09-04 13:04:10 UTC
Permalink
Raw Message
Anyhow, that does not change the fact that I need a single handler for the
network reading, and then dispatch the messages to handler, filling their
individual buffer and manually activating their event to trigger them, does
it?
As far as I understand you - yes.

Cheers,
Azat.
---
*B. R.*

***********************************************************************
To unsubscribe, send an e-mail to ***@freehaven.net with
unsubscribe libevent-users in the body.

Loading...