Hi Karl, Sorry for getting back to you so late, but at the moment i'm quite busy (also on the pmacct side of the things: wrapping up a "stable" 0.11.6 release and in parallel working to a couple of ideas which can give light to the 0.12 branch). Let me summarize a little bit:
* the ssh/rsh method is there, it just works but is inefficient; * the socat approach is fine with me if it works: i can't advice because i don't know the socat package - and have no time to look into it currently. As said, we can make the external dependancy optional and configurable at compile time; if you produce some code that works at least for you, we might seek at improving it at a later stage for inclusion in mainstream. Or the patch can be made available through the CVS separatedly if it's not generic enough. * the socket approach would be, IHMO, the best but requires more work. This might be done in alternative or in addition to listening on a UNIX socket. The way in which it should be coded is similar; as operations in the IMT plugin are very quick (and to avoid concurrency overhead) i would advice something that serves only one client per time; it currently works this way for the UNIX socket. The reward is that once the connection is served, the existing code on both the client and the server can be fully re-used. Optionally, multi-threading can be introduced: a small but useful thread pool management library is already existing inside the pmacct package and is written by Francois Deppierraz. One more thing: what about authentication? With an UNIX socket this is easily solved by the underlying filesystem. Anything network-based, should require you to take care about it (once again, can't speak for how it's going to work for the socat approach). Cheers, Paolo On Sat, Feb 28, 2009 at 07:49:50AM -0600, 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? > > Bah. All the time I'm spending messing around in shell makes > me think I'd be better off extending pmacct. I guess my reluctance > is that if you don't like it all the work would be wasted. > We would really have to agree on an approach. Naturally you > could still reject whatever code I write if you think > it's broken or ugly. > > What do you think of the ideas so far? (I do need > to get something working quickly.) > > 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
