[collectd] collectd behind NAT

[Florian Forster]

Hi,

On Fri, Oct 20, 2006 at 04:03:25PM -0400, Guillaume Pratte wrote:
> I am willing to work on the transmission of the hostname in the UDP
> packets in collectd, if you are willing to review my vserver patch for
> inclusion in collectd :-)

First off, I have delegated this decision to Sebasian, since he wrote
the original plugin and is using VServer himself. The last thing I've
heard was, that he thinks that the desired information can be found in
an easier way somehow..

As for the hostname submission: My idea is to use a protocol that's
similar to IPv6's extension headers. I.e., you have a sequence of
generic headers which are parsed and put into a structure, which is then
returned by the networking code. The header could look something like
this:
  struct collectd_basic_header_s
  {
    uint16_t type;
    uint16_t length;
  };

A more specialized header could look like this:
  struct collectd_data_header_s
  {
    uint16_t type = CT_DATA;
    uint16_t length;
    uint8_t  host_len;
    uint8_t  type_len;
    uint8_t  inst_len;
    uint8_t  value_len;
    char     host[host_len];
    char     type[type_len];
    char     inst[inst_len];
    char     value[value_len];
  };
  assert (length == (host_len + type_len + inst_len + value_len));

So right now, we'd just send one `struct collectd_data_header_s' in each
packet and that's it. But in the future I want to be able to
- send multiple values in one packet
- include some kind of integrity check/signature
- send encrypted messages

What do you think? Does this protocol sound reasonable, or has it some
flaws? Would it be better to assign numeric values to `type' and `inst'?
Should we rather send an `struct ip6_addr' than a string? What about the
values? Some clever idea how to distinguish between (unsigned) int,
doubles and whatnot? Or should plugins take care of that? Any feedback
is appreciated.

Regards,
-octo
-- 
Florian octo Forster
Hacker in training
GnuPG: 0x91523C3D
http://verplant.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://mailman.verplant.org/pipermail/collectd/attachments/20061022/ac5dbf5e/attachment.pgp