I'm still trying to figure out what you're trying to improve here? XDR seems like a fine, standard, lightweight serialization protocol to use. It is already implemented and we've already got some protocol handling for backwards compat for really old ganglia monitor clients. What is there to gain from switching aside from having some new and shiny that needs to be supported in addition to the existing stuff? We aren't serializing any custom data types or references or anything aside from some floats, ints, and a couple of strings. XDR compute overhead is not hurting performance, especially on modern hardware, the payloads aren't very big and the tuning of various check timings and metric validity timings further reduces the amount of chatter on the wire.
If you want to introduce some more modern code to ganglia I think adding support for pushing gmond communications into a modern pub/sub message queue framework. I've never heard anybody have problems with our serialization, but there is frequent and often confusing troubleshooting around multicast vs unicast and the various infrastructural/configuration tweaks to make the most out of those. Further improvements could probably be had in the arena of node multi-tenancy and/or arbitrary node grouping/clustering. Maybe I'm missing something that you've said or implied already, but this just seems like change for the sake of change. -Dave On 07/28/2013 02:09 PM, Nikhil wrote: > > Hi, > > Thanks for response. > > I see there is no averseness to the idea of considering different > serialization format/protocol. > > Before we have any contribution in terms of code/specifications, what > would be the ideal choice among these : > http://en.wikipedia.org/wiki/Comparison_of_data_serialization_formats for > choosing > the serialization format over the current XDR implementation in ganglia? > > As in like what is the current payload by XDR and what we should not > intend to cross over, the performance overhead in processing and > storing, the availability of libraries and ease of use being some of > them that comes to thought of discussion. > > As Dave also mentions platform agnostic, portability (endianness?) and > efficiency are also of the critical things to be considered. While ASN.1 > does offer all of this, some of the others that I wanted to consider are > : MessagePack and UBJson. Formats specs are described here for > MessagePack > http://wiki.msgpack.org/display/MSGPACK/Format+specification and for > UBJson http://ubjson.org <http://ubjson.org/> > > Let me know what do you all think would be the ideal choice. > > Thanks. > > > > On Sat, Jul 27, 2013 at 6:13 AM, Vladimir Vuksan <vli...@veus.hr > <mailto:vli...@veus.hr>> wrote: > > I am not necessarily opposed to it if it's implemented in such a way not > to break backwards compatibility. Someone would need to contribute some > code. > > Vladimir > > On Fri, 26 Jul 2013, Dave Rawks wrote: > > > I'm curious to hear what you think is going to be more efficient, > > platform agnostic and portable than XDR? ASN1 would be the only > thing I > > would even consider using instead, but it is arguable whether it > would > > be worth the pain of supporting more than one serialization > format and > > it certainly doesn't seem sane to break all backwards > compatibility to > > switch to something new unilaterally. ASN1 /might/ be a reasonable > > alternative to XDR, but I don't see what advantages this could > possibly > > bring. > > > > -Dave > > > > On 7/26/13 10:46 AM, Nikhil wrote: > >> Hi, > >> > >> Considering that we have better and compute efficient and binary > >> serialization open formats out there . How hard would it to make > Ganglia > >> use them instead of XDR ? > >> Can the serialization format engines be pluggable, instead of being > >> closely integrated with XDR? Is it still worth continuing to > stick with XDR? > >> > >> The intention is to understand and see the possibility and have a > >> discussion what could be best to go with, if its appropriate. > >> > >> I am really hoping to see the reply from the authors of ganglia > core :-) > >> > >> Thanks, > >> Nikhil > >> > >> ------------------------------------------------------------------------------ Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk _______________________________________________ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
