On 02/25/2009 10:10:05 PM, Karl O. Pinc wrote: > > On 02/25/2009 04:46:46 PM, Paolo Lucente wrote:
> > > > All this said, let me just shoot a proposal: as the in-memory table > > client/server communication is already based on request/reply > headers, > > operation codes, etc. (so let's say the protocol is there) what > about > > keeping it simple by encoding all of this in either UDP or TCP > packets > > with a bit of socket programming? > That's the alternative. The one bit of functionality > you get by coding sockets in pmacct(d) is that you can > use a single port on the server side and fork to allow > multiple data paths to the client side. On reflection, I think I can do this with socat/shell. I'm wondering if this means that the userland interface can remain unchanged and the internals re-implemented to switch from a socat/shell implementation to a C/socket solution. There seem to be 2 big hurdles. There are 2 daemons, each with a child for every exported socket, that do the work of schlepping the data across the network. One runs on the client box and one on the server box. The first problem is that on the server box using a C/socket approach that daemon would be pmacctd. If there's a separate daemon just to move stuff across the network then you may as well stick with the socat/shell solution. The socat/shell implementation could mimic the effect of havimg pmacctd doing the work if pmacctd did the work of spawning the socat/shell daemon. The second hurdle is the configuration file. The socat/shell solution is (mostly) getting it's arguments from the command line. To really make it look like pmacctd is doing the work there would have to be configuration file parameters that control all aspects of the network sockets. This could be annoying to parse in shell, but if the socat/shell daemon is invoked by pmacctd then pmacctd could do the parsing before invoking the socat/shell daemon. There would not be much in the way of "extra" code in pmacctd that would later need to be removed to go to a straight C/socket solution because pmacctd would have to parse the config anyway. I don't know how much I'm interested in doing the work needed to design the configuration directives and glue the socat/shell solution into pmacctd. Or rather I'm not sure how much time I'd have. But it's nice to know that a socat/shell solution could be integrated into pmacctd in a way that would allow it to be re-implemented in C without disrupting the end-user. I'm running a lot of architectural design out of my brain without feedback from the pmacct project. Please feel free to tell me to shut up and go away if you think this is all a distraction with respect to the direction that you want the pmacct project to take. I've put out a lot of detail and I don't want to mire you down in it unnecessarily. Regards, Karl <[email protected]> Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein _______________________________________________ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists
