<div dir="ltr">One option would be to use MQTT as the transport. It fits really well with metrics use case but I don't think the collectd-mqtt writer was ever finished.... <div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-06-11 22:24 GMT+02:00 Konstantin Tokarev <span dir="ltr"><<a href="mailto:annulen@yandex.ru" target="_blank">annulen@yandex.ru</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
11.06.2015, 21:56, "Florian Forster" <<a href="mailto:octo@collectd.org">octo@collectd.org</a>>:<br>
<span class="">> Hi Konstantin,<br>
><br>
> On Thu, Jun 11, 2015 at 03:08:04PM +0300, Konstantin Tokarev wrote:<br>
>>  Is it a design desition that network plugin supports UDP and<br>
>>  multicast, but not TCP?<br>
><br>
> yes, it allowed us to implement support for multicast, which is not<br>
> possible with TCP.<br>
<br>
</span>What's wrong with just sending the same packets over TCP connection?<br>
<span class=""><br>
><br>
>>  I think using TCP would be better option than UDP for transmitting<br>
>>  data over Internet. Otherwise, collectd would need to mitigate UDP<br>
>>  packet loss somehow.<br>
><br>
> You can work around this with the AMQP plugin, for example. I'd also<br>
> like to have a reliable-by-default option, but the idea I have in mind<br>
> is not quite there yet …<br>
<br>
</span>I'm planning to use collectd on embedded systems, and AMQP requires<br>
additional dependency. Also, it's not a binary protocol.<br>
<div class="HOEnZb"><div class="h5"><br>
--<br>
Regards,<br>
Konstantin<br>
<br>
_______________________________________________<br>
collectd mailing list<br>
<a href="mailto:collectd@verplant.org">collectd@verplant.org</a><br>
<a href="http://mailman.verplant.org/listinfo/collectd" rel="noreferrer" target="_blank">http://mailman.verplant.org/listinfo/collectd</a><br>
</div></div></blockquote></div><br></div>