Hi all,
Bernd sent me the ping client draft. As it has no version, I hope I refer to
the correct and current one.
First of all I want to ask, if further discussion about this paper has taken
place.
As I am fairly new to the GIMPS team, I might lack the overall picture, but
I hope to be able to contribute here.
> 4. Is this a good way for testing after all? Is it really needed at all?
> What could be added?
I think the approach of implementing a ping client by extending the GIMPS
protocol with 2 additional objects and special handling at the GIMPS level
is not so well suited for testing the GIMPS implementation.
The overall idea of storing IPs and Timestamps is good but to test the
complex GIMPS logic I think it would be better to implement the ping client
as a NSLP application. Such a test client would involve testing the API
which has pros and cons. On the one hand, problems in the API are detected
too, on the other hand GIMPS does a lot of things in the background, hiding
things from the NSLP application. (such as message association setup,
removing and reconnecting)
Another argument for implementing the ping client as a NSLP application is
that it needs no special treatment in the GIMPS layer, which makes the GIMPS
layer easier. You might argue that this approach adds additional overhead,
but as the ping client would use the common API the measured values would be
more realistic with regard to real NSLP applications.
The draft suggests to look in the payload of the newly added object to
determine the next hop on the way back. I think it shouldn't be done this
way for two reasons:
- It does not use and thus not test the next hop discovery integrated in
GIMPS.
- it adds additional code which could be buggy. If it does not work it tells
you nothing about the fact if GIMPS works or not.
What do you think?
Christian Dickmann
PS: It would be nice to add a version number and a date to the document.
