Text 9546, 124 rader
Skriven 2015-01-08 11:16:00 av Bill McGarrity (1419.2ftscpubl)
     Kommentar till en text av mark lewis (1:3634/12.0)
Ärende: Re: Path...
===================
-=> On 01-08-15 05:29, mark lewis wrote to Bill McGarrity <=-

Hiya mark...

 ml>  On Wed, 07 Jan 2015, Bill McGarrity wrote to mark lewis:

 BM> OK, I toggled another switch to see if it will add my node to the
 BM> Path... let me know please...
 BM>
 BM> @PATH: 266/404 261/38 712/848 280/464 203/0 320/119 123/500 3634/12

 ml> you mean like that? damn that went the long way around to get here...

 BM> Yes... I toggled zone blind and now it's there.  I know you're on
 BM> the FTSC so does it need to be there?

 ml> the original FTS-0004 (which was cribbed from the confmail docs) says
 ml> this...

 ml> [quote]
 ml>   5. PATH Lines

 ml>        These are  the last  lines in  a Conference Mail message and
 ml>        are a  new addition,  and therefore  is not supported by all
 ml>        Echomail processors. It appears as follows:

 ml>                           ^aPATH: 132/101 1014/1

 ml>        Where the  ^a stands  for Control-A  (ASCII character 1) and
 ml>        the net/nodes  listed correspond  to  those  systems  having
 ml>        processed the  message before it reached the current system.
 ml>        This is  not the  same as  the seen-by  lines, because those
 ml>        lines list  all systems  the message has been sent to, while
 ml>        the path line contains all systems having actually processed
 ml>        the message.  This is not a required field, and few echomail
 ml>        processors currently  support it,  however it  can  be  used
 ml>        safely with  any other  system, since  the line(s)  will  be
 ml>        ignored. For  a discussion  on how  the  path  line  can  be
 ml>        helpful, see the "Advanced Features" section of this manual.
 ml> [/quote]


OK... so it's an option... as of now.. :)

 ml> there is no "Advanced Features" section but at the end of the document
 ml> there is also this section...

 ml> [quote]
 ml>    Why a PATH line?

 ml>      As was  previously mentioned,  the PATH  line is a new concept in
 ml>      Echomail. It  stores the  net/node numbers  of each system having
 ml>      actually processed  a message.  This  information  is  useful  in
 ml>      correcting the  biggest problem  encountered by  nodes running an
 ml>      Echomail compatible  system - the problem of finding the cause of
 ml>      duplicate messages.  How does  the  PATH  line  help  solve  this
 ml>      problem? Take the following path line as an example:

 ml>           ^aPATH: 107/6 107/312 132/101

 ml>      This  shows  the  message  was  processed  by  system  107/6  and
 ml>      transferred to  system 107/312.  It further  shows system 107/312
 ml>      transferred the  message to  132/101, and  132/101  processed  it
 ml>      again. Now take the following path line as the example:

 ml>           ^aPATH: 107/6 107/312 107/528 107/312 132/101

 ml>      This shows  the message  having been processed by node 107/312 on
 ml>      more than one occasion. Based upon the earlier description of the
 ml>      'information control'  fields in  Echomail messages, this clearly
 ml>      is an  error in  processing (see  the section  entitled  "How  it
 ml>      Works"). This  further shows   node  107/528 as  the  node  which
 ml>      apparently processed  the message  incorrectly. In  this case the
 ml>      path line  can be  used to quickly locate the source of duplicate
 ml>      messages.

 ml>      In  a   conference  with  many  participants  it  becomes  almost
 ml>      impossible to  determine the  exact topology used. In these cases
 ml>      the use of the path line can help a coordinator of the conference
 ml>      track any  possible breakdowns in the overall topology, while not
 ml>      substantially increasing  the amount  of information transmitted.
 ml>      Having this  small amount of information added to the end of each
 ml>      message pays  for itself very quickly when it can be used to help
 ml>      detect a  topology  problem  causing  duplicate  messages  to  be
 ml>      transmitted to each system.
 ml> [/quote]

 ml> so it comes down to "what is the definition of 'systems having
 ml> processed the message'?"... does the originating system count as having
 ml> processed the message or not? it only scanned out and prepped it for
 ml> disposal^Wdistribution before puking^Wsending it to all the systems
 ml> connected to it...

More doubletalk so to speak. lol!!


 ml> honestly, this is one of those like the seenbys and an originating
 ml> system adding themselves to the seenby or not... some do and some
 ml> don't... the originating system should be able to be determined by the
 ml> origin line address... if it appears in the seenbys and path, ok...
 ml> otherwise, we still know where it originated...

 ml> at least, that's the way it is supposed to work but folks didn't think
 ml> about regurges and situations where that information is removed for
 ml> some reason...

OK.. as of now the ZONE_BLIND 4 option is in.  I can monitor it and see if
there is an issue later on down the road... :)

Thanks


Bill

Telnet: tequilamockingbirdonline.net
Web: bbs.tequilamockingbirdonline.net
FTP: ftp.tequilamockingbirdonline.net:2121
IRC: irc.tequilamockingbirdonline.net Ports: 6661-6670 SSL: +6697
Radio: radio.tequilamockingbirdonline.net:8010/live


... Look Twice... Save a Life!!!  Motorcycles are Everywhere!!
--- MultiMail/Win32 v0.50
 * Origin: TequilaMockingbird Online - Toms River, NJ (1:266/404)