2011/3/31 Dena Dragos <[email protected]>: > 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?
You instruct them, manually. I don't see this as a bad thing, btw. > 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. > 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. > 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?). My previous suggestion remain, an routing algorithm/protocol -- I really don't recommend doing this at this point. There might be an easier solution, but if it is not going to work then I don't see why use it. > 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. > 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. > Yep, that seems cleaner to do. > So, what would be the better method here? Or we shouldn't keep track > of notifications when Umit Network Scanner is closed? > For the moment I like the second method way more. > 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")? > 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 > 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. > You have addressed several details that are important for this project. My advice is to point these details in your final project; you don't need to say exactly how you are going to address each one because there are many of them very problematic. But it is good to have an initial idea on how you would deal with them. I hope this quick and short reply messages help you in any way. Good luck, > Best regards, > Dragos Dena > -- -- Guilherme H. Polo Goncalves ------------------------------------------------------------------------------ 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
