Hello! On Fri, Apr 1, 2011 at 4:25 AM, Guilherme Polo <[email protected]> wrote: > The avoidance of any manual configuration is hard to do properly. I'm > considering this general term "the network" to be as big as Internet.
Actually it was my fault here. In my language the equivalent of "network" is used to name a broadcast domain and I don't know why I had the feeling it's the same in English :). Was mainly thinking of rooms (like laboratories at my Faculty) where you have something like 30 hosts connected to a switch rack, then you wouldn't want to configure one daemon to know about all the others. If it's separated by a router, indeed it gets more complicated. My only idea here was manual configuration actually (in that settings file). >> At the same time, the user can add remote agents trough >> the configuration file. But at this point, you can access from the >> local agent (or even an agent on another host) all the discovered >> agents on the Umit Network Scanner. Now the Umit main process can >> "subscribe" to those daemons and get information from them. >> >> The original reason in my view for which the daemons communicated was >> that I thought that after the Umit process is closed you wouldn't want >> to loose track of the notifications. You would want that after the >> Umit process is closed to still be receiving notification messages and >> show them when you start Umit again. For that you would need a daemon, >> and I thought of using the agent to "subscribe" to the other daemons >> and pass out the information to the Umit process when it will start >> again. >> > > It seems the daemons are storing information rather than exchanging > information between them, in your example. Actually, you are kind of correct. The Agent would store the information until Umit "wakes up" again in this case. The information should be stored anyway somewhere, but indeed it seems that this idea has a major flaw: it may duplicate a lot of data. >> Another security issue here is to avoid flooding with notifications. >> In both cases in which the notification messages are saved (on the >> local daemon or being split up in queues on all the other daemons) >> there should be mechanism to stop the memory used by these messages >> get too big. This problem can also happen if the Umit Network Scanner >> is not opened for something like a week while all the hosts are >> opened. I believe messages should have priority to help deciding which >> ones should be dropped in case it will be needed. Of course, in case >> of something like a DoS attack from a corrupt agent (let's say the >> connection security was bypassed) that won't help too much since it >> can set all notifications to high priority. If an agent is flooding >> with messages maybe it should be removed from the list and a >> notification should be generated for this (something like: "potential >> untrusted agent")? >> > > Indeed, this is one of the details (a good one, btw). There is at > least another detail: you might not want to remove the data from an > agent right after a umit client gets the previously queued messages > because there could be another umit client that wants to see this data > too. There could be infinite :) clients wanting this same data, maybe > you should never erase data. This seems like IMAP :P Almost like IMAP :). Actually the notifications would be sent only to "Umit Agent Information Receiver"'s that subscribed to the agent. So messages will have associated a counter: if it drops to zero, it will get deleted (the counter will consider the timestamps when the "Umit Agent Information Receiver" subscribed/unsubscribed). Something similar to hard-links on Linux. I think it would get a bit too complicated if the Umit main process can request information which was produced before it subscribed. Best regards and thanks again, Dragos Dena ------------------------------------------------------------------------------ Create and publish websites with WebMatrix Use the most popular FREE web apps or write code yourself; WebMatrix provides all the features you need to develop and publish your website. http://p.sf.net/sfu/ms-webmatrix-sf _______________________________________________ Umit-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/umit-devel
