I would also agree that Ping be split up for the very simple reason
that most *users* out there are accustomed to a "ping" command being a
VERY simple connectivity test. Users are used to using ping to just
test if they can reach another node on the network. That's it.
Sure, functionality *could* be added to a "ping" command to have it
retrieve various bits of resource information, but I would expect that
this is not necessarily what users (and implementers) may be
expecting. I would agree that it would be best to split it so that
PING was just the truly low-level connectivity test - simple, easy and
fast - and then something else like "PROBE" would be used to test for
and receive the resource information.
My 2 cents,
Dan
On Jul 17, 2008, at 12:43 PM, David A. Bryan wrote:
I'm pretty solidly in the camp of splitting it (3). Technically
speaking, you can do two things with the same message, so the present
approach would work, but from a protocol design perspective, I prefer
splitting it for a few reasons:
1) The draft is a little hard to read this way. I can see a good bit
of confusion being caused by the fact that in many cases PING will be
used for the DHT, but it is only described in 6.4.2, on connection
management, and not in 6.3.2. You could list it both places, but that
seems ugly too.
2) Splitting it in two gives the DHT section not only a push-based
mechanism for information, but a poll-based one as well (other than
abuse of a connection method). Many DHTs will be far easier to
implement this way (Chord is, for that matter -- PING is used as a
poll-based for DHT maintenance, not connection management in 12.6.3 of
the current draft).
3) While I can see being able to do it either way, if they are split,
from an implementation perspective I can see modular DHTs being
easier. Connection management can be implemented once, DHTs for each
message, and a lower layer doesn't have to determine which context
PING is being used in. (I know there are other ways to do this, but I
just think it will make implementations simpler)
So again, I say split 'em. PROBE is a good name for the new method.
POLL would work too.
David (as individual)
On Wed, Jul 16, 2008 at 3:05 PM, Cullen Jennings <[EMAIL PROTECTED]>
wrote:
The ping method now does three things as described in 6.4.2.2 and
perhaps
the name should be changed to something other than ping. Options
are so the
options are here are roughly
1) leave it as is
2) change name to something new (say probe)
3) split into two methods one that determines which resource
another node is
responsible (PROBE) for and one that does the other parts (PING)
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
--
David A. Bryan
[EMAIL PROTECTED]
+1.757.565.0101 x101
+1.757.565.0088 (fax)
www.SIPeerior.com
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
--
Dan York, CISSP, Director of Emerging Communication Technology
Office of the CTO Voxeo Corporation [EMAIL PROTECTED]
Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com
Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com
Build voice applications based on open standards.
Find out how at http://www.voxeo.com/free
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
