Hi Elisa, Thanks for the offer!
My thoughts/ideas have not yet progressed much further than "it'd be nice to have a perl interface/module with a feature set equivalent to the pmacct tool". Ideally there'd be multiple possible output formats, arrays, hashes, etc. The rest of this mail is basically just some thoughts that flew by while writing this email. I'm not sure much hardcore pmacct (the client that is, not the total package) users there'd be, and how much of them would be interested in the perl interface. (Judging from the amount of comments in this thread I'd say the number is quite low.) My personal "requirements" are actually a tiny subset of the pmacct client. All I care about is getting the data from the imt into a perl "struct" (be it an array, hash of arrays, array of hashes, hash, etc). And in my case the only data in the imt is a list of ip+packet+byte records. The tricky part (well, one of 'em at least) is to decide on the level functionality and thus complexity. You don't it to be too simple, as it wouldn't be of any use for the more complex scenarios, but too complex isn't that good for the more simple scenarios either. One solution could a "multi-layer" implementation. At the bottom would be a very raw interface to pmacctd. On top of that layer one could build additional layers with more friendly and/or specific interfaces for a given task. Did you have any (specific) ideas yourself already? Regards, Ruben Laban On Monday 28 February 2011 at 19:27 (CET), Elisa Jasinska wrote: > Hi Ruben and Paolo, > > being a perl fan and having written the perl module for sFlow > (Net::sFlow), I would be happy to contribute to this effort! > > Feel free to send you ideas and plans my way Ruben. Even if only by > having you write down and structure your thoughts, maybe I'll be able to > help ;) > > Cheers > Elisa > > On 2/28/11 9:10 , Ruben Laban wrote: > > Hi Paolo, > > > > Sounds good! Except for the absent part ;-) > > > > I must admit I failed to read the source of pmacct to see how "obvious" > > the protocol might be. I kinda hope most of the intelligence to be in > > pmacctd and not pmacct. > > > > Assuming the protocol isn't too complex, I do intend to proceed with > > this, at least the investigating part of it. My perl-foo is fairly > > limited (I learned it through editing existing scripts and later on > > writing simple ones myself), though if I end up writing a perl interface > > for pmacct, I'll do my best to deliver code worthy of at least > > "contribs" inclusion. > > > > So, if you could outline the basics of the protocol, that'd be a great > > start. In the meantime I'll have a look at the source and see what I can > > get from there. > > > > Regards, > > Ruben Laban > > > > On Sunday 27 February 2011 at 18:42 (CET), Paolo Lucente wrote: > >> Hi Ruben, > >> > >> The protocol between pmacct and pmacctd is fairly stable, didn't evolve > >> much over the last year or so. But, of course, stability is also greatly > >> related to the purpose: as that didn't evolve consequently the protocol > >> remained still. This is to say i'm open to review it with anybody might > >> be interested into it. > >> > >> Documentation is absent in this regard - but i can (and willing to) put > >> something together if it can be of use. Let me conclude that you propose > >> a valid idea: should you want to progress it, i will fully support. > >> > >> Cheers, > >> Paolo > >> > >> On Thu, Feb 24, 2011 at 10:04:53AM +0100, Ruben Laban wrote: > >>> Hi Paolo, > >>> > >>> Digging up an ancient thread as the topic became "interesting" again as > >>> I'm improving/refactoring my current setups. > >>> > >>> One of the ideas I had was for perl to directly "talk" to pmacct using > >>> the sockets (talking memory plugins only here). Is the protocol/ABI/API > >>> that's used between pmacct and pmacctd stable? And perhaps documented > >>> somewhere already? If this were the case, writing "3rd party" > >>> interfaces to pmacct(d) could be fairly trivial. > >>> > >>> Regards, > >>> Ruben Laban > >>> > >>> On Thursday 02 August 2007 at 13:01 (CET), Ruben Laban wrote: > >>>> Hi Paolo, > >>>> > >>>> I understand the time-related problem, I face it myself way more often > >>>> than I'd hope for :-) > >>>> > >>>> I haven't looked very closely at the pmacct source code, but a nice > >>>> first step would be to modularize the functionality of pmacct. I have > >>>> no idea if the current codebase is suited for something like that. If > >>>> pmacct were to become a mere frontend to a pmacct library, it would > >>>> pave the road for other frontend implementations. If I have some spare > >>>> time I will take look at the code myself as well. > >>>> > >>>> For now the interfacing with the pmacct does the job pretty nicely. > >>>> Except that errorhandling is a bit nasty, though that's also caused by > >>>> my far from extensive perl knowledge. > >>>> > >>>> Thanks for your input thus far. > >>>> > >>>> Kind regards, > >>>> Ruben Laban > >>>> > >>>> On Thursday 02 August 2007, Paolo Lucente wrote: > >>>>> Hi Ruben, > >>>>> > >>>>> Personally, i don't have plans to go in that way. But let me clarify > >>>>> that's only because of my current time constraints; i recognize it > >>>>> would be a great addition to the current status, so i would be > >>>>> absolutely open and supportive to anybody that would like to get the > >>>>> token. > >>>>> > >>>>> A valid and effective starting point, as you were suggesting, could > >>>>> be to develop a module that allows to interact with the memory > >>>>> tables without the need to invoke the pmacct binary. > >>>>> > >>>>> Cheers, > >>>>> Paolo > >>>>> > >>>>> On Thu, Aug 02, 2007 at 08:39:30AM +0200, Ruben Laban wrote: > >>>>>> Hello list, > >>>>>> > >>>>>> I was wondering if there were any plans or if anyone had given it a > >>>>>> try to implement a perl interface to pmacct. Right now I'm calling > >>>>>> the pmacct binary from within my perl scripts. A much nicer way > >>>>>> would be to have a perl module to do the interaction with pmacctd. > >>>>>> > >>>>>> Kind regards, > >>>>>> -- > >>>>>> Ruben Laban > >>>>>> Systems and Network Administrator > >>>>>> [email protected] > >>>>>> > >>>>>> ISM eCompany > >>>>>> Van Nelleweg 1 > >>>>>> Postbus 13043 > >>>>>> 3004 HA Rotterdam > >>>>>> +31 (0)10 243 6000 (tel) > >>>>>> +31 (0)10 243 6066 (fax) > >>>>>> www.ism.nl > >>>>>> > >>>>>> Quality Solutions - Reliable Partner > >>>>> > >>>>> _______________________________________________ > >>>>> pmacct-discussion mailing list > >>>>> http://www.pmacct.net/#mailinglists > >>>> > >>>> _______________________________________________ > >>>> pmacct-discussion mailing list > >>>> http://www.pmacct.net/#mailinglists > >>> > >>> _______________________________________________ > >>> pmacct-discussion mailing list > >>> http://www.pmacct.net/#mailinglists > >> > >> _______________________________________________ > >> pmacct-discussion mailing list > >> http://www.pmacct.net/#mailinglists > > > > _______________________________________________ > > pmacct-discussion mailing list > > http://www.pmacct.net/#mailinglists > > _______________________________________________ > pmacct-discussion mailing list > http://www.pmacct.net/#mailinglists _______________________________________________ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists
