Bruce Lowekamp <[EMAIL PROTECTED]> wrote:
> songhaibin 64081 wrote: > > If that makes sense, perhaps the traceroute mode of the Echo > message in the diagnostic draft, which is used to diagnose where > the problem happens for the failed routing, and gather other > useful information on the path, should also be splitted into two > messages:> (1) a message to track where the problem happens for > failed routing, > > (2) a new message to gather other information of intermediate peers > > > > For (2), does reload's route log (6.2.2.2) meet your requirements, > or do > you think different functionality is needed. > > Bruce Route-log is an attribute must be involved with other requests. I prefer a separate message to do this work(2). You can just gather the ovelay information, without accompany with any other PUT, GET or other requests. -Song Haibin > > > > > > > -Song Haibin > > > > > > Dan York <[EMAIL PROTECTED]> wrote > > > > > >> 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 > >> > > _______________________________________________ > > P2PSIP mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/p2psip > > > > _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
