On Saturday, May 07, 2016 11:49:04 AM Matthew Toseland wrote:
> I am concerned that if we use Martin's approach directly we could end up
> with another layer of indirection for little purpose. That is, DMT
> Message's come in, and then we convert them to events on a 1:1 basis,
> and then... If so, it would be better just to subscribe to Message's in
> the first place! And furthermore the existing infrastructure *does do
> that*...
The problem that classes depend on the Node-class exists not only in the
context of message handling, but also in the HTTP-Interface etc. Maybe we can
find a more general solution to deal with Freenet's asynchrony. Some sources
and sinks of events are
1) User interfaces
- where user-triggered requests come from (e.g. disable opennet)
- that need to be updated whenever the current state of freenet changes
-> Maybe it would make sense to cache state in the UI-object, like the
set of opennet-neighbors and update it using an event-like mechanism instead
of directly accessing freenet's core components, locking them during the
process.
2) Network interfaces
- where messages from other nodes come from
- where messages to other nodes need to be sent
-> Here, an event-like mechanism is primarily relevant for reception of
packets, as multiple components might be interested in the arrival of messages
(e.g. one that replies to the message if necessary and another that keeps
network statistics)
-> If multiple interfaces shall be used for communication, it would
probably not make much sense if all interfaces receive a SendMessage-event,
therefore sending the same message on every interface. There probably should
be one dedicated component that coordinates sending of messages.
3) Internal events (e.g. Message timeouts, Node Shutdown/Restart due to
update)
- It probably depends on the particular event whether multiple parts of
the code are interested
> At the moment, most of that level of the node *does* subscribe to
> Message's via MessageFilter's. The MessageCore matches incoming messages
> to MessageFilter's. NodeDispatcher deals with what's left.
> Unfortunately, "what's left" is quite big!
Basically, I like the MessageFilters approach, as it allows protocols to be
programmed in a sequential way instead of having a series of
handleTheFirstMessage, handleTheSecondMessage etc.-methods that depend on one
another. Maybe we can work out some kind of more general EventFilter. Core
components such as the Opennet-Manager could then run in an infinite loop,
starting with a filter that catches any interesting event (which can result in
quite many EventFilter.create() and filter1.or(filter2)-calls :-/) and upon
reception starts a thread that handles this event, so that the main loop can
quickly return to waiting for the next event. Any of these threads then might
wait for follow-up events or generate events itself (e.g. to execute a
protocol, such as the swapping in LocationManager).
_______________________________________________
Devl mailing list
[email protected]
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
