[atlas]trying to collect basic info about the architecture
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? Is the probe capable of bufffering data for a while if connectivity to the Net is still there, but not to the controller(s)? 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)? 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? Thanks to everyone who was and is involved in this fascinating project, with season's greatings and a happy (2010)++ to everyone, Wilfried. 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? :-)
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.
Some additional info: On 2010.12.22. 12:09, Emile Aben wrote:
On 21/12/2010 18:23, Wilfried Woeber, UniVie/ACOnet wrote:
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.
It could store more, but we're cautious for now as in the worst case this could fill up the storage space which could cause serious problems. We'll add more buffering as soon as we're confident it cannot fire back.
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.
This makes me wonder: what problem would this solve? You obviously couldn't use this feature if the probe was down, only if it was up; but then why would you want to reboot it? :-) Cheers, Robert
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/05/2011 11:29 AM, Robert Kisteleki wrote:
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.
This makes me wonder: what problem would this solve? You obviously couldn't use this feature if the probe was down, only if it was up; but then why would you want to reboot it? :-)
Well, there have been several cases of probes being up but not reporting any data. At least one of those cases was solved by a reboot :) Of course fixing all the issues that causes such behaviour is the ultimate goal, but since every piece of code contains at least one bug, i can see some use for such a feature for those people having their probes not in an easily reachable location. Having some form of remote control over one's usb power would also do the trick ;) Jelte -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk0kS1MACgkQ4nZCKsdOncXT1gCaA/ILH87xVGDHKF9n0wKXgDsx DLEAoJw1ksFf8viujiGLhVnV+7SWIFKV =w3/Q -----END PGP SIGNATURE-----
On 2011.01.05. 11:43, Jelte wrote:
On 01/05/2011 11:29 AM, Robert Kisteleki wrote:
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.
This makes me wonder: what problem would this solve? You obviously couldn't use this feature if the probe was down, only if it was up; but then why would you want to reboot it? :-)
Well, there have been several cases of probes being up but not reporting any data. At least one of those cases was solved by a reboot :)
Good point, but that's not the expected behavior :-)
Of course fixing all the issues that causes such behaviour is the ultimate goal, but since every piece of code contains at least one bug, i can see some use for such a feature for those people having their probes not in an easily reachable location.
I agree, but my argument is that in normal circumstances this isn't useful. Also, we can always force probes to reconnect (by kicking them out from the server side). Besides, if we implemented this feature, we'd have less incentives to solve the bugs :-) Cheers, Robert
Having some form of remote control over one's usb power would also do the trick ;)
Jelte
participants (4)
-
Emile Aben -
Jelte -
Robert Kisteleki -
Wilfried Woeber, UniVie/ACOnet