On 01-08-15 05:29, mark lewis wrote to Bill McGarrity <=-
Hiya mark...
On Wed, 07 Jan 2015, Bill McGarrity wrote to mark lewis:
OK, I toggled another switch to see if it will add my node to the
Path... let me know please...
@PATH: 266/404 261/38 712/848 280/464 203/0 320/119 123/500 3634/12
you mean like that? damn that went the long way around to get here...
Yes... I toggled zone blind and now it's there. I know you're on
the FTSC so does it need to be there?
the original FTS-0004 (which was cribbed from the confmail docs) says this...
[quote]
5. PATH Lines
These are the last lines in a Conference Mail message and
are a new addition, and therefore is not supported by all
Echomail processors. It appears as follows:
^aPATH: 132/101 1014/1
Where the ^a stands for Control-A (ASCII character 1) and
the net/nodes listed correspond to those systems having
processed the message before it reached the current system.
This is not the same as the seen-by lines, because those
lines list all systems the message has been sent to, while
the path line contains all systems having actually processed
the message. This is not a required field, and few echomail
processors currently support it, however it can be used
safely with any other system, since the line(s) will be
ignored. For a discussion on how the path line can be
helpful, see the "Advanced Features" section of this manual. [/quote]
OK... so it's an option... as of now.. :)
there is no "Advanced Features" section but at the end of the document there is also this section...
[quote]
Why a PATH line?
As was previously mentioned, the PATH line is a new concept in
Echomail. It stores the net/node numbers of each system having
actually processed a message. This information is useful in
correcting the biggest problem encountered by nodes running an
Echomail compatible system - the problem of finding the cause of
duplicate messages. How does the PATH line help solve this
problem? Take the following path line as an example:
^aPATH: 107/6 107/312 132/101
This shows the message was processed by system 107/6 and
transferred to system 107/312. It further shows system 107/312
transferred the message to 132/101, and 132/101 processed it
again. Now take the following path line as the example:
^aPATH: 107/6 107/312 107/528 107/312 132/101
This shows the message having been processed by node 107/312 on
more than one occasion. Based upon the earlier description of the
'information control' fields in Echomail messages, this clearly
is an error in processing (see the section entitled "How it
Works"). This further shows node 107/528 as the node which
apparently processed the message incorrectly. In this case the
path line can be used to quickly locate the source of duplicate
messages.
In a conference with many participants it becomes almost
impossible to determine the exact topology used. In these cases
the use of the path line can help a coordinator of the conference
track any possible breakdowns in the overall topology, while not
substantially increasing the amount of information transmitted.
Having this small amount of information added to the end of each
message pays for itself very quickly when it can be used to help
detect a topology problem causing duplicate messages to be
transmitted to each system.
[/quote]
so it comes down to "what is the definition of 'systems having
processed the message'?"... does the originating system count as having processed the message or not? it only scanned out and prepped it for disposal^Wdistribution before puking^Wsending it to all the systems connected to it...
More doubletalk so to speak. lol!!
honestly, this is one of those like the seenbys and an originating
system adding themselves to the seenby or not... some do and some
don't... the originating system should be able to be determined by the origin line address... if it appears in the seenbys and path, ok... otherwise, we still know where it originated...
at least, that's the way it is supposed to work but folks didn't think about regurges and situations where that information is removed for
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)