Hello, On Fri, Apr 1, 2011 at 12:24 AM, Guilherme Polo <[email protected]> wrote: > 2011/3/31 Dena Dragos <[email protected]>: >> >> Any suggestions on how the >> discovery of the agents in the network should work? It's pretty >> unclear for me with my current networking knowledge, but if the agent >> is supposed to listen on port X and that specific port is used by >> another TCP connection before the agent starts what would be the >> back-up plan? Or it could work by just sending messages to all the >> open ports on a host to see if there is an agent listening on those >> ports. >> > > Ok, that actually seems two distinct questions to me but it raises a > point I didn't consider in your proposal. > Why are you going to exchange data between agents instead of directly > sending to "Umit Agent Information Receiver" ? I'm afraid this > decision is going to complicate things a lot here, the first thing > that comes to my mind is some form of a routing protocol to solve it > properly. The easier way is to not do this kind of discovery, let the > agents add themselves to an agent's list. To do this safely, you could > use a public-private key schema -- ssh. The second question is easily > solved because you can trust a known agent to update its situation > (port and host).
Actually the second question was about the discovery process also. Was thinking of scanning the open ports to see if there is an agent running on them. I didn't quite understand how the agents can add themselves to an agent's list. Won't that require some discovery anyway? The main idea is to avoid manual configuration of agents in the network (like adding on one host where you have Umit Network Scanner installed all the hosts with agents). At the same time, all the agents (though configured differently) are considered equal in my view. But how about this? The agent's in the network discover themselves (or any dynamic way to find all the agents in the network, any suggestions?). 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. Another solution for not loosing those messages if we choose the version when the "Umit Agent Information Receiver" receives data directly from agents which it subscribed is to keep some sort of message queue in each of those agents (the messages would require of course a timestamp) and send them to the Umit main process when it starts up again. So, what would be the better method here? Or we shouldn't keep track of notifications when Umit Network Scanner is closed? Yes, if the connection is already established then the agent can notify the other agents about it's change of status (mainly of port). And about the connection, I think I forgot to mention this, but it should be secured of course. Was thinking more towards a password system, but a public-private key seems fine to me. 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")? Anyway, in a normal functioning environment the messages should be logged somehow and let the user decide what to do with the logs. Maybe it would be a good idea to inform the user when the logs are getting too big. Thanks for your feedback! Helped me see a few things clearer. Best regards, 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
