Text 26284, 270 rader
Skriven 2015-07-27 17:07:08 av mark lewis (1:3634/12.73)
Kommentar till text 26282 av David Drummond (3:640/305)
Ärende: Both Are Covered
========================
28 Jul 15 05:17, you wrote to Matt Bedynek:
DD>>> It is the packet containing it that has a (one hop) destination. AT
DD>>> that node it must be re-propogated to what ever nodes that one has
DD>>> in it's configs for that echo. Again, it the the container that has
DD>>> a target address.
MB>> I think you should look at the packet format in detail.. First, the
MB>> only difference from netmail and echomail msg is the presence of
MB>> "AREA:XYZ". The packet header holds origin and destination address,
MB>> password, and product.
DD> I repeat "Echo mail has no destination address"
again, dude... look at your own outgoing packed echomail in your own outgoing
PKTs...
hell, look at the damned specs! there is no distinction between a netmail
message and an echomail message in FTS-0001...
[quote]
1. Application Layer Data Definition : a Stored Message
Stored Message
Offset
dec hex
.-----------------------------------------------.
0 0 | |
~ fromUserName ~
| 36 bytes |
+-----------------------+-----------------------+
36 24 | |
~ toUserName ~
| 36 bytes |
+-----------------------+-----------------------+
72 48 | |
~ subject ~
| 72 bytes |
+-----------------------+-----------------------+
144 90 | |
~ DateTime ~
| 20 bytes |
+-----------------------+-----------------------+
164 A4 | timesRead (low order) | timesRead (high order)|
+-----------------------+-----------------------+
>> 166 A6 | destNode (low order) | destNode (high order) |
+-----------------------+-----------------------+
168 A8 | origNode (low order) | origNode (high order) |
+-----------------------+-----------------------+
170 AA | cost (low order) | cost (high order) |
+-----------------------+-----------------------+
172 AC | origNet (low order) | origNet (high order) |
+-----------------------+-----------------------+
>> 174 AE | destNet (low order) | destNet (high order) |
+-----------------------+-----------------------+
>> 176 B0 | destZone (optional) | destZone (optional) |
+-----------------------+-----------------------+
178 B2 | origZone (optional) | origZone (optional) |
+-----------------------+-----------------------+
>> 180 B4 | destPoint(optional) | destPoint(optional) |
+-----------------------+-----------------------+
182 B6 | origPoint(optional) | origPoint(optional) |
+-----------------------+-----------------------+
184 B8 | replyTo (low order) | replyTo (high order) |
+-----------------------+-----------------------+
186 BA | Attribute (low order) | Attribute (high order)|
+-----------------------+-----------------------+
188 BC | nextReply (low order) | nextReply (high order)|
+-----------------------+-----------------------+
190 BE | text |
~ unbounded ~
| null terminated |
`-----------------------------------------------'
Message = fromUserName(36) (* Null terminated *)
toUserName(36) (* Null terminated *)
subject(72) (* see FileList below *)
DateTime (* message body was last edited *)
timesRead (* number of times msg has been read *)
destNode (* of message *)
origNode (* of message *)
cost (* in lowest unit of originator's
currency *)
origNet (* of message *)
destNet (* of message *)
destZone (* of message *)
origZone (* of message *)
destPoint (* of message *)
origPoint (* of message *)
replyTo (* msg to which this replies *)
AttributeWord
nextReply (* msg which replies to this *)
text(unbounded) (* Null terminated *)
DateTime = (* a character string 20 characters long *)
(* 01 Jan 86 02:34:56 *)
DayOfMonth " " Month " " Year " "
" " HH ":" MM ":" SS
Null
DayOfMonth = "01" | "02" | "03" | ... | "31" (* Fido 0 fills *)
Month = "Jan" | "Feb" | "Mar" | "Apr" | "May" | "Jun" |
"Jul" | "Aug" | "Sep" | "Oct" | "Nov" | "Dec"
Year = "01" | "02" | .. | "85" | "86" | ... | "99" | "00"
HH = "00" | .. | "23"
MM = "00" | .. | "59"
SS = "00" | .. | "59"
AttributeWord bit meaning
--- --------------------
0 + Private
1 + s Crash
2 Recd
3 Sent
4 + FileAttached
5 InTransit
6 Orphan
7 KillSent
8 Local
9 s HoldForPickup
10 + unused
11 s FileRequest
12 + s ReturnReceiptRequest
13 + s IsReturnReceipt
14 + s AuditRequest
15 s FileUpdateReq
s - need not be recognized, but it's ok
+ - not zeroed before packeting
Bits numbers ascend with arithmetic significance of bit position.
[/quote]
now look at the same thing for a packed message...
[quote]
1. Presentation Layer Data Definition : the Packed Message
To conserve space and eliminate fields which would be meaningless if
sent (e.g. timesRead), messages are packed for transmission. As this
is a data structure which is actually transferred, its definition is
critical to FidoNet. A packed message has a number of fixed length
fields followed by four null terminated strings.
While most of the string fields in a stored message are fixed length,
to conserve space strings are variable length when in a packet. All
variable length strings are all Null terminated, including especially
the message text.
Packed Message
Offset
dec hex
.-----------------------------------------------.
0 0 | 0 | 2 | 0 | 0 |
+-----------------------+-----------------------+
2 2 | origNode (low order) | origNode (high order) |
+-----------------------+-----------------------+
>> 4 4 | destNode (low order) | destNode (high order) |
+-----------------------+-----------------------+
6 6 | origNet (low order) | origNet (high order) |
+-----------------------+-----------------------+
>> 8 8 | destNet (low order) | destNet (high order) |
+-----------------------+-----------------------+
10 A | Attribute (low order) | Attribute (high order)|
+-----------------------+-----------------------+
12 C | cost (low order) | cost (high order) |
+-----------------------+-----------------------+
14 E | |
~ DateTime ~
| 20 bytes |
+-----------------------+-----------------------+
34 22 | toUserName |
~ max 36 bytes ~
| null terminated |
+-----------------------+-----------------------+
| fromUserName |
~ max 36 bytes ~
| null terminated |
+-----------------------+-----------------------+
| subject |
~ max 72 bytes ~
| null terminated |
+-----------------------+-----------------------+
| text |
~ unbounded ~
| null terminated |
`-----------------------------------------------'
Due to routing, the origin and destination net and node of a packet
are often quite different from those of the messages within it, nor
need the origin and destination nets and nodes of the messages within
a packet be homogenous.
PakdMessage = 02H 00H (* message type, old type-1 obsolete *)
origNode (* of message *)
destNode (* of message *)
origNet (* of message *)
destNet (* of message *)
AttributeWord
cost (* in lowest unit of originator's
currency *)
DateTime (* message body was last edited *)
toUserName{36} (* Null terminated *)
fromUserName{36} (* Null terminated *)
subject{72} (* Null terminated *)
text{unbounded} (* Null terminated *)
[/quote]
*BOTH* have a destination network address in them...
DD> - although the packet you have placed it in does. That packet could
DD> contain anything.
yup! they can contain echomail messages with a destination addresses different
than the one in the PKT header! just like netmail!
here's the key aspect that you are apparently missing... let's say that you are
linked in one echo to five other systems... when the tosser packages up
outbound echomail messages from that echo, it places one each of the linked
systems' addresses in each of the five copies of the original message as it is
packed into each system's PKT... so you end up with five PKTs each with a copy
of this one echomail message inside... those packed messages contain your 2D
address as the originating address... those packed messages also contain the
address of one of those linked systems... in the end, each PKT is addressed to
one each of the five linked systems AND the echomail message inside the PKT is
/also/ addressed to the linked system...
now, consider if these echomail messages are unpacked from those PKTs into raw
MSG messages and then packed into a new PKT addressed to another system that is
not one of the five systems linked to that echo... when this other system gets
the PKT, it will unpack the messages and analyze them one by one... if this
other system is properly configured to handle routed mail (and it doesn't make
a distinction between netmail and echomail), then it will pack those messages
into a new PKT or possibly several PKTs depending on the systems routing
structure... the system will be routing these echomail messages to the
destination system as seen in the messages' headers... if the system is
connected to one or more of those five systems you are linked to, then the
system will pack the messages into PKTs to those systems and deliver them...
otherwise the system will forward those echomail messages on to (one of) its
upstream connection(s) in another PKT...
that's one routed echomail scenario... another one is shorter in that if your
system doesn't pack the mail to the five linked systems but instead packs them
all to (one of) your upstream connection(s)... in other words, skipping the
first packing and unpacking with the repacking... some software allows this to
be done easily while other software holds your hand and prevents you from
shooting yourself in the foot... some consider it to be a misconfiguration but
in reality it is not... especially when considering that echomail is simply
another flavor of netmail...
FWIW: it is /this/ aspect of echomail and netmail that P4 speaks of... not
content as section 2.1.5 clearly states O:)
DD> Netmail has a destination address within the message - and can be sent
DD> on without packetisation.
ALL mail in fidonet has to be packetized... we do not transfer raw messages...
they're ALL packed into PKTs... ALL mail is unpacked from the PKTs and analyzed
before being packed into new PKTs for transmission to the next system...
)\/(ark
... To err is human, to forgive...$5.00
---
* Origin: (1:3634/12.73)
|