[atlas]trying to collect basic info about the architecture

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.