[Armory-devel] Server/agent

[Robert K. <ny...@gm...>]

It's pretty hard to meet you all on #armory on IRC, so I thought it would be
better to use the mailing list.

First of all, I'm one of the new developers that recently joined the
project. My name is Robert Konklewski and I live in Poland. My experience
includes C/C++, Python, some networking and databases, so I'll be mostly
interested in the server/agents parts of the Armory.
It would be nice if the rest of you introduced themselves, so we all know
who we're working with.

Now I'd like to make a few comments on some of the threads in the
developers' forum.

1) Dynamically linked plugins. I think it's a must both for server and
agents. It will enable us to better divide responsibilities, avoid clashes
in SVN and add new features without recompiling the whole app.

2) Server-Agent communication protocol. Agents will be running on multiple
platforms and probably multiple different CPUs, so we need a good data
representation mechanism. Text format is the most cross-platform one, but
its also more heavyweight than binary format. The proposed format (see
https://sourceforge.net/forum/forum.php?thread_id=1751975&forum_id=689813)
is too inflexible. Bicofino mentioned about database monitoring, which will
definitely need lists. It is possible to do lists with the proposed format,
but it'll look much like binary data represented as text which means waste
of space. So why not use a binary format? I suggest we use XDR (which is
standard and endian neutral) to transfer data through network.

3) Transport protocol. Since Armory is about monitoring, lots of small data
packets are going to be sent from many hosts. Only a high-performance
networking framework (like ACE) will be able to handle TCP connections.
Moreover, if you have ever used any P2P software, you should know what
happens to most routers/switches when there are too many TCP connections
open.
We can use UDP instead. It's true that some data will be lost, but things
like CPU or memory usage are updated frequently, so no one will ever notice
the loss of packets.

4) Networking library. Depends on all of the above.


Any comments?


Maybe we start writing down every key decision we make? There is no info
about what is going on with the project.