On 21/12/2010 18:23, Wilfried Woeber, UniVie/ACOnet wrote:
Dear ATLAS-Team,
I am aware of the fact that my poking and attempt to collect information may be premature, as the whole thing is still very much in development...
Still, I think it would be useful for many of us to have some sort of "snapshot" regarding the behaviour of the probes and the framework they live in.
The initial basic questions on my end would be:
What does the term "connect", to one of the controllers, really mean in terms of TCP/IP Lingo? Like: does the thing open a TCP hose to the controller? Is communication based on UDP and/or on TCP?
It's a single SSH connection on TCP/443.
Is the probe capable of bufffering data for a while if connectivity to the Net is still there, but not to the controller(s)?
Yes, the probes have a limited capability to do so. I think it's currently capable of storing a couple of minutes worth of data.
Is there any means to (locally, on the same subnet, or even remotely) trigger or "reboot" a probe, other than disconnecting power (which means physical access required)?
Currently there is no way for users to reboot a probe other then disconnecting power. If this is a capability that people would like to have, we could look into ways we could make that happen.
I am also wondering how much of this stuff is available already and where to collect it - the 'labs pool may be more appropriate than this list?
The presentation at RIPE61 and the RIPE Labs articles are what we have this far. If there is a need for more documentation at this point, we'll listen of course, but that would also take resources away from developments.
Thanks to everyone who was and is involved in this fascinating project, with season's greatings and a happy (2010)++ to everyone, Wilfried.
Best wishes from a snowy Amsterdam, on behalf of the whole team! Emile Aben RIPE NCC
PS: for a future version of the probes or as an optional gadget: how about making the thing capable of feeding it off 2 different power plugs, e.g. a primary and a UPS? :-)
The power-input is USB, so if you can make whatever feeds power to the USB redundant you effectively accomplish what I think you want.